Re: The xi namespace

On Sat, 16 Dec 2006, Murray Maloney wrote:

> Dan and GRDDL WG,
>
>
> I pointed out in this week's GRDDL call that it would be possible
> and potentially highly desirable, to relate a GRDDL transformation
> with the XInclude namespace, thereby sidestepping the whole question
> of how GRDDL transformations should behave in the face of an
> XInclude in a document.

I don't think you will be able to do what you have in mind with an RDF 
term expressed in the GRDDL result document, and I'll try to explain why 
not.

First, I'm assuming what you have in mind is a property such as (perhaps) 
http://example.com/post-transform-inclusion which relates the source 
document with a URL which resolves to a document fragment which was meant 
to be included in the original XML infoset (prior to the GRDDL 
transformation).  I'm having a hardtime defining this property, so perhaps 
this is an initial indication to the problem =)

> Of course, if XInclude processing occurs in the course of events that
> leads to creation of an infoset, then the XInclude question is moot.
> It is only in the case of a GRDDL-aware processor without recourse
> to XInclude processing that my plan comes into effect.

Yes.  A further argument to *strongly* encourage the use of a pipeline 
with pre-transform XML operations such as these - BTW I wonder does XProc 
allow for some kind of 'fallback' if the implementation does not support a 
particular operation?

> My suggestion is that there should be transformation(s) against which
> an instance of <xi:include .../> could be processed to achieve something
> useful. My hope is that someone clever can write a simple bit of XSLT
> that would transform the <xi:include .../> into a useful triple

I took a stab at such a template to illustrate:

<xsl:template match="xi:include">
   <rdf:Description about="" xmlns:ex="http://example.com/">
     <ex:post-transform-inclusion rdf:resource="{@href}"/>
   </rdf:Description>
</xsl:template>

There are two problems:

1) Once the transformation happens you lose any useful context for the 
document fragment identified by the ex:post-transform-inclusion property.  The 
original source document XML infoset cannot be reconstructed *after* the 
transform so the relationship with the document fragment (identified by 
@href) is mostly annotative and there is no way to properly recreate the GRDDL
  result document that would have been the outcome of applying the transform to an
XML infoset *after* the XInclude was resolved

2) The XSLT template that extracts the XInclude instructions into 
ex:post-transform-inclusion properties might never be invoked if the 
XInclude is resolved by an XML processor that *can* handle XInclusions in 
the absence of a pipeline (we've already shown that some do).

>  I am not
> proposing the content of such an XSLT transform or the expected triple.
> I leave that as an exercise for the other members of the GRDDL WG,
> with the observation that an XInclude can, in general, be replaced
> with a corresponding XML entity declaration and use. We would need
> a rule that gives this particular transformation privilege to run first,
> ahead of any/all other transformations.

Shouldn't it be up to the author alone to specify which transformations to 
apply (knowing his/her explicit list can be overidden by a local policy?)

> The bigger question is whether the GRDDL WG can ask the W3C, or
> some appropriate part of the W3C, to add a GRDDL namespaceTransformation
> assertion to the XInclude namespace document -- that being the REC, I assume.

In order for this XInclude transform to be picked up wouldn't that require 
that the root node of the source document be in the XInclude namespace?

> Failing that, I would suggest that a tested snippet of XSLT be included in a
> non-normative portion of the spec or the Primer with a caveat about the
> potential for erroneous result graphs if XIncludes are not processed. The 
> nature
> of the warning might be something like:
>
> 	This Information Resource may or may not be a faithful representation
> 	of the original source document (href) because (##) XIncludes were
> 	not expanded before the transformation(s) were run. The result graph
> 	may or may not contain all of the useful triples that might have been
> 	gleaned from the source document if the XIncludes were expanded in 
> place.

I think XProc (and an explicit pipleline) should generally be the only 
context where we can mandate anything about arbitrary XML operations that 
may affect the XML infoset that the GRDDL transform(s) is applied to.

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

Received on Tuesday, 19 December 2006 00:07:11 UTC