RE: Multiple result-documents, client-side transformations, and U RIs

> I'm sorry if this has already been discussed, but I couldn't find a 
> discussion of how client-side transformation of multiple 
> result-documents will be handled (in web browsers, for example).

Thanks for these comments. Browser vendors have been involved in the
discussions of these XSLT facilities, but the exact way that multiple result
trees might be handled in the browser is not something that the WG considers
within its scope - it's a product issue. I can only speculate about how
browsers might choose to map the abstract concepts in the specification to
concrete concepts in their implementation. The original drafts of the
specification caused some resistance because they were written in a way that
appeared to restrict implementations too much. This obstacle seems to have
been cleared, and we can now only wait to see what implementors choose to
do.


> 
> Mozilla currently uses XSLT(1) transoformations to display 
> web content. 
> However, if multiple result-documents are returned, the 
> browser needs a 
> way to choose an initial result
> 
> For example, I will pose a hypothetical docbook transformation that 
> separates the transformation results into a TOC, a page for each 
> chapter, and an index. These pages will need to link together 
> in various 
> ways.
> 
> 1) is there a mechanism for a browser to know which 
> result-document is 
> the "default"?

We have tried to avoid giving preferential status to any one result tree,
though in practice there will often be one that is output "first". An
implementation might attach special status to the result tree that is
created implicitly, without using an xsl:result-document instruction, or it
might impose some convention on the URIs that are used.
> 
> 2) is there a URI by which each result can be accessed individually?

Yes, the href attribute of the xsl:result-document defines a URI which is
intended to provide some kind of handle by means of which an API might
access each result tree, or an implementor could define some kind of mapping
from these URIs to the names of frames or other browser GUI objects in which
the result trees are to be rendered.
> 
> 3) is there a method that can link from one result-document 
> to another?

Yes, we have taken care to specify that the URIs provided in the href
attribute can be used to link from one tree to another. The idea is that you
would probably use relative URIs for links within the collection of result
trees, so that they would survive serialization to any particular location
on disk.
> 
> It seems that these would be a necessity if XSLT2 is to be 
> used in any 
> interactive client-side situation.
> 
> If this has not been resolved, I would propose a URI scheme to handle 
> this situation:
> 
> xlst:source-xml!transformation!result-document


I don't feel qualified to judge whether the scheme you propose would be
useful; this is something we are leaving entirely to the browser
implementors.

Many thanks for the comments. This area probably hasn't been discussed as
much as it should be.

Michael Kay



> 
> source-xml = relative or absolute URI (exclamation marks must be 
> escaped; relative to linking document)
> 
> transformation = relative or absolute URI (exclamation marks must be 
> escaped; relative to source-xml, may be left empty for default 
> stylesheet specified by <?xml-stylesheet?> or other mechanisms)
> 
> result-document = relative or absolute URI (exclamation marks must be 
> escaped; relative to source-xml)
> 
> Examples: 
> xslt:http://www.abc.123/docbook.xml!http://www.docbook.org/doc
> book.xslt2!index.html
>    retrieves the source http://www.abc.123/docbook.xml
>    transforms it using http://www.docbook.org/docbook.xslt2
>    displays the result-document http://www.abc.123/index.html
> 
> xslt:http://www.abc.123/docbook.xml!!index.html
>    retrieves the source http://www.abc.123/docbook.xml
>    transforms it using the default stylesheet
>    displays the result-document http://www.abc.123/index.html
>

Received on Wednesday, 14 May 2003 23:24:38 UTC