|Micah Dubinko||Jul 31, 2009 4:06 pm|
|COUTHURES Alain||Aug 1, 2009 3:35 am|
|Amelia A Lewis||Aug 1, 2009 7:43 am|
|Kurt Cagle||Aug 2, 2009 11:54 am|
|Kurt Cagle||Aug 2, 2009 12:30 pm|
|Amelia A Lewis||Aug 2, 2009 6:44 pm|
|rjel...@allette.com.au||Aug 2, 2009 9:06 pm|
|Micah Dubinko||Aug 2, 2009 9:21 pm|
|Micah Dubinko||Aug 2, 2009 9:39 pm|
|Dave Pawson||Aug 2, 2009 11:20 pm|
|Michael Ludwig||Aug 3, 2009 8:30 am|
|Kurt Cagle||Aug 3, 2009 10:41 am|
|Pete Cordell||Aug 3, 2009 11:56 am|
|Michael Kay||Aug 3, 2009 1:46 pm|
|Kurt Cagle||Aug 3, 2009 4:42 pm|
|rjel...@allette.com.au||Aug 3, 2009 8:39 pm|
|Pete Cordell||Aug 4, 2009 12:36 am|
|Tim Bray||Aug 4, 2009 9:44 am|
|Micah Dubinko||Aug 4, 2009 11:17 am|
|Micah Dubinko||Aug 4, 2009 10:54 pm|
|Liam Quin||Aug 4, 2009 11:28 pm|
|Dave Pawson||Aug 5, 2009 12:45 am|
|Pete Cordell||Aug 5, 2009 3:17 am|
|Tim Bray||Aug 5, 2009 12:53 pm|
|Liam Quin||Aug 5, 2009 1:46 pm|
|Michael Kay||Aug 5, 2009 4:44 pm|
|64 later messages|
|Subject:||[xml-dev] Pragmatic namespaces|
|From:||Micah Dubinko (mica...@marklogic.com)|
|Date:||Jul 31, 2009 4:06:23 pm|
Literally for years, people have been talking about how great it would
be to use something like Java-style namespaces in XML instead of the
current xmlns regime. For example
By scoping the solution down to just HTML syntax, I believe a reasonable solution can be crafted, and now that the W3C is focusing on "distributed extensibility" as a requirement for HTML5, the timing seems right to see how far a proposal in this direction can go. On the other hand, if this proposal doesn't work out, maybe it will permanently end the musings about how great Java-style namespaces would be.
I'm posting this on xml-dev for community input and feedback. I have no current association with the HTML Working Group, and this is my personal project, with no reflection on my employer. The format is an intermingling of requirements and proposed solutions. This is largely inspired by Tom Bradford's "clean namespaces" proposal, the archive.org version of which I linked to previously.
Requirement: Ask not if it is good enough, ask if it can be popular enough.
(Thanks to Douglas Crockford for the quote). This proposal will horrify the purists, but that's OK.
Requirement: this solution must not interfere with existing HTML elements or attributes
Point 1: Any element name with no dots in it is treated as HTML (including HTML rules on handing unrecognized elements)
Requirement: this solution must allow for distributed creation of globally-unique namespace names (including those outside of a consensus process)
Point 2: Any element with one or more dots in it is treated as an extension element. The portion after the last dot is considered the localname, and the the portion up to but not including the last dot is parsed as the pragmatic namespace name (or pname for short). Interfaces with existing namespace-aware APIs must treat the pname as the namespace URI. With the exception noted below, to prevent clashes pnames must be based on reversed DNS names.
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")
Requirement: it is highly desirable to produce a document that will produce the same element names in HTML or XML
Point 3: Zero or more special attributes of the form using.<pname> may appear on the root element, and ONLY on the root element. The declarations have document-wide scope. The pname that appears after "using." is the one being declared. The value of the attribute is a space-separated list of localnames that represent boundary elements, in other words, upon reaching a boundary element, a new namespace gets applied to that element and all children (until encountering another boundary element).
Example equivalent to the previous: <html using.com.example="project"> <head> <project> <id>123521123</id> </project> </head>
This structure will produce the same element names in an XML parser, and a straightforward transformation could convert it to true XML +Namespaces.
Requirement: widely-known namespaces must be parse to an equivalent DOM as xmlns
Point 4: In any extension element with only one dot, the token before the first dot is treated specially. Specifically, there exists a list of grandfathered namespaces, and associated namespace URIs. Interfaces with existing namespace-aware APIs must treat the grandfathered namespace URI as the namespace URI of the extension element.
Here is the list: (additional suggestions welcome)
atom http://www.w3.org/2005/Atom docbook http://docbook.org/ns/docbook html http://www.w3.org/1999/xhtml math http://www.w3.org/1998/Math/MathML/ svg http://www.w3.org/2000/svg xbl http://www.mozilla.org/xbl xbl2 http://www.w3.org/ns/xbl xforms http://www.w3.org/2002/xforms xlink http://www.w3.org/1999/xlink xml http://www.w3.org/XML/1998/namespace
<html using.math="math">... <p> E.g. <math><msqrt><mi>π</mi></msqrt></math> </p> ...</html>
In this example document.getElementsByTagName("mi") would return the innermost element. So would document.getElementsByTagNameNS("http://www.w3.org/1998/Math/MathML/ ", "mi")
Requirement: must support HTML nested inside an extension vocabulary.
Point 5: Unless overridden, HTML documents are treated as if all localnames explicitly listed in the specification are HTML boundary elements.
Example: <html using.svg="svg"> <body> <svg version="1.1" viewBox="0 0 100 100" preserveAspectRatio="xMidYMid slice"> <rect x="10" y="10" width="100" height="150" fill="gray"/> <foreignObject x="10" y="10" width="100" height="150"> <body> <div>Here is a <strong>paragraph</strong>.</div> </body> </foreignObject> </svg> </body> </html>
Here the inner body element and its children are still treated as HTML.
Another example: <html using.xforms="model select1 range secret"> <head> <model>...</model> </head> </body> <xforms.input>... </body> </html>
In this case, "input" is already used as an HTML element name, so uses of it--even with the using statement at the top--need to be explicitly spelled out. Of course, the author could have overridden this by including "input" in the using statement, but then any regular HTML input controls would need to be spelled <html.input>. Just like in Java.
That's the entire proposal.
In practice, it may be inevitable that browser makers might bake in additional defaults, like using.math="math mi mo ms mn mtext" such that users can freely use chosen vocabularies with zero additional markup. Support for this outcome is an additional feature of this proposal.
I will be at Balisage this year. If you have comments or ideas, look me up. Comments on this list are welcome as well.
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