[Bug 9302] [XQuery11] How are output declarations processed?

http://www.w3.org/Bugs/Public/show_bug.cgi?id=9302





--- Comment #9 from Henry Zongaro <zongaro@ca.ibm.com>  2010-06-08 14:17:39 ---
I agreed in comment 5 to propose changes to the Serialization 1.1 draft to
allow serialization parameters to be specified in the form of an XML document,
which I will refer to as a parameters document below.  I'd like consensus on
the approach before specifying it in great detail.  To that end I propose the
following changes to Serialization 1.1:

We define a schema for serialization parameters.  An instance might look like
this:

<ser:parameters xmlns:ser="http://www.w3.org/2010/xslt-xquery-serialization"
       ser-rec-version="1.1">
  <ser:method>xml</ser:method>
  <ser:indent>yes</ser:indent>
  <ser:cdata-section-elements xmlns:my="http://example.org">
     my:cdata-elem my:other-elem
  </ser:cdata-section-elements>
  <ser:use-character-maps>
    <ser:character-map character="~" map-string=">"/>
    <ser:character-map character="!" map-string="&lt;"/>
  </ser:use-character-maps>
</ser:parameters>

Of course, many of these are simple types, so we might decide that the values
of such parameters should be specified in "value" attributes this way:

<ser:parameters xmlns:ser="http://www.w3.org/2010/xslt-xquery-serialization"
       ser-rec-version="1.1">
  <ser:method value="xml"/>
  <ser:indent value="yes"/>
  <ser:omit-xml-declaration value="no"/>
  <ser:use-character-maps>
    <ser:character-map character="~" map-string=">"/>
    <ser:character-map character="!" map-string="&lt;"/>
  </ser:use-character-maps>
</ser:parameters>

Or make them attributes of ser:parameters itself:

<ser:parameters xmlns:ser="http://www.w3.org/2010/xslt-xquery-serialization"
       method="xml" indent="yes" omit-xml-declaration="no"
       ser-rec-version="1.1">
  <ser:use-character-maps>
    <ser:character-map character="~" map-string=">"/>
    <ser:character-map character="!" map-string="&lt;"/>
    <ser:character-map character="&#xFFFD;" map-string="Oh, oh!"/>
  </ser:use-character-maps>
</ser:parameters>

I would recommend against the third of these choices.  Implementers will likely
want to tailor the behaviour of some parameters - the indent parameter, for
instance, by specifying whether to use tabs or the number of whitespace
characters to add at each level of indentation.  Placing such
implementation-specific parameters in an attribute that modifies an element
would make it easier to see than jumbled in amongst a long list of attributes
on the ser:parameters element itself.

If we decide against the third choice, I propose the content of the
ser:parameters element would be an "all" group, with an optional element for
each parameter (minOccurs="0" maxOccurs="1").  We can allow for wildcard
elements for implementation-defined parameters and wildcard attributes that an
implementation may use to modify the behaviour of a parameter - all to the
extent such things are permitted by the Serialization specification today.

XSLT and XQuery differ in their default values for serialization parameters. 
Therefore, I would recommend against specifying default values in the schema.

Then, we can specify that a host language may use a parameters document (or an
Infoset) to specify the values of serialization parameters as if by doing the
following:
(1) validating the parameters document against the schema for serialization
parameters (and possibly against other implementation-defined schemata);
(2) constructing an instance of the XDM from the resulting PSVI; and
(3) evaluating XPath expressions of the form /ser:parameters/ser:method and so
forth to determine the values of the serialization parameters, with appropriate
settings of the components of the static and dynamic contexts.

Host languages would be permitted to override any or all of those serialization
parameter settings in any host language dependent way and supply values for
serialization parameters whose values were not determined by that process.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Tuesday, 8 June 2010 14:17:46 UTC