Re: Recognizing "subdocuments"

Subject: Re: Recognizing "subdocuments"
From: "W. Eliot Kimber" <eliot@xxxxxxxxxxxxxx>
Date: Sun, 06 Dec 1998 22:34:16 -0600
At 05:46 PM 12/6/98 -0600, Brandon Ibach wrote:

>   You're right.  The (sgml-parse) probably wouldn't qualify, in a
>strict sense, as an auxiliary parse.  But consider, for a moment, the
>intent here.  An auxiliary parse is intended to provide additional
>information about a document (or an abstraction of information, such
>as an architectural instance).  What Norm is doing (without knowing
>exactly what he's up to) is probably essentially the same thing.  He's
>parsing in one document, then parsing in another which is referenced
>in the first, in order to provide related information about the first
>document.  Given the similar goals of both processes, would it not be
>reasonable to say that an implementation could provide a link back to
>the "source" node of an (sgml-parse), "based" on the auxiliary parse
>functionality of the spec?

I'm all for attempts to make the standards work to the greatest degree
possible and have done my share of liberal interpreting. But in this case,
I think that trying to shoehorn this requirement into auxiliary groves
would be inappropriate and counterproductive.  In particular, the
relationship between the newly parsed document and the grove being
processed at the time the new document is parsed is entirely determined by
the semantics of the style spec--there is no standardized (or
standardizable) meaning for parsing a document while processing a node in
another grove.  It could be done for any reason, many of which would have
no need to maintain a back pointer from the new grove to the node in the
old one where parsing occurred.  Therefore, the new grove is not an
auxiliary grove by definition.

The DSSSL standard could provide a function for establishing the
relationship so that style processes that needed to go from the new grove
to some node in another grove could do so conveniently. But it doesn't. But
there's no reason any DSSSL processor couldn't provide the function.

>    Standards are great, but if they don't provide (or even impede)
> practical solutions, who cares?

But that doesn't mean that everything we need has to be written in a
standard first.  Standards like DSSSL and HyTime provide a framework within
which specific solutions can be created and documented in terms of a more
general standard.  If some parts of those solutions turn out to have wide
applicability, it may be useful to standardize them as well.  Groves and
grove construction are a general facility that any DSSSL processor could
use in new and clever ways to do things like this.

Of course, if you had a HyTime engine that supported valueref, it'd be a
moot point because the HyTime engine would maintain the necessary
information for you.


<Address HyTime=bibloc>
W. Eliot Kimber, Senior Consulting SGML Engineer
ISOGEN International Corp.
2200 N. Lamar St., Suite 230, Dallas, TX 75202.  214.953.0004

 DSSSList info and archive:

Current Thread