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

Re: more QName madness


qname alternatives
John Cowan wrote:

> I am comparing the use of URIs *in documents* (not to identify documents) with QNames
> in documents.  QNames are just a minimization practice and concession to the SGML name
> rules, but semantically they are the same as URIs.  I am not here talking about the
> use of URIs to retrieve or name documents.

But I am, and am contrasting that with the very different effect of embedding such URIs
or QNames  as document content. (We will leave aside for the moment the defensibility of
your claim, which others are challenging, that those URIs and QNames are isomorphic.)

> The local-naming UUCP scheme did *work*, after all; it simply wasn't as convenient as
> the domainist one.

In this discussion I am stating no preference between these alternatives. Again, I am
contrasting the use of any such scheme for addressing or naming with its effects when
embedded as document content.

> Every word of this is equally applicable to the use of postal codes, telephone
> numbers, language tags, and a thousand other globally assigned names in documents; yet
> Real World documents are riddled with them and could hardly do without them.

Absolutely. You could construct with e.g. postal codes the same case that I am trying to
examine here. On the header of the sheet within the envelope is printed--as document
content--the sender's fixed understanding of his own postal code (within a
quasi-universal post coding scheme which he has accepted a priori, etc., etc.). In the
postmark on the outside of the envelope is the postal code revealing the address, or
context, from which the message in fact has been sent. Which of those is useful (or how
either of both may need to be combined with other data) for the particular processing
which the recipient may need to perform is inherently unknown to the sender. As a
specific example, whether or how the recipient might use the post code embedded in the
document to disambiguate the semantics of some noun appearing in that document from the
semantics of the same noun coming from an apparently different source cannot be known to
the sender except as the effect of a priori agreement which that sender is confident
that the recipient adheres to. Such confidence is inimical to the nature of the
internetwork, and where it can be achieved at all is realized only at the cost of the
global scalability which the internetwork topology was designed to facilitate.

> The mere use of namespace names says nothing about the semantics of those names, any
> more than the mere use of unprefixed names says anything about *their* semantics.

Oh, how I should like to believe this. Unfortunately it unravels rapidly in the real
world--your example below being only the tip of an iceberg. In the same minds which want
to disambiguate via static 'namespaces' the semantics of a noun used in one context from
those of the same noun used in another, it seems to be a hard-wired assumption that
*particular* semantics can be conveyed by the use of a given noun with a specific
namespace. This assumption is why XML messaging designs become so rapidly designs for
RPC. On the other hand, if we start with the converse assumption--that semantics are not
conveyed in the transmission of a document from sender to recipient--we will quickly
lose interest in namespacing the nouns within document content, precisely because we
understand that the point of view of the sender thus expressed is is not binding upon
the recipient and for the purposes of the recipient's processing of the document is
likely to be contradicted by the specific provenance revealed in obtaining that document
through the internetwork.

> (I realize that XML Schema-heads think they can associate a single unique semantics to
> every namespace-qualified name, but this should not influence the view of namespaces
> as such.  Abusus non tollit usum.)

Respectfully,

Walter Perry



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.