2000-01-19 WD: WEK Comments

Here are my comments on the 1/19/2000 Draft:

General:

I like the design overall. I didn't find anything I considered to be a
fundamental problem (no surprise there). I like the arc mechanism--I
think that's a clever way to solve the traversal rule problem. The
extended link set stuff seems to be fine.

G.1. It would be ideal if the spec provided a "type" value that can be
used for document elements to signal that the document is an "XLink
document" (meaning that it might have links in it), e.g.
"type="xlinkdoc". This is all that is missing in order to formally
define XLink as an architecture using ISO/IEC 10744:1997 mechanisms.

G.2. I would like to see an informative appendix that shows how to use
XLink as an architecture. I would be happy to draft this appendix (I'll
do the work in any case for my own use if for no other reason).  Given a
document element form, XLink can also be formally derived from the
HyTime architecture, which might be another useful informative annex (I
would not expect the deriviation to be normative, although it would
please me to have it).

G.3. I could not find a formal definition of what the abstract data
model for a link is. I think this is required for a rigorous spec. In
particular, are links with exactly one resource meaningful in XLink? Is
there a formal notion of link type?  I could not find clear answers to
either question.

G.4. The lack of a formal definition of link type is a problem. The lack
of it will lead to serious ambiguitities in documents or unnecessarily
constrain the syntactic configuration of simple links. Without a formal
definition of link type, it is not possible for XLink and HyTime share a
common abstract data model for links, which they would otherwise do. 
[See comments WRT simple below.]

Specific:

3.1 Extended Links

If I understand the extended link design, there is a fundamental
difference between HyTime and XLink such that in HyTime, a linking
element can be one of its own local resources, while in XLink it cannot.
I'm wondering if XLink needs to impose this constraint?

Modulo this difference, the XLink extended form maps to the HyTime
"varlink" (variable link) form, e.g.:

<mylink 
  HyTime="varlink"
  linktype="mylink"
  anchrole="role-1"

  xlink:type="extended"
>
<l HyTime="anchspec"
   anchrole="role-2"
   loctype="xlink:href queryloc uri"

   xlink:type="locator"
   xlink:role="role-2"
   xlink:href="#target-1"  
/>
</mylink>

>From a HyTime point of view this is a two-ended link, with one end being
the "mylink" element node (playing the anchor role "role-1") and the
other end being the element with the id "target-1" (playing the anchor
role "role-2").  Note that HyTime defines two attributes, linktype and
anchrole, that clearly distinguish the purpose of the element as a link
definition (linktype) and as a resource participating in the link
(anchrole). I think it would be good for XLink to allow these same
distinctions [See below].

>From an XLink standpoint, this is an invalid link because it only
specifies one resource (there is no local resource and XLink requires at
least two resources (or at least it should--a one resource link is
meaningless)).

Of course, if XLink does not define a formal notion of link type then it
is not possible to unambiguously map the (currently implicit) XLink
abstract link model to the HyTime abstract link model. [See comments
about link type WRT to simple links below.]

3.1 Constraint: Locators in Extended Link Elements

I do not believe the requirement for extended link elements to contain
at least one locator is necessary or justified.

I think it would be better to require at least two resources, local or
remote, and leave it at that.  If I want to use extended to define a
relation between two local resources, I should be allowed to do so. 
Requiring at least one remote resource is an unnecessarily restrictive
policy and standards of this sort should not be imposing policies that
are not technically required.

3.1.1 Local Resources for Extended Links

Is the value of a local resource the resource element node or the nodes
in its content?  From the text I think it is the latter. If so, then I
think there is a problem. Shouldn't the resource element node be the
local resource? What does it mean to have a local resource with no
content? I think that most users would expect that the resource element
is the resource (and therefore might use empty elements thinking that
the element itself will be identified as the resource). [See similar
comment WRT simple below.]

3.1.4: Traversal Rules for An Extended Link

Please consider adding two more traversal options:

- No further traversal. If the resource is traversed to, no further
traversal from the resource is allowed (i.e., a "trap")
- Traversal prohibited. Explicitly disallows traversal to the resource.

Also, there is no facility for defining the traversal rules among the
members of an aggregate resource (i.e., HyTime's "list traversal"
facility)

3.2 Simple Links

The definition of simple link is inconsistent with the definition of
extended in that it implies that the link element itself is the local
resource:

"...; all its content together is the local resource of the link, as if
the content were inside a resource-type element."

That is, the simple element is a link, locator, and *resource* element
at once. This is fine, but that suggests that extended elements should
have the same option. That is, if it is formally meaningful for a simple
element to play all three semantic roles, it should be formally
meaningful for any other element to play all three roles.

In any case, there is some ambiguity about what the local resource is
for a simple link: is it the link element node or is it the aggregation
of its content nodes (if any).  I think it must be the former, otherwise
you would have many links for which the local resource would be an empty
node list, which is probably not the normal intent (and would certainly
cause problems for tools that expected there to be at least one node for
each correctly-specified resource).

Simple links are underspecified for role and link type. The role
attribute is defined as specifying the role for the remote resource.
Therefore, there is no way to clearly define the role of the local
resource of a simple link and *at the same time* define the link type
the simple link represents (if we assume that, by default, the element
type is taken as either the link type or local role name). Consider this
example from the XLink spec:

<studentlink xlink:role="student" ...>

What is the link type? What is the role played by the local resource?
Can't tell. We can guess from the element type name that perhaps it is
intended to be the link type, but maybe not? Maybe the intended link
type is something more semantically meaningful, like "class membership"
or "studies under" or "dorm assignment"? Can't tell from the example
*and XLink currently gives us no way to be complete*.

To solve this problem, there need to be two additional attributes: local
role and link type, so that I can say things like:

<studentlink 
  xlink:type="simple"
  xlink:role="student"
  xlink:local-role="class"
  xlink:link-type="class-membership">Philosophy 101</studentlink>

Of course, it would be natural to use the element type name as the link
type name, so it would be reasonable to have the effective value of
link-type default to the element type name:

<class-membership  
  xlink:type="simple"
  xlink:role="student"
  xlink:local-role="class">Philosophy 101</class-member>

But in this case, since I'm using simple and the link is therefore
inline, I probably want the element type to describe the local resource,
rather than the relationship type:

<class  
  xlink:type="simple"
  xlink:role="student"
  xlink:local-role="class"
  xlink:link-type="class-membership">Philosophy 101</class>

That is, this element now identifies mentions of classes in addition to
linking them to their members.

Note that I now have three configurations of exactly the same
relationship that provably mean exactly the same thing.

Without the ability to state the local role and link type explicitly, I
cannot have these different configuration options, nor can I use the
different options for the same relationship type.

For example, I may have different documents that need different
syntactic configurations of the same link type within the same link base
but I want to be able to search on instances of the link based on its
type and roles, e.g. "find all students that exist in a
"class-membership" relationship with the class 'Philosophy 101'".  If I
have the explicit specifications shown above then all three links are
clearly instances of the same relationship type and all will satisfy my
query.  Without them, I must assume that all three elements represent
different links (and in any case, I have no way to state the concept
"link of 'class-membership'" in an XLink context so the query is not
possible at all).

I feel that without the above, XLink will be of limited utility for any
sort of interoperable semantic information modeling (although it will
still be useful for enabling simple navigation). I also think that
people will make assumptions about how to infer the link type or local
resource role name, and those assumptions will, of course, be different
across different applications and implementing tools.

Cheers,

E.

Received on Monday, 24 January 2000 21:52:37 UTC