Re: QNames minority opinion (really sent by Eve)

Yikes!  I didn't realize my posting was formatted so badly.  Hopefully this 
version will be easier to read.  Also, the version below incorporates a 
small editorial change that I wasn't able to address before, because of the 
technical problems mentioned previously.

	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, but not here.  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.

--
Eve Maler            Sun Microsystems
elm @ east.sun.com    +1 781 442 3190

Received on Friday, 11 February 2000 16:46:29 UTC