Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: XSchema Spec, Section 3, Draft 1 (Namespaces)
 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@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...) 
|
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
|
|||||||||
