W3C home > Mailing lists > Public > public-grddl-wg@w3.org > December 2006

Re: Faithful Infoset (was RE: The xi namespace)

From: Chimezie Ogbuji <ogbujic@bio.ri.ccf.org>
Date: Fri, 22 Dec 2006 02:06:59 -0500 (EST)
To: public-grddl-wg <public-grddl-wg@w3.org>
Message-ID: <Pine.GSO.4.60.0612220146500.24614@joplin.bio.ri.ccf.org>

On Thu, 21 Dec 2006, Murray Maloney wrote:
> I assert that by dint of using XML with a DTD or Schema reference, the author
> has subscribed to those specifications. Using an infoset that only takes into 
> account
> the bytes that are present in the document is unfaithful to the intent of the 
> author.
> Similarly with XInclude.
> I guess what I am saying is that I believe that a GRDDL-aware processor has a 
> duty
> to resolve all XIncludes in the document and either XML- or Schema-validate 
> it.

> Even so, I think that it is incumbent on someone -- probably us/me -- to 
> highlight a
> heightened potential for unfaithful renditions in the face of DTDs, Schemas 
> and XIncludes.
> I suppose that XLink might also present a risk as well.

XLink doesn't but XInclude does and actually I went to see 
what the distinction would be, if any:


1.1 Relationship to XLink

XInclude differs from the linking features described in the [XML Linking 
Language], specifically links with the attribute value show="embed". Such 
links provide a media-type independent syntax for indicating that a 
resource is to be embedded graphically within the display of the document. 
XLink does not specify a specific processing model, but simply facilitates 
the detection of links and recognition of associated metadata by a higher 
level application.

XInclude, on the other hand, specifies a media-type specific (XML into 
XML) transformation. It defines a specific processing model for merging 
information sets. XInclude processing occurs at a low level, often by a 
generic XInclude processor which makes the resulting information set 
available to higher level applications.


XInclude is defined as a 'transformation', so it's problematic.  XLink has 
more to do with visual presentation.

A local policy ( the same which might determine which transforms are 
actually run ) might mandate to resolve all XIncludes, while another might 
not. The host language assumes an open world assumption about it's 'facts' 
so I cant imagine how the author would intend for it to be a legally 
binding contract, even though it might be 'well-formed.'

> I will work on wording for a paragraph (hopefully that is all it will take).
> If anybody doesn't understand my position, please let me know. I can live 
> with
> everybody disagreeing with how to handle the problem, but if you don't see 
> how
> it is a problem then I would appreciate your help in working toward a better
> mutual understanding.

I see the problem as you put it, see above.  But perhaps a XLink / 
XInclude caveat can be expanded for language which highlights the 
increased possibility of an unfaithful rendition?

Chimezie Ogbuji
Lead Systems Analyst
Thoracic and Cardiovascular Surgery
Cleveland Clinic Foundation
9500 Euclid Avenue/ W26
Cleveland, Ohio 44195
Office: (216)444-8593
Received on Friday, 22 December 2006 07:07:12 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:39:09 UTC