XLink comment and queries

[W. Eliot Kimber]

At 02:11 PM 4/23/98 -0400, Daniel Pitti wrote:

>Thus, in trying to XMLize an existing SGML DTD, I find myself wanting my
>linking elements to have both idref/s and entity/ies for use in creation
>and maintenance, and XLink attributes for exporting the same, the latter be
>created at the time of exporting. Is this sensible at this juncture? Or am
>I overlooking something?

In a previous note, I mentioned that the HyTime architecture provides a
syntax for declaring what form of addressing is being used in a given
instance.  This facility lets you be 100% clear about how to interpret the
values of attributes that you know are referential, lets generalized
software manage documents that use a variety of addressing methods, and
makes it clearer that single element types can use a variety of addressing
methods.

The facility is the "reference location address" (refloc) facility (clause
7.8). It provides two attributes that can be used on any element:

- loctype (location type), which associates referential attributes with
their addressing methods (notations)
- rflocsrc (reference location source), which associates pairs of
referential attributes to indicate that one attribute addresses the
location source for the other (e.g., book= and refid= as often used with
DynaText).

With these two attributes, you can completely characterize the referential
attributes used by a given element such that a generalized system that
implements the refloc facility and implements the addressing methods used
will be able to resolve the addresses.

XLink doesn't need to provide such a mechanism because it requires the use
of exactly one addressing method: URIs and XPointers.  However, in an
environment where you want more flexibility you do need this sort of facility.

For example, a generic linking element that can use any form of addressing,
including, but not limited to, XPointers, can be declared like so:

<!-- Declaration for a generic linking element -->
<!-- NOTE: Because this is intended for authoring, it uses SGML features
           not allowed in XML. Use of the refloc facility does not require
           any SGML-only facilities, but here they are used for convenience.
  -->

<!-- Declare use of HyTime architecture so we know what semantic 
     domain defines the meaning of the loctype attribute. 
  -->
<?IS10744:arch name="HyTime" 
   public-id="ISO/IEC 10744:1997//NOTATION Hypermedia/Time-based
Structuring Language (HyTime)//EN"
> 

<!-- Declare a hyperlink element type: -->
<!ATTLIST GenericLink
   href        -- Referential attribute, points to other anchor (resource)
                  of link. --
     CDATA
     #REQUIRED
   linktype
     NAME
     "crossref"  -- Default link type name --
   loctype
     CDATA
     #FIXED "href IDLOC" -- href attribute is interpreted as an ID
reference --
   HyTime
     NAME
     #FIXED "hybrid" -- Must be mapped to some element type in HyTime
                        architecture. Here hybrid is used for implicity. --
>

The value of the loctype attribute is a list of tupples (either pairs or
triples depending) where the first token is an attribute name, the second
token is a location type keyword as defined by the HyTime architecture, and
the third token, if required is a notation name (as shown in the next
example).  Thus, this value of the loctype attribute declares the href
attribute to be, semantically, an "IDLOC", which means that the attribute
is interpreted as though it had a value prescription of "IDREF" or
"IDREFS".  Other choices are "ENTLOC" (entity references), "TREELOC", (tree
location address), and so on, corresponding to the build-in addressing
methods of HyTime. You can also refer to non-HyTime-defined addressing
methods, as shown below.

[Note that here the HyTime architecture is being used *only* for the
loctype attribute. The GenericLink element is not declared as a HyTime
hyperlink. This is an example of using an architecture that provides a
"global" attribute. The "hybrid" element form is HyTime's generic element
that has no meaning other than HyTime-specific processing will be applied.
Thus any element can be mapped to the hybrid form in order to associate it
with the generic facilities of the HyTime architecture, such as the loctype
attribute.  You can also use this technique to characterize attributes
named "ID" as being unique IDs because the HyTime architecture says an
attribute named ID is an ID unless you say otherwise.  Because all
facilities of the HyTime architecture are optional, a processor can support
just the loctype attribute and be a conforming HyTime application--support
for loctype does not require or imply support for any other facilities of
HyTime.]

An instance of the GenericLink element type might look like this:

<!DOCTYPE ... >
 ...
<section id="chap1">
  ...
</section>
 ...
<para> See <GenericLink href="chap1">Chapter 1</GenericLink> 
...

To deliver this document as an XML document using XPointers, you 
would transform the declaration as follows:

<!-- XML version of previous declarations -->

<!-- Declare use of HyTime architecture -->
<?IS10744:arch name="HyTime" 
   public-id="ISO/IEC 10744:1997//NOTATION Hypermedia/Time-based
Structuring Language (HyTime)//EN"
> 
<!NOTATION XPointer 
  PUBLIC "+//IDN w3.org//NOTATION eXtended Pointer//EN"
>
<!ATTLIST GenericLink
   href        
     CDATA
     #REQUIRED
   linktype
     NAME
     "crossref"  
   loctype
     CDATA
     #FIXED "href QUERYLOC XPointer" 
   HyTime
     NAME
     #FIXED "hybrid" 
>

The QUERYLOC keyword indicates that the addressing method is some form of
"query", that is, something not defined by SGML or HyTime. The QUERYLOC
keyword must be followed by the name of the notation that governs the
interpretation of the query value. In this case, I've declared a notation
for XPointers (I made up the public ID as one has not yet been defined by
W3C for XPointers as far as I know).

Note that the base declaration of the href attribute has not changed, nor
has the link type or the HyTime architectural mapping. We've only changed
the declaration of how its value should be interpreted. 

The generated XML instance changes by transforming the ID reference into
the equivalent XPointer specification:

<?XML version="1.0" ?>
<!DOCTYPE ...>
...
<section id="chap1">
  ...
</section>
 ...
<para> See <GenericLink href="#id(chap1)">Chapter 1</GenericLink> 
...


Finally, note that the *semantic* of the reference is still defined by the
processing application. The fact that an attribute is referential does not,
in and of itself, make the element a hyperlink.  Thus, the loctype
attribute serves to declare that a given attribute is, in fact, referential
and how to resolve the reference (interpret its value) but does not say
*why* it's referential.  For that you would need to appeal to some other
mechanism, such as XLink:

<!-- XML version of previous declarations, now with XLink -->

<!-- Declare use of HyTime architecture -->
<?IS10744:arch name="HyTime" 
   public-id="ISO/IEC 10744:1997//NOTATION Hypermedia/Time-based
Structuring Language (HyTime)//EN"
> 
<!NOTATION XPointer 
  PUBLIC "+//IDN w3.org//NOTATION eXtended Pointer//EN"
>
<!ATTLIST GenericLink
   href        
     CDATA
     #REQUIRED
   linktype
     NAME
     "crossref"  
   loctype
     CDATA
     #FIXED "href QUERYLOC XPointer" 
   xml:link
     NAME
     #FIXED "simple"
   HyTime
     NAME
     #FIXED "hybrid" 
>

If you understand the rules imposed by the XLink architecture, then you
know that not only is href referential, but that its purpose is to address
the remote resource of a hyperlink.  You didn't know that second part before.

Notice that I've now combined the use of two independent architectures in
one element.  Processors that only understand XLink will ignore the
loctype, linktype, and HyTime attributes. Processors that only understand
HyTime will ignore the xml:link attribute and processors that understand
both will have redundant information about what the href attribute is all
about (because it is implicitly a reference interpreted as an XPointer by
XLink's rules an explicitly so as declared by the loctype attribute).

Cheers,

Eliot
--
<Address HyTime=bibloc>
W. Eliot Kimber, Senior Consulting SGML Engineer
Highland Consulting, a division of ISOGEN International Corp.
2200 N. Lamar St., Suite 230, Dallas, TX 95202.  214.953.0004
www.isogen.com
</Address>

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