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

RE: Registered Namespace prefixes

• To: "'W. E. Perry'" <wperry@f...>
• Subject: RE: Registered Namespace prefixes
• From: Jeff Lowery <Jeff.Lowery@c...>
• Date: Wed, 26 Feb 2003 12:54:01 -0800
• Cc: "'xml-dev'" <xml-dev@l...>

> From: W. E. Perry [mailto:wperry@f...]
> Jeff Lowery wrote:
> 
> > The advantage of a registry is that prefixed names become 
> universal names when
> > prefixes are registered.
> 
> But do the things which they *name* become thereby universal 
> (which is, after
> all, the effect which we are trying to achieve here)?

That's a far tougher assignment, but one which Namespaces in XML doesn't
address, either.  It only gives a unique namespace (if the URI is unique;
and that's not guaranteed, either) for names in a document.  But there could
be same-named and namespace (but different) components in a different
document.

> > There are no scope issues.
> 
> On the contrary, what remains are nothing but scope issues. 
> The intent of
> namespaces is to disambiguate names by properly assigning 
> them to semantic
> domains, 

Uhhh, no.  You can't mandate intent through syntax.  You can only make good
intents easier and malintent harder.

> But from the point of view of the processing nodes 
> which will act upon
> the documents in which those names are found, the only 
> accurate (or useful)
> assignment of names to domains is the assignment to 
> particular processing from
> among the choices which might be invoked at that node. 

okay.

> Ultimately, from that
> local point of view, the correct assignment of any name is to 
> the processing
> from which useful results have been produced in processing 
> analogous names and
> their data content in the past. And, of course, nothing could 
> be more local and
> idiosyncratic than such a database of experience and its 
> (always local)
> outcomes.

I really don't see the registry proposal as a database proposal.  I see it
as a method of ensuring uniqueness among short name-character strings.
There's no semantic meaning behind the proposal.  Semantic meaning may be
attached, the same way that such meaning can be attached to a Namespace
identifier. But such semantics are not mandated.

> I have 'namespaced' since 1999 by the provenance of XML 
> documents and by the
> structure in which names are found in them. In my experience, 
> a processing node
> has a miserable first week as it learns what to expect in 
> documents from each of
> its sources. After that, non-recognition of names drops to 
> well below 0.1% and,
> except for the spike when new data sources come online, runs 
> consistently far
> below the level at which it would be economic to adjust or 
> optimize the
> namespacing portion of processing.

I'm looking to cover two scenarios:

1. mechanical slicing and dicing of documents (i.e., without any deep
internal representation).  This can only be accomplished by making the
prefix:localname pair stand on its own, IMHO.

2. avoidance of document models where prefix/namespace id assignment
information must be maintained. That's overhead.  Prefix:localName is easier
to maintain because the two can be considered inseparable.  They become the
component identifier.

No semantics, no semantics, no semantics.   If I say semantic and registry
in the same sentence, flame me but good. Starting now. :-)

• Follow-Ups:
  • Re: Registered Namespace prefixes
    • From: Joe English <jenglish@f...>
  • Re: Registered Namespace prefixes
    • From: "W. E. Perry" <wperry@f...>

• Prev by Date: Re: The subsetting has begun
• Next by Date: Re: Use cases for parsing efficiency (was Re: Parsing efficiency? - why not 'compile'????)
• Previous by thread: Re: Registered Namespace prefixes
• Next by thread: Re: Registered Namespace prefixes
• Index(es):
  • Date
  • Thread