Re: Xinclude word-smithing

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)

In the test, the document is an XHTML document.

I don't believe XHTML permits xinclude.

While XInclude describes a method for elaboration of an infoset it is 
unclear who/how/what decides when to do this elaboration. The use case 
in the introductory paragraph in XInclude suggests other specifications 
that want an include mechanism. XHTML is not such a specification.

While I don't want to argue the merits of the above argument - it is at 
least plausible, hence the suggestion for defensive edits.

>> 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.

No, my implementation supports XInclude, in that an explicit user 
instruction can switch it on.
It does not however, perform such preprocessing except in response to 
explicit user instruction (made automatically by my test code when 
running text #xinclude)

> 
>> 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.
> 

Yes

>> ====
>>
>> 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.  

That is arguable - but I don't want to argue it.

> 
> 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'.
> 


Jeremy


-- 
Hewlett-Packard Limited
registered Office: Cain Road, Bracknell, Berks RG12 1HN
Registered No: 690597 England

Received on Wednesday, 13 June 2007 13:57:12 UTC