RE: What is passed between processes?

We see many fallback cases in xml processing, implicitly or explicitly.
For an xml instance contains xinclude, an xinclude comforming parser
will parse it according to the spec, an non-conforming parser will
simply ignores it.

There are a few conformance levels of XSL-FO. There are fallbacks for
properties not supported in the lower level of conformance to insure
interoperability. 

In XSLT, the spec allows extension to it and provides a way to allow
author writing fallbacks in anticipating the extension may not be
available in different implementations.

We have many different use cases, and most of them involve components
not under any well-known spec. We need to have a way to make sure one
process works in multiple implementations, be it a fallback or error
handling. Otherwise, there will be just proprietary implementations and
that would render the standard useless. 

Andrew

> -----Original Message-----
> From: public-xml-processing-model-wg-request@w3.org
[mailto:public-xml-
> processing-model-wg-request@w3.org] On Behalf Of Erik Bruchez
> Sent: Wednesday, January 11, 2006 10:39 AM
> To: public-xml-processing-model-wg@w3.org
> Cc: public-xml-processing-model-wg@w3.org
> Subject: Re: What is passed between processes?
> 
> 
> Fang, Andrew wrote:
> 
> > I was actually thinking about a fall back mechanism here. Custom
> > component should specify a fallback that must be implemented by all
> > pipeline implementations. It could be as simple as passing the
> > information along without any processing.
> 
> I wonder how many use cases would actually benefit from this. I would
> think that in most situations you would simply be in a "fatal error"
> type of scenario. Consider simply an XSLT transformation you want to
> perform: if you don't have an XSLT transformation component available,
> your task simply cannot be executed. What sense does it make to pass
the
> information unmodified?
> 
> Maybe the right way of looking at this suggestion is for its
proponents
> to provide concrete use cases that would benefit from a fallback
mechanism.
> 
> Alternatively, a generic error (exception) handling mechanism could
take
> care of the issue, assuming the absence of a component is handled as a
> runtime error.
> 
> -Erik

Received on Wednesday, 11 January 2006 17:18:33 UTC