RE: Proposal 3c (compromise) to address the ambiguity issue

> From: Chimezie Ogbuji [mailto:ogbujic@ccf.org] 
> [ . . . ]
> However, I didn't add the note about what browsers do as GRDDL is a
> mechanism for web 'agents' in general not browsers specifically.  

That's fine.  I don't think that part is important.

> The
> emphasis on the suggestion in the GRDDL specification to use XProc (in
> the "Testing Faithful Infosets" section) seemed sufficient and more
> relevant than the TAG issue as XProc is specifically *chartered* to
> deliver a Recommendation Track document which addresses 
> fine-grained XML
> processing and we have commented [1] on the risk (WRT GRDDL) 
> associated with not addressing this.

The existing suggeston in section 6 to use XProc (to my mind) addresses
a different problem though.  It addresses the case where the GRDDL-aware
agent has *not* done unwanted pre-processing, and the GRDDL
transformation author can therefore control the desired
pre-preprocessing by explicit use of XProc's pipeline language.    It
does not address the case where the GRDDL-aware agent may do unwanted
pre-processing, and the GRDDL transformation author is unable to
indicate that such pre-process was not intended.  This is the case where
XProc's future default processing model would come into play.  The GRDDL
transformation author has no way to indicate that XProc's default
processing model should be used.

The key question is: Does GRDDL expect GRDDL implementations to conform
to the future XProc default processing model and the TAG's future
xmlFunctions-34 decision or not?   If so, then the GRDDL spec should
clearly say that and the ambiguity issue will go away when that happens.
If not, then those decisions will not resolve the ambiguity problem
because they are not binding on GRDDL implementations.

The purpose of this compromise proposal is to make clear that GRDDL
implementations *are* expected to conform to the XProc default
processing model and the TAG's xmlFunctions-34 decision when they are
issued.

> 
> [1]http://lists.w3.org/Archives/Public/public-xml-processing-m
> odel-comments/2007Jun/0046.html
> 
> >  - Making forward reference to a spec that is not yet published is
> > somewhat unusual, but not unprecedented.  For example, the 
> > RDF Concepts
> > document did this in reference to the non-yet-published IRI spec:
> > http://www.w3.org/TR/rdf-concepts/#section-Graph-URIref
> 
> Is it the case that the resolution of the TAGs issue will result in a
> (TAG-authored) recommendation track document? Seems unlikely given the
> fact that the XProc WG has this responsibility placed 
> squarely in their lap.

DanC can probably speak to this better than me, but I doubt the TAG
would issue a rec-track document about xmlFunctions-34.  They usually
just issue "findings" on specific issues.  My understanding of
xmlFunctions-34 -- DanC please correct me if I'm wrong -- is that the
TAG is hoping that an XProc default processing model will represent a
solution to that issue, and hence the TAG won't have to do much other
than say "follow that spec".  However, the reason proposal 3c mentions
both xmlFunctions-34 and the XProc default processing model is in case
the XProc default processing model is only a partial solution to
xmlFunctions-34, and the TAG needs to say more about it.



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.

Received on Tuesday, 26 June 2007 16:40:17 UTC