xml-dev - Didier's lab report

[Didier PH Martin <martind@netfolder.com>]

experiment:
-----------
I used an Xlink construct (xlink:type="simple") to embed external content
using the attribute "show" set to "embed (show="embed"). It has been stated
in this list that the "show" attribute is for rendering purpose. The
substrate document that includes the xlink construct is an XHTML document.
The linked content is a cXML document (ref: Ariba e-commerce XML based
language). The link refers to a document fragment using an XPointer
construct. The expected behavior is that the linked content is to be
embedded in the XHTML document. This latter is rendered by a browser able to
understand, convert into rendering objects, and display the XHTML
constructs.

problem:
--------
the browser can render XHTML constructs but not other languages. cXML is not
XHTML and therefore cannot be rendered by the browser. To be displayed the
cXML content has to be transformed into XHTML. In its actual incarnation,
the xlink construct set with a show="embed" attribute will embed the content
in the XHTML document info set but won't be able to convert the cXML into
XHTML display objects. Therefore, the browser displays the cXML content with
its default XML rendering. This is not the intent of the author who wants
the content to be embedded and displayed with XHTML constructs like for
instance, a table (if the cXML document's fragment is the detailed list of
an invoice).

possible solutions?
-------------------

scenario:
the author has to provide a style sheet processing instruction in the xhtml
document. This stylesheet will transform any cXML element into XHTML.
Obviously the style sheet will not do any transformation on the XHTML
constructs and simply copy them on the output but will provide templates for
cXML constructs (to transform them or provide an interpretation for
transforming cXML elements into XHTML). This implies that anytime an XHTML
document has to embed external content, the document as a whole has to
contain a style sheet declaration. The external content is at first included
and then the whole document transformed.

Thus, when the user clicks on the link, the browser has to get the content
fragment form an external source, include it in the info set and transform
the wole document with the declared stylesheet having as a scope the entire
document.  It is like doing an inclusion but at the very last moment when
the user clicks on the link, in that sense it is a different behavior than
the xinclude element.

So, the only actual way to create a standard document is to include a
stylesheet processing instruction with the whole document as a scope (at
least based on the W3C recommendations). There are no provisions to set a
transformation to a particular document fragment (at least based on the W3C
recommendations)

Thus, an xlink element including a "show" attribute set to "embed" is in
fact a dynamic inclusion triggered by a user action like clicking on a link.
It is different from an xinclude construct in the sense that this latter
kind of inclusion occurs before any transformation or before any stylesheet
is applied to the document.

Thus:
xlink:show="embed" -> dynamic inclusion based on a user action
xinclude:href="someURI" -> inclusion occurs before any transformation and is
not based on any user action. In fact, it occurs before any kind of user
interactivity.

It seems that the actual solution based on the recommendation is that when
the user clicks on a link, the browser gets the fragment and re-apply the
provided stylesheet. Does it make sense? not so sure... It would be better
to apply a stylesheet to a particular element. The problem though is simply
the stylesheet scope which actually is applied to the whole document.

--------------------------------------------
Solution required: an update to XML documents to stylesheet association. The
updated recommendation would mention how to set the stylesheet scope to a
document fragment in addition to the actual way (whole document scope).
--------------------------------------------


Scenario 2 and solution explorations:
-------------------------------------
Until a recommendation is published to address this issue, can we create a
de facto standard behavior for any server supporting XPointer. The scenario
being that the server provide the require format by performing the
transformation on the server side. For instance, if a server receives the
following URL

/folder1/folder2/mydoc.xml#xpointer("/detail")

Let's suppose that the referred document is not an XHTML document but an
other doctype. Then, the returned element is the <detail> element but still
in a format not understood by the browser (which understands only XHTML).
Thus the proposal is that the server may perform the transformation on the
server side, for instance the xlink:href may ask for an XHTML format with a
URL like:

/folder1/folder2/mydoc.xml#xpointer("/detail")?style=xhtml.xsl

The server may perform the transformation and return the fragment to be
included. But this brings another problem. What is expected?
a) an XPointer resolution on the client side
b) an XPointer resolution on the server side

When can we know on which side the resolution is to occur? Oviously, it is
less expensive for the server to process the Xpointer on the client side but
we saw that the client is not actually well equiped to handle the
xlink;show="embed" construct.

Gee, it seems that the more I work on concrete implementations, the more the
architecture becomes like a Swiss cheese (you know, these cheese with a lot
of holes...) :-))

Very hard to stick to the recommendations, It would help more to set a
standard ourselves like we did with SAX (again, thanks David for the
initiative)

My proposal:
------------

if the transformation and the document fragment creation is to be performed
on the server side, then when the server is requested for:

/folder1/folder2/mydoc.xml#xpointer("/detail")?style=xhtml.xsl

it returns a document fragment already transformed (in the example above
with an XSLT stylesheet). The returned document fragment may be a
collection. To resolve the issue, let's say that any returned fragment is
structured as:

<?xml version="1.0"?>
<fragment>
...the fragment is contained here....
</fragment>

The fragment package is well formed but not valid (since any content can be
in the <fragment> element. The xlink behavior or piece of code used to
handle this just take the <fragment> content and embed it after the user
clicks on the link. Thus, for instance, the XHTML document may still have or
not a stylesheet with a document scope and still be able to embed foreign
vocabularies.

Opinions? comments?



cheers
Didier PH Martin
----------------------------------------------
Email: martind@netfolder.com
Conferences: xml devcon 2000 (http://www.xmldevcon2000.com)
		 Wireless Summit NY (http:www.pulver.com)
	       xml devcon 2001 London (http://www.xmldevcon2000.com)
Book: XML Professional (http://www.wrox.com)
column: (http://www.xml.com)