Re: Serialization Analysis and Proposal

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

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

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

| It also looks to me like XSLT 1.0's serialization is a subset of XSLT 2.0.  It
| is easy to detect parameters that can't be supported by an XSLT 1.0
| serialization engine.  In addition, the XSLT 2.0 specification says:
|
|   "An implementation may allow the attributes of the xsl:output declaration
|    to be overridden, or the default values to be changed, using the API that
|    controls the transformation."
|
| That means an implementation can choose to ignore a serialization parameter
| although a user would see that as a non-feature.  I assume that is to
| allow serialization parameters to be set by the invocation of the transform
| and not always be dictated by the XSLT transformation.
|
| Given all of this, I think we need:
|
|  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.

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

|  4. We add a 'serialization' option to the p:store and p:http-request
|     that names a p:serialization element to use.  The values of
|     the serialization parameters are merged where the locally
|     defined options on the step are preferred over those of
|     the p:serialization element.

Maybe.

|  5. We add a 'serialization' attribute to the p:output element.  If
|     the pipeline output has one of these attributes and the output
|     is serialized, the processor should apply that serialization.
|     These serialization options may be overridden via invocation
|     just as for XSLT 2.0.
|
|     If the 'serialization' attribute is specified on step outputs,
|     it is ignored.  Note: It could be useful for journaling
|     the outputs.

I'd rather not.

| Having a 'p:serialization' declaration element has the advantage of
| allowing a pipeline library to declare serialization for a set of
| pipelines.  We could decide to provide a way for such declarations
| to be made available through the library as well as the pipelines.
| On possibility is for the p:pipeline-library to allow the p:serialization
| element as well.
|
| [1] http://www.w3.org/TR/xslt-xquery-serialization/#serparam
| [2] http://www.w3.org/TR/xslt20/#character-maps

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.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | For the mental patient's family and
http://nwalsh.com/            | society, mental illness is a 'problem';
                              | for the patient himself it is a
                              | 'solution'.--Thomas Szasz