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

On Aug 24, 2009, at 01:05, Micah Dubinko wrote:

> On Aug 13, 2009, at 11:47 AM, Henri Sivonen wrote:
>>> 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.

I thought the point of "extensions" was that they are mainly hooks for  
scripts. As such, they could work on existing browsers, too, if they  
were a mere naming convention. In contrast, SVG requires quite  
distinctive native 2D rendering support that can't be achieved with  
mere scripting and styling macros on top of the HTML4+CSS functionality.

As for unilateralist browser-sensitive extensions like <blink> and  
<marquee>, it would probably have been better to make them less  
attractive than the elements minted through a peer review. Thus, it  
would have been better to make them <com.netscape.blink> and  
<com.microsoft.marquee> without a mechanism to hide the prefixes.

> 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.

Actually, SVG-in-text/html parsing takes special steps to deal with  
legacy content that contains SVG bit due to cargo cult copying and  
pasting. Specifically, the parser breaks out of SVG at the slightest  
hint of cargo cult copying and pasting:
(The cases that say: 'A start tag whose tag name is one of: "b",  
"big", "blockquote", "body", "br", "center", "code", "dd", "div",  
"dl", "dt", "em", "embed", "h1", "h2", "h3", "h4", "h5", "h6", "head",  
"hr", "i", "img", "li", "listing", "menu", "meta", "nobr", "ol", "p",  
"pre", "ruby", "s", "small", "span", "strong", "strike", "sub", "sup",  
"table", "tt", "u", "ul", "var" A start tag whose tag name is "font",  
if the token has any attributes named "color", "face", or "size"')

> 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.

Except for the SVG and MathML stuff, the changed behaviors (compared  
to the old HTML parser in Gecko) fall mainly into one of two buckets:
  1) Changes from old Gecko behavior to align with IE or WebKit behavior
  2) Changes from old behavior of any browser in order to make the  
parser never read back from the DOM in order to allow the DOM and the  
HTML parser to live in different threads

The SVG and MathML changes are sometimes generalized to mean that  
browsers are now doing HTML extensions or namespaces. That's not  
what's happening. The SVG and MathML support is about taking the  
browser-native functionality investment that has already been made but  
that has been tied to XML parsing and enabling it in the text/html  

It is incorrect to extrapolate that it's now OK to use Namespaces in  
text/html for purposes other than salvaging investments in  
functionality previously implemented but tied to XML.

> 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.

I think it's a problem in terms of the DOM Consistency design  
principle if the same syntax doesn't produce the same DOM on both  
sides of the fence. The simplest way to make progress is to stick to  
things that don't require any changes to the XML 1.0 4th ed. +  
Namespaces 1.0 layers on the XML side and that don't trigger any  
Namespaces layer processing (i.e. don't use the colon).

Using reverse DNS identifiers as a naming convention without affecting  
how the DOM/Infoset is constructed meets these requirements.

>> 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...

Parsers and DOM Level 2 are rather heavily coupled. I meant in terms  
of the DOM API, in terms of the Infoset, in terms of the XPath data  
model, in terms of Selectors and in terms of the browser-internal APIs.

>> 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.

OK. Your proposal specifically suggested changes to what specific DOM  
methods return, though.

>> 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?

SVG and MathML are the only vocabularies that have already been  
implemented in multiple browsers and that need bringing into the text/ 
html world. New things can simply be added to the http://www.w3.org/1999/xhtml 
  namespace. That's what was done with <video>, for example.

I think it is a bug that the organization of the W3C into Working  
Groups leaks to Web authors in the form of multiple namespaces.  
(Consider Conway's Law.) Changing the namespace of SVG and MathML or  
withdrawing Namespaces from the XML stack would be too late at this  
point, so the namespaces for SVG and MathML need to be grandfathered  
in, but there's no reason to keep minting more namespaces.

>>> 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.

This is possible. (The XML vocabularies that wish to use dotted names  
and be mixed readily into text/html should probably use the http://www.w3.org/1999/xhtml 
  namespace, though.)

> 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.

I think it's pretty simple to form the list of privileged namespaces:  
Take the set of namespaces supported by at least two browsers out of  
IE, Firefox, Safari and Opera in subtrees of application/xhtml+xml  

>>> 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  
> fashion?

Why shouldn't SVG and MathML work just as easily as HTML? What benefit  
is there for Web authors for having to use incantations like xmlns or  
using.math when it has now been shown by implementation this stuff can  
work without such incantations? I think the HTML5 way of incorporating  
SVG and MathML is less magic in the sense that there are no spells for  
the author to cast.

Henri Sivonen

[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