Re: Recognizing "subdocuments"

[Brandon Ibach <bibach@xxxxxxxxxxxxxx>]

W. Eliot Kimber said:
> 
> >> Examples of auxiliary groves are architectural instance groves, groves
> >> constructed by parsing character data into nodes (e.g., data tokenizer
> >> groves as defined by the HyTime standard), etc.
> >> So no joy there.
> >> 
> >   I guess it depends upon how you define "parse".  If the document
> >that you're running sgml-parse on is named in the value of a node in
> >the existing grove, then would it not be reasonable to say that the
> >SGML Document node in the resulting grove would be the result of a
> >"parse" of the node which contained the reference?  Therefore, the
> >SGML Document node would contain the "source" property as defined in
> >Section 9.5.
> >
> 
> I think you must be joshing, but just in case you're not: no, it would only
> be an auxiliary grove if the thing parsed were the name itself (e.g., I
> construct a grove consisting of a list of character data nodes constructed
> from a string or token). If the name is used to find some source data
> (e.g., another SGML document entity) and then *that* is parsed, the result
> cannot be an auxiliary grove.
> 
   Actually, I was quite serious.  As I recall, this started with Norm
wanting to have some way to determine if a node was part of the
original grove, or part of one generated by (sgml-parse).  The solution
(which I believe you proposed) was to compare the grove-root property
of the node with one known to be in the original grove.  Thus, the
need for a link from the generated grove back to the original arose.
You stated that the DSSSL spec didn't provide for such a link.
   Obviously, any implementation could provide a link as a
non-standard extension, but as we all know, this is the sort of thing
we try to avoid by having standards in the first place.  So, I
attempted to find a way to construct this link in a fashion which seems
to follow the standard.  The best way to do this, in my opinion, is to
look for a mechanism which seems suited, such as the "source" property
in auxiliary parsing and groves, and either adapt it, or fit it to the
problem with a somewhat more liberal interpretation of the standard.
   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?
   Standards are great, but if they don't provide (or even impede)
practical solutions, who cares?

-Brandon :)


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