[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
Re: [xml-dev] What's wrong with namespaces? Some observations and suggestions
- From: Dimitre Novatchev <dnovatchev@gmail.com>
- To: Amelia A Lewis <amyzing@talsever.com>, xml-dev@lists.xml.org
- Date: Sun, 5 Dec 2010 09:55:56 -0800
Amelia,
Here are my answers:
> 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?
Either, which means that everybody will use the latter for convenience.
Why is this so? Because in a well-formed XML document there is only
one possible closing tag at any moment (we cannot have two or more
same-level tags open at the same position).
Thus, in the ending tag we can use only a minimal right-substring of
dot-delimited tokens of the start-tag, and in this example it is the
string "html".
>
> 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 ?
>
In case there is a collection of namespaces available in the static
context and only one of them (say, org.w3c.html) ends with ".html"
then an XPath-N expression:
//:~html.p
would be equivalent to:
/descendant-or-self::node()/:org.w3c.html.p
On the other side, if more than one namespace exists in the document
with string value ending in ".html", then:
//:~html.p
would select all elements in the document that belong to a namespace
whose string value ends with ".html".
Anyone having problems with this?
--
Cheers,
Dimitre Novatchev
---------------------------------------
Truly great madness cannot be achieved without significant intelligence.
---------------------------------------
To invent, you need a good imagination and a pile of junk
-------------------------------------
Never fight an inanimate object
-------------------------------------
You've achieved success in your field when you don't know whether what
you're doing is work or play
On Sun, Dec 5, 2010 at 8:47 AM, Amelia A Lewis <amyzing@talsever.com> wrote:
> 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"]
>
> _______________________________________________________________________
>
> 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@lists.xml.org
> subscribe: xml-dev-subscribe@lists.xml.org
> List archive: http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>
>
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
