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

Re: Namespace questions

  • From: james anderson <James.Anderson@m...>
  • To: "xml-dev@i..." <xml-dev@i...>
  • Date: Thu, 02 Jul 1998 21:04:14 +0200

Re: Namespace questions
David G. Durand wrote:
> 
> In brief answer to your continuing comments on this issue, the
> namespace spec currently does _not_ make the restrictions

i believe mr. durand may have misunderstood the context of my remark on
"effective qualification". (was it that passage?) while the notion of
"effective qualification" may not appear in the wd, it applies nonetheless to
the application domain in which the question was posed.

> nor
> have the implications that you would like.

we disagree. you may not see the implications. i do.
i understood the question to have been posed with respect to an application
which is to operate on data of which the encoded form may contain qualified
names, and where the prefixes may vary from document to document. such an
application is going to require mechanisms of the kinds i describe in order to
produce predictable results.

there will be many such applications. i leave the implications open.

> It allows applications
> that _wish_ to, to disbamiguate names based on a prefix. It does

i trust that the context of the discussion leaves no doubt, that that is the
kind of application with which my remarks have been concerned.

> not make _all_ names qualified,

for which applications, even names which conform to "NCName"'s in their
encoded form will need be comparable with those which are qualified. if one
does not identify the region of the namespace which is implied by the lack of
a prefix when decoding, the results are unpredicatable.

> nor does it affect DTD or link
> processing, or any other process that already uses GIs.

i don't understand this.

since both of these processes depend on name identity it's hard to see how a
standard which specifies how names are encoded does not - at least in terms of
the appearance of the data upon which they operate -  affect them.

one can't very well send a server an uri which contains an xpointer in its
fragment identifier and then say "hey, now you figure out what the prefixes
were supposed to mean. good luck."

> The kinds of things you are advocating may be useful (and they may
> not), but they are currently not on the table, because they have so
> many implications for the rest of XML.

which is unfortunate; and exactly why i discuss them.

and please take my remarks as "reporting" rather than "advocating".
i'm just recounting what i've had to do to fill out the standards to get
things to work.

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i...
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@i... the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@i... the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@i...)


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.