[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: What's wrong with namespaces? Some observations andsuggest
A question: On Sat, 04 Dec 2010 23:24:22 +0000, Michael Kay wrote: > Elements should have simple (string-valued) names, using hierarchic > naming to achieve uniqueness, and context-sensitive abbreviation to > achieve conciseness. It should always be legitimate to use the full > name if abbreviation is not wanted. > > Hierarchic naming: for example an element might be called > :org.w3c.html.table. > > Abbreviation: this might be abbreviated to "table". How is the > abbreviated name resolved? Using the hierarchic name of the parent > element. So the outermost element gives the full name > > <:org.w3c.html.html> > > and inner elements can use abbreviated names if they are in the same > "namespace": > > <:org.w3c.html.html> > <head> > <title>...</title> > </head> > <body> > <:org.w3c.svg.svg> > <rectangle> > .... > > Of course, this is hopelessly incompatible. Or is it? I've been thinking about this since I first saw the post. So I want to ask the question: is this incompatible? Suppose that we go ahead and specify this, defining a mapping/transformation mechanism (per Michael's email) (for HTML only?). Add, at the top of the document: <?name-of-spec ?>. Existing parsers would have to treat this is as non-namespaced. Anything wanting a Namespaces in XML-compliant version could use a standard stylesheet. In that case, this could be adopted *now* by convention, could it not? The parsers wouldn't choke. Validators would, if given the base document; that could be handled by handing this over to an XSLT processor first, triggered by the presence of the processing instruction (but could a current XSLT processor handle names of this format?). Conversely, a workflow based on this rationalized namespace could use absence of a processing instruction to trigger the other stylesheet, rewriting a Namespaces in XML-compatible instance to a rationalized namespaces instance. Problem: it seems likely that current XSLT processors couldn't handle the transformation, as they're heavily reliant on the existing namespace technology, and couldn't generate or accept the rationalized form (due to the initial colon). Is that true? Problem: a standard transformation is easy for HTTP (probably the 80% case), but what about all those other bizarre URIs? The urn scheme, for instance (which has some significant use, I know). Can we add the scheme part to the transformation for those URIs and achieve disambiguation? Dimitre's just posted about some minimization, in instance documents and XPath. Separating those concerns a little: Problem: given <:org.w3c.html.html>, is the proper match </:org.w3c.html.html>, or </html>, or either? Problem: in XPath, can we follow the pattern of the instance for abbreviation? Thus: /:org.w3c.html.html/body/p ? In context, that's more or less (well, more less than more, given nesting of p elements in other things, but play along, 'kay?) equivalent to //:org.w3c.html.p ... or could we say //p ? Amy! -- Amelia A. Lewis amyzing {at} talsever.com But pain ... seems to me an insufficient reason not to embrace life. Being dead is quite painless. Pain, like time, is going to come on regardless. Question is, what glorious moments can you win from life in addition to the pain? -- Cordelia Naismith Vorkosigan [Lois McMasters Bujold, "Barrayar"]
[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
|