Subject: RE: About Constructions rules From: "Didier PH Martin" <martind@xxxxxxxxxxxxx> Date: Wed, 14 Jul 1999 20:34:08 -0400 |
Hi Matthias, Matthias said: No, I think what Peter wanted to point out is that a query construction rule is "fired" for every node of the grove which is a member of the node-list returned by the query-expression. Your example involving sgml-parse isn't very useful, since sgml-parse returns a node-list, but none of the nodes is part of the current grove. Thus the rule will never be fired. Didier says: OK I see. That's a fourth interpretation. In the case the requirements are: a) the query-expression is applied on the sgml-node and then on all its children b) the action-construct-expression is applied on the returned node-list from the query-expression this then implies that a query could only be applied to the source document. then off course sgml-parse would not be qualified as a query-expression. So, the spec by itself is either ambiguous or left to implementors. Actually I think that both rules could be applied and conform to the specs: a) a query-expression is applied to the source document and if the query-expression includes a current-node expression it is always associated to the current-root node. Thus, a query is applied on the whole source document. b) as long as the query-expression is valid and part of SDQL (sgml-parse is part of SDQL) and if the query-expression returns a node-list then the action-construct-expression acts on the node-list. If, in the query-expression a current-node expression is present, then this expression is equivalent to current-root and threfore the query is applied on the whole document. Because the specs do not provide additional information about the query context, then both (a) and (b) are valid. (b) do not restrict the existance of (a) and is then a superset of (a) (because it includes it). construct (b) can lead to powerful scripts like a query processing a list containing document file path and the query-expression could then return a node-list for this particular member. the question at this point is: how do the new grove gets attached to the original grove? A possible answer is that the new grove could be just inserted under the current-root. A process-children construct-expression would imply that the new grove be processed entirely with all other rules and then the other branch (the source document or the next query result grove) processed. I agree that implementation for (b) is more complex than for (a). But it is also less poweful. (b) could allow you to process a collection of documents. For instance use a topic map as a bootstrap to process a collection of documents. Thus, queries could be used to process document collections. regards Didier PH Martin mailto:martind@xxxxxxxxxxxxx http://www.netfolder.com DSSSList info and archive: http://www.mulberrytech.com/dsssl/dssslist
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: About Constructions rules, Matthias Clasen | Thread | Re: About Constructions rules, Brandon Ibach |
Re: DSSSL engine in LISP? (also Re:, Daniel Mahler | Date | RE: DSSSL engine in LISP? (also Re:, Didier PH Martin |
Month |