🚀 go-pugleaf

In an earlier posting, I showed a HyTime example that
used nameloc to create a location chain ending in a dataloc
element that located character data in a non-SGML file.
I had though that HyTime required a nameloc element to
create a location ladder, but I apparently misread the standard
(that's what I get for creating appends early on Saturday
mornings).

Looking back over ISO 10744, I can't find anything that would
suggest I *can't* refer directly to a dataloc by its own
ID, allowing me to reduce my somewhat convoluted ContentRefSpec
element to no more than an application-specific instance
of the dataloc form (further simplified by allowing an
ENTITY= attribute directly on ContentRefSpec in place of
locsrc=):

<!ELEMENT ContentRefSpec - O (marklist*) >
<!ATTLIST ContentRefSpec
             HyTime         NAME   #FIXED     dataloc
             DataContainter ENTITY #REQUIRED  --replaces locsrc--
>

Note that the minimized markup from my earlier posting and
the markup for the above definition are the same:  ContentRefSpec
containing marklists defining the data positions within the data
entity.  I've just simplified the underlying system itself.

I might want to keep my original, more complex, definition
if I need the following:

o The need to refer to multiple dataloc elements in order to
  define an aggregate location.  This requires a nameloc in order
  to provide a single local ID for multiple targets.  This is the
  power of the indirection of nameloc.  Think of it as an amplifier,
  where each opportunity for indirection is an opportunity to
  specify more target anchors for the links.

o The desire to provide application-specific elements with
  ContentRefSpec.  For example, I like to require a description
  element in elements to make the elements self-documenting,
  e.g.:

  <ContentRefSpec><desc>Purpose of this link</>
    <marklist>...
  </ContentRefSpec>

o Complete separation of HyTime elements and application-specific
  elements.  Using this design principle removes the need to
  require HyTime support for support of your application if the
  functions HyTime provides are optional within your application.  It
  also makes the boundary between your application and HyTime
  very clear and precise.

Eliot Kimber                      Internet:  drmacro@ralvm13.vnet.ibm.com
Dept E14/B500                     IBMMAIL:   USIB2DK9@IBMMAIL
Network Programs Information Development     Phone: 1-919-543-7091
IBM Corporation
Research Triangle Park, NC 27709