RE: Xinclude word-smithing

Actually, I think it is *important* to change explanation of the
XInclude test cases.  The test cases are supposed to be illustrating
conformant GRDDL-aware agent behavior.  But it is quite clear that there
are differences of opinion about whether the XInclude expansion is
licensed or not, and the TAG has not yet decided.  So as a WG, I do not
think we should try to take a position on what the correct (licensed)
behavior of XInclude should be.

If a GRDDL-aware agent changes all 5's to 7's (perhaps at the explicit
license of the user), the document publisher cannot possibly be
construed as having taken responsibility for the result as a Faithful
Rendition of the original.  Similarly, if we (as a WG) do not know
whether XInclude process is licensed by the XInclude standard, we must
not imply that the results obtained are correct.

I suggest deleting mention of Faithful Renditions, and adding something
like the following to both XInclude examples:
[[
At this time, <b>the GRDDL Working Group does not know whether this
output should be considered correct.</b>  The Working Group hopes that
resolution of the W3C TAG's issue xmlFunctions-34[1] will clarify this.
]]

1. issue xmlFunctions-34:
http://www.w3.org/2001/tag/issues.html#xmlFunctions-34

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.
 

> -----Original Message-----
> From: public-grddl-wg-request@w3.org 
> [mailto:public-grddl-wg-request@w3.org] On Behalf Of Jeremy Carroll
> Sent: Thursday, June 14, 2007 5:10 AM
> To: ogbujic@ccf.org
> Cc: GRDDL Working Group
> Subject: Re: Xinclude word-smithing
> 
> 
> 
> I am happy to let this drop - my editorial suggestions convinced one 
> editor and not the other ... OK
> 
> Jeremy
> 
> 
> Chimezie Ogbuji wrote:
> > On Wed, 2007-06-13 at 14:08 +0100, Jeremy Carroll wrote:
> >> Summary:
> >> Issuette:
> >> It does not appear that XInclude rec licenses the 
> arbitrary expansion of
> >> xinclude elements. The GRDDL documents, particularly the 
> #xinclude test,
> >> can be read as suggesting that it does.
> > 
> > I'm not sure I understand.  The XInclude rec defines a 
> processing model
> > for transforming information sets.  The expansion is not 
> arbitrary, but
> > definitely licensed (by XML processors which 'support' its 
> elaboration
> > [1]  semantics)
> > 
> >> To better reflect this, I suggest the sentence:
> >>
> >> "Whether or not processing of XInclude, XML Validity, XML Schema
> >> Validity, XML Signatures or XML Decryption take place is
> >> implementation-defined"
> >>
> >> be changed to
> >>
> >> "Whether or not processing of XInclude, XML Validity, XML Schema
> >> Validity, XML Signatures or XML Decryption take place is 
> as defined in
> >> other recommendations and by implementation-specific behaviour"
> > 
> > I think the recent conversation on xmlFunctions-24 (from what I can
> > glean from the minutes and from HT's email [2] ) merits 
> emphasizing this
> > (especially since XProc WG is chartered to solve some of 
> this problem -
> > more on why this is significant later).
> > 
> >> And that the description of the test #xinclude is changed:
> >> http://www.w3.org/2001/sw/grddl-wg/td/grddl-tests#xinclude
> >>
> >> "the XML Processor of the GRDDL implementation supports XInclude"
> >>
> >> to
> >>
> >> "the XML Processor of the GRDDL implementation performs 
> preprocessing
> >> following XInclude"
> > 
> > I don't follow the significance of this edit, they are 
> saying the same
> > thing.
> > 
> >> and an additional sentence, perhaps at the end of the test 
> description,
> >> after the picture.
> >>
> >> "This test is not intended to suggest that such XInclude processing
> >> should be performed in this case, if no such processing is 
> performed,
> >> then the following test applies."
> > 
> > Seems a bit (unnecessarily) defensive considering the tests exercise
> > compliance WRT GRDDL (they don't mandate any additional 
> behavior) which
> > is already silent about XInclude.  This is, again, the reason why I
> > think we need stronger correspondence with the XProc WG - 
> especially if
> > we intend to not *just* say that GRDDL is silent about XML 
> processing,
> > but additionally if we are suggesting that XProc is 
> *supposed* to solve
> > this problem.  Notice, the XInclude component [3] in the 
> XProc draft is
> > incredibly sparse about prepossessing.
> > 
> >> ====
> >>
> >> The last sentence reflects the opinion of various HP 
> engineers I have
> >> chatted with, that in this case XInclude processing is not 
> licensed by
> >> any recommendation, and, while, it may be legitimized by 
> explicit user
> >> invocation of XInclude, in general, we do not think it should be
> >> encouraged.
> > 
> > This doesn't follow from http://www.w3.org/TR/xinclude (a W3C
> > 'recommendation') which indeed licenses XInclude processing 
> for those
> > XML processor which understand it's semantics.  
> > 
> > If you embed SVG within an XHTML document you aren't 
> 'encouraging' that
> > browser to render the SVG, you are simply leaving markup there for
> > browsers that understand SVG 'semantics'.
> > 
> > [1] http://www.w3.org/2001/tag/doc/elabInfoset.html#elab_ns
> > [2] http://lists.w3.org/Archives/Public/www-tag/2007Jun/0033.html
> > [3] http://www.w3.org/TR/xproc/#c.xinclude
> > 
> 
> -- 
> Hewlett-Packard Limited
> registered Office: Cain Road, Bracknell, Berks RG12 1HN
> Registered No: 690597 England
> 
> 
>

Received on Friday, 15 June 2007 18:00:12 UTC