[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] 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! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|