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

Re: Pragmatic namespaces

  • From: Micah Dubinko <Micah.Dubinko@marklogic.com>
  • To: Amelia A Lewis <amyzing@talsever.com>
  • Date: Sun, 2 Aug 2009 21:40:18 -0700

Re:  Pragmatic namespaces

On Aug 1, 2009, at 7:43 AM, Amelia A Lewis wrote:
>
> In fact, in the xforms example, below, using "input", it is suggested
> that the corresponding HTML element must then become "html.input".

The proposal wasn't very clear in this area. I will fix this.


>
>> 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. ...
>
> Potentially problematic for any dialect that already uses dotted-on
> names.  However, the chance of ambiguity is minimal.  If there's
> com.example.project, com.example.id, and com.example.project.id (the
> latter being a reference to an id child of a project, tagname
> project.id), it remains unambiguous.  I see little chance of
> reverse-DNS dot-ons creating a clash between separately administered
> namespaces, which is the crucial point.
>
> Another option: double-dot: com.example..project, com.example..id,
> com.example..project.id.

How often do dotted element names come up in existing HTML or HTML- 
like XML? In the (presumably rare) cases where this does happen, would  
interpreting them as pragmatic namespaces cause problems?


> I'd recommend simply removing the "root only" restriction.  "using"
> acts within the scope of the element it is an attribute of.

I could probably be convinced of this, though I haven't been so far.  
When talking about merging XML documents, there's already a  
requirement to preserve a single root element, which makes certain  
operations more difficult, but has advantages in making documents more  
consistent. I would argue that something similar is in play here: the  
root-only restriction makes a few things more difficult, but many  
common things easier. A generic, works-for-all-of-XML solution  
probably needs it. A more limited scope of HTML-like documents may  
allow a simpler solution. I am very receptive to evidence to the  
contrary.


>> 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
>
> I just don't like this.
>
> For one thing, using "xml." as a prefix is illegal in XML.  Avoid.

Over a beer it might be fun to argue about reserved names and future  
versions of specifications, but I suspect you're right.
It might be possible to make HTMLn grok attributes starting with xml:,  
but that's a different discussion. I think the "xml" grandfather is  
unnecessary for this proposal, and will remove it for the next round.

>
> This is, in effect, a prefix registry.  It has all the freedom from
> politics, agility, flexibility, and consensus support of any other
> registry (did my sarcasm tags show up?).  I'd recommend simply  
> dropping
> this.

By using "grandfathering" language, I am trying to distance this from  
a regularly-maintained repository. There exists a smallish set of  
namespace URIs that 1) are used today in HTML-like documents and 2)  
need to be properly exposed (namespace-wise) to the DOM. I can't  
imagine a reasonable proposal that doesn't either grandfather or force  
pages to restate well-established mappings. Future vocabularies might  
define namespaces in terms of this proposal, but realistically seem to  
need something else, beyond the scope of this proposal (or is it?),  
maybe XIN or what you mention below.

Try this thought experiment: If, say, svg and math prefixes were  
somehow already baked in to the XML+XMLNS specifications, would the  
present situation be better or worse for authors? For XML?


>
> However, that brings up an issue, to my mind.  How would one indicate
> the MathML namespace using only a reversed domain name?
>
> We have a number of existing namespaces.  Let's transform those to
> reverse-dns dotted-on forms.  This is slightly more verbose, but it
> would work:
>
> org.w3.www.1998.Math.MathML

I've thought about this, though that URL looks like it's pushing the  
edge of memorability. It's certainly better than the corresponding  
URL. But that raises another issue you mention, the "http://" part of  
the URL doesn't round-trip. How many non-http namespace URIs are used  
in HTML-like XML documents?

One thought is some prefix/suffix that maps to "http://" or possibly  
the all-too-common "http://www.w3.org/" yielding names like
w3.1998.Math.MathML

Or strictly adhering to specific-to-general ("reversed") ordering
h.org.w3.www.Math.MathML
though that gets into separator issues, as you note. I have to say I  
like the first one more.

A more grandiose thought is something Tantek has talked about often,  
of making a unified W3C namespace. This is partial grandfathering of  
the year portions of the URL strings (which would need to be stored in  
a table somewhere) and combined with the above, could yield names like

w3.Math.MathML

 > .. lots of good stuff snipped...

>
> Care to hear a suggestion that reeks of SGML minimization, but that
> might make these pragmatic namespaces more acceptable?
>
> Permit an element to be closed without its "prefix".  It's something
> I've wished for in XML, for that matter:
>
> <com.example..project>la, la</project>

Seems reasonable, especially compared to some of the scary parsing  
rules already in place.


>
>> 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.
>
> Ick.
>
> That suggests that the "prefix registry" is central to acceptance by
> browser makers, while I find it the least convincing part of the
> proposal.

It seems that the current proposal for dealing with svg & math is an  
even bigger hack. Choosing the least among evils is, well, the  
pragmatic thing to do. :-)

-m




[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.