[
Lists Home |
Date Index |
Thread Index
]
> From: W. E. Perry [mailto:wperry@fiduciary.com]
> 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. :-)
|
