- From: Harry Halpin <hhalpin@ibiblio.org>
- Date: Tue, 19 Jun 2007 11:46:38 -0400
- To: "Booth, David (HP Software - Boston)" <dbooth@hp.com>, public-grddl-wg <public-grddl-wg@w3.org>
Before proposing any alternative solutions, I would write the Note and specify *all* (including non-normative) spec changes your first proposal recommends before writing a second proposal. The option of reducing variability by *not permitting* Xinclude resolution by the transformation language or the GRDDL-aware agent would require re-opening our decision on #faithful-infoset, which the current proposal in my opinion does not require. At this late stage, I am against re-opening previous WG decisions unless there is very strong feeling by more than one member of the WG, and preferably WG consensus. Booth, David (HP Software - Boston) wrote: > >> From: public-grddl-wg-request@w3.org >> [mailto:public-grddl-wg-request@w3.org] On Behalf Of Clark, John >> >> [ . . . ] with the proposed change, the >> transformation author can only control the variability along >> one of two >> possible axes; the other is out of her control. First, the document >> must be projected into the XPath data model in order to determine what >> transformations apply (call this the "transformation determination" >> step). Second, the document must be consumed by each of the GRDDL >> transformations and the results merged (call this process the >> "transformation application" step). The implementation of these two >> steps is independent, and the transformation author can only >> exert full >> control over the transformation application step (for example by using >> XProc, as we have theorized). >> > > Yes, that is exactly correct. The proposed change does not permit all > variability to be controlled, it only permits the "transformation > application" step to be controlled. In this regard, this proposal would > be clearly inferior to a change that would also remove the variability > of that step. > > Hmm, with that in mind, perhaps I should offer at least one other > alternative solution. I'll send it in a separate message. > > > David Booth, Ph.D. > HP Software > +1 617 629 8881 office | dbooth@hp.com > http://www.hp.com/go/software > > Opinions expressed herein are those of the author and do not represent > the official views of HP unless explicitly stated otherwise. > > > > -- -harry Harry Halpin, University of Edinburgh http://www.ibiblio.org/hhalpin 6B522426
Received on Tuesday, 19 June 2007 15:46:54 UTC