Lists Home |
Date Index |
Rick Jelliffe <firstname.lastname@example.org> wrote:
> From: <AndrewWatt2000@aol.com>
>> Would you care to lay out the use case for this suggested change?
> 4) To suit transmission of documents over the web, where we
> want to be able to start rendering the document as soon as we
> receive it. This is problematic in XML, because if a WF error
> is found, the
> document is supposed to fail. Using this multi-entity XML, the
> user agent does not need to wait till the whole document is
> received before rendering that top-level chunk.
<another big snip/>
> Probably there are more, and I don't know whether any of
> these are particularly compelling.
You sort of hit on it in 4: error handling in general... A user requests a
document and something goes wrong. Since you had an error in the original
production it might not be well formed, you don't really know what you have
to so annotating it with error information is problematic. Being able to
start a separate entity gives you at least some hope that you can spit out
error annotations in a useful manner.
The Apache Cocoon project could use this type of error handling capability.
It could also use the general capability for input aggregation in general.
Currently, with Cocoon you aggregate multiple sources and wrap them with a
single root element. Really a bit of a hack since it means you can just
handle the original documents with any XSL that may have been designed to
work with them, you have to start at a new root. However, this "proposal"
doesn't quite solve that unless you maybe have some new XSLT capabilities to
point an import at a particular entity....
The additional capability I'd want with XSLT is to have a master XSLT import
other XSTL that each knew how to handle their respective documents without
having to be modified from handling the document in a standalone fashion.
An <xsl:import using="root()"/> sort of thing...
> The xml-dev list is sponsored by XML.org
> <http://www.xml.org>, an initiative of OASIS
The list archives are at http://lists.xml.org/archives/xml-dev/
To subscribe or unsubscribe from this list use the subscription