Re: Xinclude word-smithing

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

-- 
Chimezie Ogbuji
Lead Systems Analyst
Thoracic and Cardiovascular Surgery
Cleveland Clinic Foundation
9500 Euclid Avenue/ W26
Cleveland, Ohio 44195
Office: (216)444-8593
ogbujic@ccf.org


===================================




Cleveland Clinic is ranked one of the top 3 hospitals in
America by U.S.News & World Report. Visit us online at
http://www.clevelandclinic.org for a complete listing of
our services, staff and locations.


Confidentiality Note:  This message is intended for use
only by the individual or entity to which it is addressed
and may contain information that is privileged,
confidential, and exempt from disclosure under applicable
law.  If the reader of this message is not the intended
recipient or the employee or agent responsible for
delivering the message to the intended recipient, you are
hereby notified that any dissemination, distribution or
copying of this communication is strictly prohibited.  If
you have received this communication in error,  please
contact the sender immediately and destroy the material in
its entirety, whether electronic or hard copy.  Thank you.

Received on Wednesday, 13 June 2007 13:37:27 UTC