[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: What's wrong with namespaces? Some observations and sugges

  • From: Dimitre Novatchev <dnovatchev@gmail.com>
  • To: Amelia A Lewis <amyzing@talsever.com>, xml-dev@l...
  • Date: Sun, 5 Dec 2010 09:55:56 -0800

Re:  What's wrong with namespaces? Some observations and sugges
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]


PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.