[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
Re: [xml-dev] What's wrong with namespaces? Some observations andsuggestions
- From: Amelia A Lewis <amyzing@talsever.com>
- To: Michael Kay <mike@saxonica.com>
- Date: Sun, 5 Dec 2010 11:47:21 -0500
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]
