OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] Pragmatic namespaces

Thanks for your response, Henri. My goal is to get people thinking  
about the issues, and in that regard the proposal seems to have  
marginally succeeded.

I caught Liam, who presented a similar paper at Balisage, and we had a  
longish chat about this proposal. More on that later, but for now,  
some inline responses.

On Aug 13, 2009, at 11:47 AM, Henri Sivonen wrote:
> I'm glad to see that here over in the XML land, people who've worked
> with Namespaces show appropriate discontent with them. I wish the RDFa
> land took note.

With due respect, I've avoided bringing RDF into this thread and will  
continue that trend here. :)

>> Point 2:
>> Any element with one or more dots in it is treated as an extension
>> element.
> As long as "treated" is a social thing and not in software operation,
> so far good.
> I think syntax-wise this is the best "distributed extensibility"
> proposal I've seen for HTML5. (It's similar to the microdata section
> in HTML5.) Thank you!

Credit Tim Bray with that proposal.

As originally presented, the Pragmatic Namespace proposal was about a  
lightweight syntax for declaring namespaces, and hence parser  
behavior. I used DOM functions merely to illustrate the resulting  
parse tree, not to suggest any changes to the DOM spec. That wasn't  
clearly explained, and reading the proposal without that in mind could  
lead one to different conclusions than intended.

>> Example:
>> <head>
>> <title>Document title</title>
>> <com.example.project>
>>  <com.example.id>123521123</com.example.id>
>> </com.example.project>
>> </head>
>> In this example document.getElementsByTagName("id") would return the
>> innermost element.
>> So would document.getElementsByTagNameNS("com.example", "id")
> I think here your proposal goes into the weeds.
> The #1 flaw with Namespaces & DOM Level 2 is that the identifiers that
> are fundamental to the operation of software were different from the
> identifiers in plain XML 1.0 or DOM Level 1. Your proposal repeats
> this mistake by making the platform behave radically differently if
> you have a JS program running on a browser that doesn't implement your
> proposal and if you have the same JS program running on a browser that
> implements your proposal.

It's already the case that older browsers will interpret things  
differently. Old browsers won't treat <svg> as something in the SVG  
namespace, but newer ones will. Since there are (presumably) far fewer  
HTML documents with multiple dots in element names than with <svg>  
elements, one could argue that this doesn't cause significant  
backwards compatibility problems either.

By its very nature, recent HTML standardization work has been about  
getting browsers to change how their parsers operate. I can flip a  
switch in my Firefox and enable HTML5 mode, which has slight  
differences in how my browser would otherwise work.

Talking about changing HTML parsers this way might make some folks  
uncomfortable, but that's OK. Remember, I'm trying to nudge people  
toward thinking about solutions they might not have considered before.

The other issue that came up in discussions is what the proper scope  
of a proposal like this should be. Does it affect only the HTML syntax  
rules, or could something be dreamt up that would supplant/replace  
xmlns in XML documents as well? That's a wide open issue still.

> In your example, the local name of the innermost element MUST be
> "com.example.id" for compatibility with existing behavior.

Based on your following comment, it's not clear if you mean existing  
behavior of parsers or of the DOM API...

> Changing
> what document.getElementsByTagName() returns here is not something
> that's open for discussion. (As in, the probability of a browser
> vendor shipping with the API behavior change is virtually zero.)

Right, I wouldn't expect any DOM functions to change w.r.t. returning  
already-parsed DOM information.

> The namespace of the innermost element as reported by the DOM isn't
> really open for discussion, either. In an HTML5-compliant UA it is "http://www.w3.org/1999/xhtml
> ", because this unifies the DOM with the XHTML5 side, where the
> namespace is constrained by the XHTML legacy to be "http://www.w3.org/1999/xhtml
> ". In legacy UAs, the namespace is null.

There are already special cases for SVG, MathML, etc., and already  
differences with legacy browsers. Is one more class of special cases  
beyond consideration? If so, why?

>> Requirement: widely-known namespaces must be parse to an equivalent
>> DOM as xmlns

Think of this: it's entirely possible that the arrival of a  
distributed extensibility mechanism in HTML (not just XHTML) might  
forever change some respects of how HTML gets written, and how XML  
vocabularies are defined.

For example, say Tim's proposal mentioned earlier takes off. Then 1)  
many more HTML documents will be around using one-off <x.y.z> element  
names, and 2) future XML vocabularies might use element names like  
<foo.bar.baz> (possibly without namespaces) so that they could be  
readily used in HTML. But even if this happens, there still exists  
*some* list of older namespaces/vocabularies that people will want to  
use in HTML. I don't have a strong opinion of what that list might be,  
so I put together some typical examples in the initial proposal in an  
attempt to smooth over the inevitable transition process.

> For practical purposes, the Web platform has four markup languages:
> HTML, SVG, MathML and ARIA. HTML5 already covers the namespace
> assignment of HTML, SVG and MathML. ARIA doesn't need special
> treatment, because it consists entirely of no-namespace attributes.
> It's plausible that XBL2 joins the markup language family of the
> platform. However, it's more problematic from the text/html point of
> view. More on that below.

>> Example:
>> <html using.math="math">...
>> <p>
>> E.g. <math><msqrt><mi>π</mi></msqrt></math>
>> </p>
>> ...</html>
> This already works in HTML5 without even having to use the using.math
> stuff. I invite you to try it in a trunk nightly build of Firefox
> after you've set the preference html5.enable to true in about:config.

What if these namespace assignments could happen in a less magical  


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS