Re: Two questions: (sgml-parse) and (data)

["W. Eliot Kimber" <eliot@xxxxxxxxxx>]

At 12:14 PM 5/30/97 +0700, James Clark wrote:
>At 22:06 29/05/97 -0900, W. Eliot Kimber wrote:
>>Two questions, largely unrelated except by arising from the same document
>>type:
>>
>>1. I've figured out a way to get the content of an element in order to
set the
>>   running head. 
>
>I would suggest something like:
>
>   left-header: (with-mode header (process-first-descendant 'title))
>
>(mode header
>  (element title (process-children))

Thanks.  I haven't quite gotten my head around modes yet.  This is a nice
simple example that will help a lot in understanding that facility.

>This will also work better when title has substructure.
>
>>2. Autonumbering through sgml-parse
>>
>>I got sgml-parse to work for processing subdocuments (very cool, I must
>>say--I had the document already and was just waiting for the function to be
>>implemented), but realized that I don't know how to look up through the
>>reference in order to autonumber the document element of the included
>>subdoc based on the child number of the referencing document. 
>
>I don't see any way to do this in DSSSL at the moment.

Bummer.  But I feel better knowing I wasn't missing something obvious.

>>Is there a way to get back to the element from which the subdoc was
>>referenced so that I can count it?  I thought the (source) function would
>>do it, but (source) doesn't appear to be supported by 0.8.
>
>The source property is on nodes in auxiliary groves; (sgml-parse) returns a
>normal SGML grove, not an auxiliary grove.

I think the way I would normally expect this problem to be solved would be
to actually construct a new (auxiliary) grove in which the references are
replaced by the referenced grove roots, thus creating an effective single
document grove.  This is the HyTime abstract model for representing those
HyTime-defined semantics that affect how parsed documents are interpreted
(value reference, default value list, etc.).  Not sure how you'd do that in
a DSSSL implementation--perhaps provide a command-line option to build that
form of grove?  Note that, for example, the semantics of the subdoc
reference I'm making in my document type are defined through the use of the
HyTime "value reference" (nee conloc) facility, to the effect that the
referenced subdoc is the "effective value" of the referencing element,
meaning that you should use the referenced document's document element in
place of the element making the reference.  This is essentially what the
DSSSL (document-element (sgml-parse)) function combination is saying, but
in the data, rather than in the style spec.

If JADE supported this use of value reference, it could do the node
substitution transparently, thus creating a single effective document
grove, rather than a hypergrove.

The HyTime value reference facility (new with the TC) lets you get the
value of an attribute, an element, or an element's content, by reference
(using any form of reference you want, including, but not limited to, ID
and entity references).

For example, my TopicRef element is declared like so:

<!ELEMENT TopicRef        - O  EMPTY
>
<!ATTLIST TopicRef
     topic    ENTITY   #REQUIRED
	 -- NOTE: Valueref new with HyTime TC.  Keyword "#ELEMENT" means
	       that the "value" of the element is the element addressed by
		the topic attribute (or, if the thing addressed is a document
		entity, the document element of that entity). --
     valueref CDATA    #FIXED "#ELEMENT topic"
>

Note that I could use other forms of reference with valueref, e.g. I could
have used URLs or HyTime indirect addressing or TEI pointers (here using
the "reference location" facility of HyTime):

<!NOTATION URL PUBLIC "-//IETF//NOTATION Universal Resource Locator//EN" >
<!ELEMENT TopicRef        - O  EMPTY
>
<!ATTLIST TopicRef
     topic    CDATA   #REQUIRED
     loctype  CDATA   #FIXED "topic queryloc url"
	 -- NOTE: Valueref new with HyTime TC.  Keyword "#ELEMENT" means
	    that the "value" of the element is the element addressed by
		the topic attribute (or, if the thing addressed is a document
		entity, the document element of that entity). --
     valueref CDATA    #FIXED "#ELEMENT topic"
>

The "location type" (loctype) attribute maps referential attributes
(attributes whose semantic is reference) to location addressing methods.
Here, I'm mapping the "topic" attribute to the query notation "URL" [In
HyTime, everything that's not fundamental to HyTime is a query.  The effect
of the URL must be to return the node in the grove built from the document
(or other resource storage object) containing whatever the URL addresses
(which by default is the document element of the document addressed).
HyTime location addressing is closed over nodes in groves, so any query
notation must return nodes in groves, regardless of what it's really
addressing under the covers.].

Thus, the semantic of the value reference is independent of the addressing
method used.  I've used it here to define the precise semantic I intend for
this use of SUBDOC.

NOTE: This means that HyTime is explicitly making a decision between
addressing used to express a construction semantic ("value reference") and
addressing used in the service of hyperlinks ("anchor addressing").  The
Web community, focused on addressing, does not normally make this
distinction and conflates the two.  IMNSHO, this is a mistake of the
highest order.  It should be obvious from the above example that the former
should be handled at the grove construction/access level in a way that is
transparent to style specs (because the interpretation of any given
construction semantic is limited to either "occurs at this place" or
"doesn't occur at this place" in the grove), while the latter has infinite
possible interpretations and renditions, and thus must be exposed for
control through style specs.  

The value reference and reference type facilities are defined in the
location address module of the corrected HyTime standard (which I'm in the
process of preparing for publication right now (or rather, after I finish
this note).

Cheers,

E.

 DSSSList info and archive:  http://www.mulberrytech.com/dsssl/dssslist