[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Pragmatic namespaces

  • From: COUTHURES Alain <alain.couthures@agencexml.com>
  • To: Micah Dubinko <micah.dubinko@marklogic.com>, XML Developers List <xml-dev@l...>
  • Date: Sat, 01 Aug 2009 12:35:39 +0200

Re:  Pragmatic namespaces
Hey Micah,

I was just having time to start to think about namespaces ;-)

Let me, first, say that I now love namespaces. Like many, my first years with XML were disturbed by namespaces : I didn't understand them and many errors occurred due to this. It was like dark magic : add this and that, add more if it still doesn't work... The no-namespace capability is even more difficult to understand because it has to be explicit ! I understand that HTML writers, who are usually not programmers, hate namespaces, considering them as useless (the element name is explicit, isn't it?) and problems cause.

I wouldn't say that today everything is perfect for me :
  • having a big list of xmlns attributes at the document element is horrible and they are usually always the same (same prefix, same URI) and when I try to reduce the number of them, I finally need one of them later...
  • upgrading a namespace sometimes means changing every declaration of it because of URI change
  • copy/paste from different documents, where different prefixes are used for the same namespace, requires delicate text editor substitutions
  • misspelling in URI occurs (URI are too long, they should not contain a year,...) and it's usually difficult to detect it immediately
  • misspelling in element or attribute names in a specific namespace occurs too...
Misspelling is, for me, the most important concern because I'm just using a smart text editor (Notepad++ is free and fast). With rendering language such as HTML or SVG, it's easy to locate what is wrong because it can be seen but, with XPath, there is no "unknown" element, just "not found" elements !

Even some widespread XML libraries and engines have difficulties with namespaces !

My first remark about Java-style namespaces is about a . or a : as separator. The dot is now allowed in element names and I have already seen some XML notations using it. I'm not sure it's a good practice anyway and . as separator sounds like Java definitely.
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.
Yes, it's a very important point but I wouldn't like to reduce XML possibilities either. Easy for non-programmers, powerful for others : is it possible ?

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)
This might be a problem for XForms instance data. XSLTForms doesn't generate an error when there is no prefix and no xmlns="" in the instance data and, when people send me their forms for support, I usually see that they don't bother with that. Yes, non-programmers try to write programs sometimes...

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")
OK. It sounds good !

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.
ONLY on the root element is a problem for generic XML tools. The Component Manager I wrote for XSLTForms development environment can work for any XML document with its own namespaces, unknown by the Component Manager itself. With XSLT, xsl:copy-of can be used for a node from an external document, the stylesheet doesn't have to know each and every namespaces.

It's also a problem for XForms instance data.

A very good aspect of namespaces is to allow to mix data without disturbing the programs interested in just one namespace !

Why not just say that, usually, using.<pname> attributes are on the root element ?

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

Example:

<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")
It's pragmatic.

This kind of list should not change frequently. It sounds more than reserved prefixes.

I, personally, would like to add

xsl http://www.w3.org/1999/XSL/Transform
xsd http://www.w3.org/2001/XMLSchema
xsi http://www.w3.org/2001/XMLSchema-instance
xbrl http://www.xbrl.org/2003/instance
xbrll http://www.xbrl.org/2003/linkbase
ifrs http://xbrl.iasb.org/taxonomy/2008-03-01/ifrs
...

Big companies, such as Microsoft, would probably have their own items without asking others if they agree...

Managing a short list will not be easy...

One solution could be to limit it to namespaces frequently used in HTML documents only.


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

That's the entire proposal.
Great !

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.
But compatibility problems would occur between different browsers and different versions of the same browser. It's not a non-programmer concern, isn't it ?

Thank you for this proposal. Yes, something has to be done and it sounds much more easy this way.

Best regards,

-Alain


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


PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.