[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
Re: [xml-dev] Pragmatic namespaces
- From: Micah Dubinko <micah.dubinko@marklogic.com>
- To: Henri Sivonen <hsivonen@iki.fi>
- Date: Sun, 23 Aug 2009 15:05:31 -0700
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.
<http://markmail.org/message/cfy2zi5ze7fjbvqt>
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
fashion?
-m
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
