|
| | | Altova Mailing List Archives>Archive Index >xml-dev Archive Home >Recent entries >Thread Prev - [xml-dev] Pragmatic namespaces >Thread Next - Re: [xml-dev] Pragmatic namespaces Re: [xml-dev] Pragmatic namespacesTo: Micah Dubinko <micah.dubinko@---------.--->, XML Developers List Date: 8/1/2009 10:37:00 AM 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
| |
| | ||||||||
| Company | Legal | Press | Partners | Careers | Sitemap | Contact Us | Altova Blog | Mobile | Full Site | |||
|
