Re: Automatic XML namespaces

On Fri, Nov 6, 2009 at 4:49 AM, Henri Sivonen <hsivonen@iki.fi> wrote:
> Making the semantics of the parser output depend on an optional feature is
> an incredibly bad idea.

I meant optional per spec, rather than optional per UA.  That is, all
HTML-only (or HTML+SVG+MathML+X3D-only, or whatever) UAs would just
totally ignore ns.xml, and HTML-only (or HTML+SVG+MathML+X3D-only)
documents wouldn't include such declarations.  Any UA processing a
conforming HTML document (meaning not with random unrecognized other
namespaces mixed in) would be required to ignore the namespace
declarations, so behavior would be completely deterministic per the
spec.

But if you wanted to make an HTML+FooML+BarML user agent, and FooML
happened to share an element name with BarML, you would be able to
have it parse the ns.xml to resolve ambiguities.  So if, as an author,
you happened to want to make such a document, you would be forced to
include whatever markup is necessary to tell the UA that when you say
"squizzle", you mean "foo:squizzle" and not "bar:squizzle".  Or you
mean "bar:squizzle", but only if it's inside a <bar> element.  Or
whatever.

But if you're using only standard markup languages, with no naming
conflicts, you would just ignore the whole deal.

On Fri, Nov 6, 2009 at 5:33 AM, James Graham <jgraham@opera.com> wrote:
> I am rather confused about how this proposal is supposed to work in the
> browser case (and whether that depends on text/html vs
> application/xhtml+xml). I see a couple of possibilities:
>
> * The namespace file is never read by browsers. They build the rules into
> the parser, possibly in a way that is amenable to non-upgrade-cycle linked
> updates.

Right.

>  In this case I don't see how this proposal enables distributed
> extensibility (possibly that is not a design goal but I somewhat assume it
> is).

I don't see how it doesn't.  If the browser supports your extension,
it will have to add hardcoded support to actually do whatever the
extension requires.  At that point it can also add hardcoded parsing
support.  The only change would be if there's a naming conflict: then
authors would be required to explicitly disambiguate it somehow (exact
format TBD).  The advantage for decentralized extensibility is that
there's a way to handle such naming conflicts.  If a browser happened
to know in advance that it didn't support any two languages that
conflicted, it could safely ignore all disambiguation mechanisms.

> This interpretation of the proposal also means that browser and non-browser
> tools will interpret documents differently at a rather fundamental level
> (one will read namespace files the other will not). This kind of
> context-sensitive processing seems to cause a large number of problems (c.f.
> validating vs non-validating XML processors).

Non-browsers would read the namespace files exactly the same as
browsers: only if necessary for disambiguation.  Which means not at
all in most cases, unless they find it's really essential to support
two specs that have conflicting element names.

Received on Sunday, 8 November 2009 06:24:55 UTC