xml-dev - My comments on the XLink and XPointer drafts

[John Cowan <cowan@locke.ccil.org>]

I sent these to Maler & DeRose on 1998-03-30, and have so
far received only an acknowledgement.  I now post them to the
listfolk for their edification and comments.


Title:          Cowan's Comments 1-8 on XLink/XPointer Drafts
Source:         John Cowan <cowan@ccil.org>
Primary Author: John Cowan (no W3C affiliation)
Date:		1998-03-25
Status:         Expert contribution
Action:         For the consideration of W3C XML WG
References:     Draft WD-xlink-19980303, Draft WD-xpointer-19980303
Distribution:   W3C XML WG, XML-DEV, and all interested parties


The following comments are offered to the W3C XML WG for
consideration.  Since I do not currently have access to the mailing
list, I would appreciate a direct reply to <cowan@ccil.org> with the
disposition of these comments.  [Replying to XML-DEV is okay too.]

For reference, comments are labeled
"Cowan-<draftname>-<status>-<serialno>" where <draftname> is "XLink"
or "XPointer" and <status> is "Editorial" or "Substantive".  Serial
numbers are unique throughout.  Substantive comments are listed in
roughly increasing order of complexity.


Cowan-XPointer-Editorial-1: Origin Clarification

Section 3.2.2, on the "origin" keyword, uses the phrase "the location
source is the sub-resource from which the user initiated traversal".
In the case of a generalized link, it is not clear whether this refers
to the actual link element, or the locator sub-element where the
XPointer is physically located.

It seems to me that the actual link element, which is typically
directly visible to the user, is what is meant; in either case,
clarification is in order.


Cowan-XLink-Editorial-2: Role Information Non-normative

Sections 4.1.2, 4.1.3, and 4.1.4 should make clear that role
information is non-normative, like title information, by adding some
such sentence as: "XLink does not require that application software
make any particular use of role information."


Cowan-XLink-Editorial-3: Additional Attribute-Remapping Example

An additional example should be provided in Section 7 for attribute
remapping.  The given example does not clearly state why remapping is
required, as the existing "title" and "role" attributes of the
TEXT-BOOK element are at least formally suitable for XLink.

An example using one of the more syntactically limited attributes such
as "show" in an incompatible way would clarify the purpose of
attribute remapping.  Here is a sample declaration:

<!ELEMENT WIDGET ANY>
<!ATTLIST WIDGET
	position	CDATA		#IMPLIED
	class		CDATA		#IMPLIED
	show		(SHOW|HIDE)	"SHOW"
	...
>

Using this element as a link would require remapping the XLink
"show" attribute to something else.


Cowan-XLink-Substantive-4: "xml:attributes" Should Be NMTOKENS

The "xml:attributes" attribute is defined as CDATA, although its
content is essentially a list of alphanumeric strings separated by
white-space.  Declaring it as NMTOKENS would permit validating XML
parsers to take a first cut at making sure the syntax was correct.
[Previous sentence has been altered to remove an error of mine.]


Cowan-XLink-Substantive-5: All Attributes In XML Namespace

Attribute remapping could be avoided altogether by using attributes
solely from the "xml:" pseudo-namespace, namely "xml:href",
"xml:inline", "xml:role", "xml:title", "xml:show", "xml:actuate",
"xml:behavior", "xml:content-role", "xml:content-title" and (if other
comments are adopted) "xml:link-title" and "xml:link-role".

This change would increase verbosity, but we already have the
precedent of the "xml:lang" attribute, which (unlike "xml:link"
and "xml:space") can be expected to often appear explicitly in
start-tags.


Cowan-XLink-Substantive-6: New "link-title" Attribute

The current draft allows titles to be specified for any of the
resources of a link, whether local (through the "content-title"
attribute) or remote (through the "title" attribute).  However, there
is no way to specify the title of the link itself.

Both links and resources can be given roles, and in that respect are
treated on an equal footing.  It seems to me conducive to uniformity
to treat links and resources equally in the matter of titles as well.

My proposed attribute for this purpose is "link-title", which would be
defined as part of the parameter entities "link-semantics.att"
and "simple-link-semantics.att" in Section 4.1.2.


Cowan-XLink-Substantive-7: Ambiguous "role" Attribute

The attribute "role" is used in two different ways within XLink.  In a
simple link, "role" means the role of the content, whereas in an
extended link, "role" means the role of the link itself.  There is no
way to mention the role of the link itself within a simple link, due
to this conflation.

I propose that the second usage be changed to employ the attribute
"link-role".  This name is analogous to "content-role", and is usable
in both simple and extended links.  The "role" attribute would then be
reserved for simple link elements and locator elements, and would
always refer to the role of the remote content.

Section 4.1.2 would be affected by adding the attribute "link-role" to
the parameter entity "link-semantics.att" and removing the attribute
"role".  The parameter entity "simple-link-semantics.att" would become
unnecessary, and all references to it (e.g. in Section 4.2) would be
changed to "link-semantics.att".


Cowan-XLink-Substantive-8: "inline" Attribute Unnecessary

I propose that the inline/out-of-line and simple/extended link
distinctions be unified according to the following rule: all simple
links are inline, all extended links are out-of-line.  Making this
change will promote simplicity (making the job of link readers easier)
with very little cost to flexibility.

Section 4.2 concedes that simple out-of-line links are "uncommon";
they are essentially links with only one resource.  Since the physical
location of such a link is irrelevant to its meaning, finding it
entails the same difficulty as finding extended links.  The syntax

	<one-ended-link href="..." .../>

can be readily converted to:

	<extended-link ...>
		<locator href="..." .../>
		...
	</extended-link>

Similarly, extended links that need to reference their own content as
a resource can readily do so by adding an extra locator element as
follows:

	<inline-extended-link ...>
		...
	</inline-link>

becomes:

	<general-link ...>
		<locator href="#origin()">
		...
	</general-link>

(Depending on the resolution of comment Cowan-XPointer-Editorial-1,
the XPointer might need to be "#origin().ancestor(1)".)

This would entail, however, that locator elements within the
extended link would appear to be part of its resources.  Link-following
applications would need to be aware of this point and implicitly
ignore locator elements.  Alternatively, XPointer syntax
could be enhanced, if necessary.

Adopting this change would require various changes to the draft
wording, including but not necessarily limited to:

Section 4: change "usually inline" to "always inline" and "either
inline or out-of-line" to "always out-of-line".

Section 4.1.2: remove references to the attribute "inline" from the
prose and the parameter entities "link-semantics.att" and
"simple-link-semantics.att".

Section 4.2: remove the explanation of out-of-line simple links; some
of the content can be moved to the end of Section 4.3 as an
explanation of what extended links with a single locator mean.

**END OF DOCUMENT**

-- 
John Cowan	http://www.ccil.org/~cowan		cowan@ccil.org
	You tollerday donsk?  N.  You tolkatiff scowegian?  Nn.
	You spigotty anglease?  Nnn.  You phonio saxo?  Nnnn.
		Clear all so!  'Tis a Jute.... (Finnegans Wake 16.5)

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