XSchema Spec, Section 3, Draft 1 (Namespaces)

[james anderson]

as the comma in the statement below well indicates, the phrase was taken out
of a larger context. one in which the objections were addressed, if not resolved.

John Cowan wrote:
> 
> [that i] scripsit:
> 
> > as noted above, syntax would not be sufficient. in any case, a name encoded as
> > a string must, at some point, become a universal identifier.
> 
> Agreed.
> 
> > it makes no sense
> > to delay this operation,
> 
> It makes every sense to delay this operation until we know just which
> attribute values represent names.  Blindly interning every attribute
> value just in case it's a name, and worse yet, assuming that every
> attribute value of the form foo:bar *is* a name, is inefficient
> and perhaps incorrect.

i attempt to pursue substantive discussions in the venue. a counter argument
should at least be a response to the points actually made in my note
(http://www.lists.ic.ac.uk/hypermail/xml-dev/9807/0031.html). i
would welcome a considered response, but find little value in counter claims
lodged against fictitious attributions.

...

to recount the issues:
1. as i illustrated in my notes on the "attributes with intent" thread
(http://www.lists.ic.ac.uk/hypermail/xml-dev/9807/0085.html), an
application process need know neither the value of a prefix nor, in fact, even
the literal value of an uri in order to carry out its tasks.
2. given that this information has no value to the application, the
application should not be burdened with it. this goal is achieved by
interning the attributes known to be names as a part of the decoding process.
3. as the goal of qualifying names is to distinguish "similar" names, i've
been presuming that they will be used as lookup keys. as soon as i've done one
definition lookup based on the string values of the uri and the 'local part',
i could well have interned the name.
4. the question which remains is whether there is sufficient information at
the point when the document is decoded to determine which attribute values are
intended to be interned as names.

it is my impression that any standard-based application will know which attributes
denote names at the point where the document is decoded. while in general an
application may not have a standard, the encoding application will know which
attributes contain names when it generates the document, and could well
declare them coincident with the namespace declarations.

the former case applies in domains such as enabling architectures, xlink, or
xschema itself.
in the first instance - enabling architectures, for example, taking the
"architecture support variables" from mr megginson's note on architectural
forms as the starting point, the values of (ArcFormA, ArcNamrA ArcSuprA
ArcIgnDA ArcDocF, ArcBridF, and ArcOptSA) would be interned. where the
attribute is a mapping attribute, the target attributes would also be interned.
in the last instance - xschema, many of the nmtoken attributes should always
be interned. for example AttDef.name. for others, the decision can be made
only during the decoding process. for example, EnumerationValue.value depends
on the presence of sibling elements (ID, IDRef, IDRefs, etc). 
other attributes, such as Notation.name could be interned as well, even though
they are never qualified.

...

this discussion (namespaces in general) gives me the willies. it's like i'm
sitting in the passenger seat of a spanking new 500c screaming down the
freeway. in the middle of rush-hour. nice stereo, leather, a/c. sounds more or
less ok. but for the fact that the driver has the pedal to the floor and
refuses to change lanes - 'cause there's nothing in the owners' manual that
says that that's what one uses a steering wheel for...

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