Home. 
.

transparent

transparent

transparent

Altova Mailing List Archives


Re: [xml-dev] RE: Namespace use cases

From: Amelia A Lewis <amyzing@--------.--->
To: 'XML Developers List' <xml-dev@-----.---.--->
Date: 7/10/2009 2:24:00 AM
On Thu, 9 Jul 2009 17:59:56 -0700, Jim Tivy wrote:
> I would love to hear of some success or horror stories of multi-namespaces
> in authoring content.  Anyone out there doing this in DITA, DocBook, open
> office...
> 
> What ever happened to the compound document?

Web services are an obvious use case.  It's true that SOAP is 
execrable, but the 'simplest subset' continues to drive it: there's an 
"envelope" namespace, which indicates 'this is a message conforming to 
certain expectations' (that breaks down when you add in the headers and 
the ws-* interoperability mess; perhaps that's a namespaces 
counterexample?), and the content is in some other namespace.  That 
namespace defines its own rules.  You can't create a "carrier" 
namespace without the ability to say something about the content 
carried; HTML5 is a rather brilliant example of how limited such 
content would be if Powers That Be had to approve every message dialect.

Several XML dialects are designed for inclusion in other dialects--SVG, 
MathML are obvious ones.  XPath is an interesting case: it's not an XML 
dialect, but does need to be able to navigate arbitrary dialects.  
Compare the rigidity and complexity of CSS selectors for a 
counterexample.  If XML namespaces weren't such a horrible muddle, 
there would probably be more such dialects (and less resistance from, 
for instance, HTML proponents, to adopting the technique).

"Microformats" are an example where namespaces would be valuable, but 
since microformats are typically HTML-based, instead the designers are 
typically forced to contort a limited set of elements and attributes 
into unnatural shapes to carry the message.  Sure, you and I can agree 
that "<abbr class="key 42">moltuae</abbr> is an encoding for the 
meaning of life, the universe, and everything, but it's ... somewhat 
non-obvious, shall we say.  Providing a means of extensibility would 
enable, in HTML 5, microformats (which are probably not intended for 
display in the browser, but which are nonetheless valuable to their 
intended users).

On a side note ... someone, I think it was Jim Tivy, suggested in an 
earlier message that attributes ought to be in the default namespace.  
I would suggest that that's not a good idea.  If you think of 
attributes as having a "namespace" scoped by their containing element, 
things are a lot more clear.

The "no-namespace" or "global" namespace (xmlns="") is where elements 
live if they're not assigned to a namespace.  It should be obvious that 
if you have multiple dialects from different authorities competing for 
names in that namespace, you're going to lose, probably quickly.  The 
same is not true of attributes; attributes in "no namespace" are scoped 
by their parent element--a single authority.

<p class="important">Blah</p> current state, html as default namespace
<html:p class="important>Blah</p> current state, xmlns:html=html 
namespace
<html:p html:class="important">Blah</p> proposed change.  take 
attributes out of their parent's namespace and into the default 
namespace, and *every* *attribute* of every element in a non-default 
namespace now has to be prefixed, even though it's governed by the same 
authority that defined the default namespace.

The scoping of attributes to their container elements is often 
confusing to people new to XML, but it is, in my opinion, the right 
decision (given the verbosity that would otherwise be introduced).

As they stand, namespaces in XML are awkward and clumsy (needlessly so, 
as others have already pointed out, using for example the Java package 
style technique for establishing a namespace authority, which is fully 
as general as the URIs-that-aren't-really-URIs defined by the 
namespaces spec), but not broken ... until you encounter prefixes in 
content, at which point ... it's broken.  Is it broken because of 
namespaces, or because of namespace prefixes in content?  Well, given 
the choice of (uselessly verbose and special-character-studded) URIs as 
the namespace identifier, it's hard to demand that they be replicated; 
lots of folks are willing to complain about the replication of the 
prefix "aliases" anyway.  Clark notation, after all, would solve the 
problem ... but hasn't been widely adopted, and I think for exactly 
that reason.

Amy!
-- 
Amelia A. Lewis                    amyzing {at} talsever.com
"How does one hate a country, or love one? ... What is love of one's
country; is it hate of one's uncountry? Then it's not a good thing. Is
it simply self-love? That's a good thing, but one mustn't make a virtue
of it, or a profession."
                -- Therem Harth rem ir Estraven

_______________________________________________________________________

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-dev-unsubscribe@l...
subscribe: xml-dev-subscribe@l...
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php



transparent
Print
Mail
Like It
Disclaimer
.

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.

.
.

transparent

transparent