XML.orgXML.org
FOCUS AREAS |XML-DEV |XML.org DAILY NEWSLINK |REGISTRY |RESOURCES |ABOUT
OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] What's wrong with namespaces? Some observations and suggestions

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]


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS