Re: well-formed output XML (was: what are node set fragments

er - I sent this without my reply. what I meant to say was ...

Kay Michael wrote:
> > along. that means that the stylesheet writer asks for a standalone
> > document declaration at their own risk: if the output turns out not to
> > be a wf document, it won't be a wf external entity either.
> 
> Yes indeed. My current thinking is that if output method="xml" and either a
> standalone declaration or a doctype declaration is requested, then I should

why when only a doctype declaration is requested? when no standalone
declaration is requested, no standalone declaration is to be output, and
so the "doctype declaration" just turns into a text declaration if the
output turns out to be a wf external entity. can't
com.icl.saxon.output.OutputDetails.setOmitDeclaration() mean either a
doctype declaration or a text declaration?

> report an error if subsequently an attempt is made:
> - to output a text node before the first top-level element node
> - to output a text node or element node after the first top-level element
> node
> - to finish processing before a top-level element node has been output.
> 
> I think I am justified in doing this because reading section 16.1 as a whole
> and ignoring obvious contradictions makes it fairly clear that the intention
> of the spec's authors was that the output from method="xml" should be either
> a well-formed XML document or a well-formed XML external general parsed
> entity or both.

yes: it's tricky, but I that approach (with the above caveat) seems
reasonable. it also helps to clarify your next issue:

> That still leaves me with a little problem if the user asks for output to be
> directed to a DocumentHandler and it turns out not to be a well-formed
> document. Should I feed the DocumentHandler the events regardless, ignoring
> the implicit requirement of the DocumentHandler interface that the events
> arive in a well-formed order? Currently for example SAXON is calling FOP's
> DocumentHandler, which quite understandably keels over when the first thing
> it's given is a text node.

we can distinguish:

(x) a conforming XSLT processor. either returns a wf document, or
returns a wf external entity, or signals an error.

(y) a wrapper around (x), which signals an error when (x) returns a wf
external entity, and otherwise just passes on (x)'s output. therefore,
either returns a wf document, or signals an error.

(z) a wrapper around (x), which signals an error when (x) returns a wf
document[1], and otherwise just passes on (x)'s output. therefore,
either returns a wf external entity, or signals an error.

I would say that there's nothing wrong with a product providing a (y) or
(z) interface, so long as it also provides an (x) interface. providing
_only_ (y) or (z) would be implementing something othre than the XSLT
standard.

if the user asks for the output to be sent to a DocumentHandler, they
seem to be asking for (y) rather than (x).

-- 

cheers

phil

"that monotonous state of the soul halfway between fulfillment
and futility which comes with life in the country" --- Musil

[1] i.e. when a standalone declaration is asked for (which can be
detected early).


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list