QNames minority opinion (really sent by Eve)

I had a computer problem while at the XML Plenary/Schema meeting, and am borrowing Murray's account to send this minority opinion on the use of QNames in XLink attribute values.

	Eve

			*		*		*

Minority Opinion on the Use of QNames in XLink Attributes
Eve Maler, Sun Microsystems

*Introduction

XLink allows QNames (namespace prefix-qualified names) in three of its attributes: role, show, and actuate.  It also chooses to define a particular qualified value for use in the role attribute.  We believe that the use of the QName/namespace mechanism in XLink V1.0 is too expensive and does not achieve very many benefits; thus, we advocate eliminating this mechanism in V1.0.

*QNames in Attribute Values in General

The mechanism involves allowing simple tokens to be qualified with a namespace prefix, where the prefix has been properly defined through xmlns attributes.  Such a mechanism is best reserved for cases where some other XML document is being operated on in a "meta-level" fashion, as is the case with XSLT.  We see only downsides to using it in XLink:

- It requires XLink applications to duplicate/mimic some of the functionality of a namespace processor, such as parsing out the prefix and local-part fields from a value, and validating the prefix.  While some namespace processor modules may have been written in a way that enables reuse, many XLink implementors are likely to reimplement this functionality themselves.

*QNames in Role Attribute Values

We originally applied the QName mechanism to the role attribute so that the generic extended-link element could serve double duty as a specific kind of extended link: an external linkset.  By allowing prefixing of the role value, we could safely avoid invading the user's "token space."  The idea also had appeal in the general case, because we had received requests to make role values universally unique.  We see the benefits and problems as follows:

+ Uniqueness of the role value allows you to unambiguously define a standard semantic, which encourages sharing (a la RDF) of people's link semantics.

+ The technique is one way to solve the external linkset markup problem.

- The technique is overkill for solving the external linkset problem, since we want only one specific semantic, not a whole set.

- Since XLink is a generic specification, it should not impose specific semantics on top of its first-class constructs.  If external linksets are an integral part of XLink, they should be first-class constructs too. 

- The QName technique doesn't work very well because linksets shouldn't, as it turns out, inherit all of the features of a generic extended link (such as arcs and some attributes).  Making it a first-class construct allows us to subset, in a clean way, the features that extended links have to offer.

Recommendation: Use a different mechanism for providing external linkset markup, such as a separate XLink type value.  Allow only NCNames (unqualified names) as role values for V1.0.  If we decide later to change it to QNames, legacy documents will still work.  Post-V1.0, consider breaking up role values by the two functions they perform: arc labels (which can safely be NCNames, probably) and semantic labels (which are best made into URIs directly, a la RDF).

*QNames in the Behavior Attribute Values

The QName mechanism allows people to extend the official XLink behavior attributes (show and actuate) by adding values of their own design, without using up some of a shared "token space."  This benefit does not make up for the cost in specification prose and application conformance:

- It gives an appearance of extensible interoperability, but just like the old behavior attribute whose value was entirely unspecified, it actually provides no advantage regarding interoperability.  Other than the four show values and the three actuate values, XLink specifies no normative behavior for any other values.

- Allowing novel values for show and actuate doesn't add anything to the ability of language designers to specify link traversal behavior, because they are already free to add their own attribute and elements.  The QName mechanism merely gives them a less functional way of doing the same thing -- less functional because it requires them to buy into our show/actuate axis (which we're not convinced is optimal, as evidenced by some of the issues we're saving for V.next).

Recommendation: Provide only a closed list of simple tokens as the allowed values of show and actuate, just as we have done for the type attribute.  The attribute is in our namespace, and we have every right to control all aspects of its allowed values.

Received on Thursday, 3 February 2000 12:31:38 UTC