Re: Serialization Analysis and Proposal

On 5/15/07, Norman Walsh <ndw@nwalsh.com> wrote:
> / Alex Milowski <alex@milowski.org> was heard to say:
> | With the exception of the 'use-character-maps' parameter, most of these can
> | be specified with a simple type attribute.  The description of character
> | maps requires an element like XSLT 2.0's xsl:character-map element
> | (see [2]).
>
> XQuery does without character maps and I think we can too for V1.
> At least, I hope we can, I'll admit I'm not entirely sure.

I suppose.  I'd like to see what the motivations for this was in XSLT 2.0.

>
> | We have three places where serialization may need to be controlled or provided
> | to the process excuting the pipeline:
> |
> |   1. The output port of a pipeline.
>
> I'd like to say this is out of scope. The p:pipeline produces XML.
> What the processor does after that is not our concern.

Well, why isn't it out of scope for XSLT 1.0 and XSLT 2.0?  Because people
run the transforms "standalone" and expect the right thing to happen
upon serialization.

I think we have the same requirement to allow pipeline authors to describe
what the "normal" serialization options are and then let invocations of the
pipeline override those options.

>
> |   2. The p:store step.
>
> Yes.
>
> |   3. The entity body of an HTTP request for p:http-request.
>
> Uhm. Yeah. I guess so, though I'd easily be persuaded otherwise, I
> think.

I really think we need these parameters to serialization here.  I have
encountered services that have trouble with simple things like
the XML declaration or other bits.  As such, the pipeline author
is really going to want control over what exactly is sent.

> |  1. A corresponding element like the xsl:character-map (i.e. p:character-map)
> |     element that occur as a sibling of p:output for the p:pipeline element.
>
> I'd rather not.

*IF* we do character maps, I don't see why it would be exactly the same
structure as XSLT 2.0's.

>
> |  2. A new element that called p:serialization that has a 'name' attribute
> |     and all the serialization parameters as attributes that is allowed
> |     as a sibling of p:output for the p:pipeline element.  The value of
> |     the 'use-character-maps' is a list of QName values that correspond
> |     to the name on the p:character-map element.
>
> Maybe.
>
> |  3. For p:store and p:http-request, we allow all the serialization
> |     parameters as options to the step.  The value for the
> |     'use-character-maps' is a list of QName values that correspond
> |     to our 'xsl:character-map' element.
>
> If we want to go here at all, I'm not sure I do, then I think the
> situation for http-request must be more complicated. I would expect to
> be able to control the individual bodies in a multipart request
> independently.
>
> I think for V1, we should just say that the body is encoded as XML.
> I'm fine with describing that in terms of the parameters that can be
> applied to store, but I think for V1 we should just say that all the
> parameters have fixed values.

I don't think that makes sense for the reason I detail above.  For V1 we
could restrict multipart requests to only have one serialization.  I think
that is OK.

> My answers above are "knee jerk" reactions (maybe without the "knee" :-)
> I'm prepared to be persuaded otherwise.
>
> One reason I say that, and that I'm sypathetic to this proposal even
> though it's quite complex, is that I don't see an obvious workaround. We
> can't just say "let the XSLT 2.0 step do the serializing" because, well,
> in a pipeline, it won't.
>
> I think users are going to expect quite a bit of flexibility with
> respect to the serialization that's possible.

I think you see that reflected in the serialization specification for
XSLT 2.0 in that
there was a user need to control serialization.   What I proposed is
certainly more
complicated than "encode it as XML"  but I don't think it is more complicated
than necessary.  Serialization is just an important and thorny topic.
Fortunately,
we have the XQuery and XSLT 2.0 serialization specification that we can reuse.


-- 
--Alex Milowski
"The excellence of grammar as a guide is proportional to the paucity of the
inflexions, i.e. to the degree of analysis effected by the language
considered."

Bertrand Russell in a footnote of Principles of Mathematics

Received on Tuesday, 15 May 2007 22:34:37 UTC