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 Thursday, 14 June 2007 09:10:34 UTC