[
Lists Home |
Date Index |
Thread Index
]
Elliotte Rusty Harold wrote:
> Maybe they need to be less so. XSLT 1.0/XPath 1.0 was designed for
> document transformations and browser display. It was not designed as
> a general purpose XML query language. Now that new and very
> different use cases and requirements are getting piled on top of it,
> it's beginning to look not nearly as pretty.
>
> I think maybe we need less general tools, not more. I think perhaps
> it's time to consider whether merging XQuery and XPath and XSLT
> actually makes sense. This may have been a mistake. The needs of the
> communities involved may be just too different for them to
> comfortably use the same tools.
One of the things that's been illuminating for me over the past few
days discussion has been how different the assumptions are between
XQuery and XSLT users about how their respective languages are going
to be used -- what kind of assumptions can be made about the source of
the information the two languages are going to operate over, and the
workflow that surrounds the query or transformation?
In XQuery, I think you generally have a large store of information in
a known format. Since such an information store will have
check-in/check-out facilities, you can pretty much guarantee that the
information within the information store will be valid.
Each information store (which is treated as an XML document but is
probably actually a database) is likely to have several queries
associated with it, in order to extract different information.
Generally this is a filtering of the information available in the
information store; you're unlikely to add information that isn't from
the information store itself.
Each query is individually likely to be quite short, and there are few
assumptions about the way in which the result of the query is used
later on -- what the target of the query will be.
Once a query is written, it will be associated with the information
store, and compiled. Like the check-in process for information,
checking in the query will involve checking it and compiling it so
that everything runs as fast as possible when the query is actually
made. The query will be executed many times on the information store,
keeping up to date with the changing contents of the information
store.
The query itself is not parameterised -- if you want the query to
extract slightly different information, then you do that by writing
another query; it's expected that the users of the information store
will be able to write a query themselves, or will have close enough
association with the information store administration staff that they
can get them to write it for them.
The querying process occurs at the beginning of a pipeline, when
extracting information from the information store.
In XSLT, I think you generally have a set of documents that have
something in common -- that something could just be that they're
written in XML, or it could be that they contain elements in a
particular markup language (such as XInclude or RDF), or it could be
that you know the ostensible markup language for the entire document.
Usually, you can't make many guarantees about the validity of the
document.
Each set of documents is likely to have several transformations
associated with it, mostly creating different layouts or formats the
information. Generally this is a translation into a different markup
language, a reorganisation, and an addition of information such as
standard text, headings and so on.
Each stylesheet tends to be quite long, and is usually constructed
with a particular target application in mind, such as an SVG viewer or
an HTML browser or an XSL-FO renderer.
The stylesheet will be made available somewhere, and used in a variety
of ways, with usually few guarantees about what those situations might
be. Each application that uses the stylesheet has to compile it and
run it, usually both at the same time, though an application might
compile it and use it several times over different documents.
Stylesheets are often parameterised, so that different users can
configure the stylesheet to create the output that's required; it's
not expected that the users of the stylesheets will know enough XSLT
to be able to write their own, so they'll usually be supplied with a
configuration mechanism, often an XML document, to make the task
simpler.
Transformations generally occur in the middle or end of a pipeline,
between information extraction and application-specific presentation.
You might have several transformations piped together to perform
different kinds of transformation.
Do people think those are fair characterisations? I admit I'm not
that familiar with the XQuery side of the coin, so I'd be interested
if I was characterising it inaccurately or if there were other
distinctions that I've left out.
Cheers,
Jeni
---
Jeni Tennison
http://www.jenitennison.com/
|
