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. Cheers, E. -- <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 www.isogen.com </Address> DSSSList info and archive: http://www.mulberrytech.com/dsssl/dssslist
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: Recognizing "subdocuments", Brandon Ibach | Thread | RE: Recognizing "subdocuments", Pawson, David |
Global Variables and JADE vs OMNIMA, Mike Sosteric | Date | Re: Global Variables and JADE vs OM, W. Eliot Kimber |
Month |