Neither the XSL nor the XML specs say a whole lot about
intended usage model. The easy case is where I've got
a single xml document and I want it displayed. No problem,
I indicate the xsl style sheet in the xml document
(or some html/xml protein coat), and send it to the browser.
The browser then displays it.
But typically I've got a whole bunch of individual xml
documents (either as files, or because that is the way
the underlying data source likes to return the data).
But what I want to show is a single view involving
contents of them all. Regardless of whether the browser
displays xml "natively" or only html, there is the question
of what to do when the underlying persistent data on my
server partitions the xml differently from how it is to
be presented.
Here are some choices:
1) write a server-side thing that parses all the individual
xml objects, and constructs a single xml or html document
for the browser. this does almost all the work on the
server, and tends to be special-cased.
this is basically what i'm doing now.
2) similar to (1), except don't do any parsing: just cat
the multiple xml objects together, and make the browser figure
it out with the aid of a stylesheet.
Of course, some overall <root></root> tag will need
to be put around it all, because xml has this annoying requirement
of wanting just one root element.
3) send back a short xml document to the browser that has suitable
links in it to indicate all the other xml documents that it
should "include". (How is this done? How do I distinguish a link
meaning "include content here" and one meaning "include reference here"?
Do I need to finally go read XLink or XPointer or one of those
other specs I've so far avoided?)
4) send back a short xml document that somehow includes a XML-QL
or similar query, so that the browser performs the query, gets
back the results (content or links), tracks those down, and *then*
applies a style.
So, what is the intended future model for this?
One of these or something else?
-mda