Re: Serialization Analysis and Proposal

/ Alex Milowski <alex@milowski.org> was heard to say:
|> |   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.

Yeah, you're probably right.

|> |   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.

Yeah, ok. :-)

|
|> |  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.

It would be. I'm saying I'd rather not do character maps.

I'm not sure we can avoid it, so I'm just saying I'd rather not :-)

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | Almost every man wastes part of his
http://nwalsh.com/            | life in attempts to display qualities
                              | which he does not possess, and to gain
                              | applause which he cannot keep.--Dr.
                              | Johnson