Re: more QName madness
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!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format