atom feed90 messages in org.xml.lists.xml-devRe: [xml-dev] Pragmatic namespaces
FromSent OnAttachments
63 earlier messages
Pete CordellAug 6, 2009 11:49 am 
John L. ClarkAug 6, 2009 12:32 pm 
Simon St.LaurentAug 6, 2009 1:06 pm 
Michael LudwigAug 6, 2009 1:13 pm 
Michael LudwigAug 6, 2009 1:16 pm 
Michael LudwigAug 6, 2009 1:39 pm 
Liam QuinAug 6, 2009 2:43 pm 
Michael LudwigAug 6, 2009 3:11 pm 
Michael KayAug 6, 2009 3:32 pm 
rjel...@allette.com.auAug 6, 2009 8:21 pm 
rjel...@allette.com.auAug 6, 2009 8:32 pm 
Michael KayAug 7, 2009 1:10 am 
michael odling-smeeAug 7, 2009 1:28 am 
Michael KayAug 7, 2009 1:33 am 
michael odling-smeeAug 7, 2009 2:24 am 
Michael LudwigAug 7, 2009 3:00 am 
Dave PawsonAug 7, 2009 8:50 am 
Liam QuinAug 7, 2009 9:08 am 
Micah DubinkoAug 7, 2009 5:03 pm 
Micah DubinkoAug 7, 2009 5:05 pm 
Robert KobergAug 7, 2009 5:08 pm 
Dave PawsonAug 12, 2009 12:34 am 
Dave PawsonAug 13, 2009 12:35 am 
Henri SivonenAug 13, 2009 11:47 am 
Micah DubinkoAug 23, 2009 3:05 pm 
David CarverAug 23, 2009 4:21 pm 
Henri SivonenAug 24, 2009 4:03 am 
Subject:Re: [xml-dev] Pragmatic namespaces
From:Micah Dubinko (mica@marklogic.com)
Date:Aug 23, 2009 3:05:08 pm
List:org.xml.lists.xml-dev

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

_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-@lists.xml.org subscribe: xml-@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php