[Bug 28140] Options of fn:serialize

https://www.w3.org/Bugs/Public/show_bug.cgi?id=28140

Michael Kay <mike@saxonica.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED

--- Comment #4 from Michael Kay <mike@saxonica.com> ---
The following rules are proposed:

Representing Serialization Parameters as a Map

The fn:serialize() function will accept serialization parameters either using
the current representation (defined in Serialization 3.1) or using a new
representation defined here.

The general principles of the representation are as follows:

The serialization parameters are represented as a map with one entry for each
parameter. The representation is designed with two objectives: (a) it should be
easy to construct programmatically in XPath; (b) it should be easy to construct
as the result of applying the fn:json-doc() function to a JSON document. The
latter constraint means that the format must not be dependent on use of data
types such as xs:QName that are not expressible in JSON, and it should allow
lists to be represented as arrays rather than sequences.

The key of the entry is a string. For standard serialization parameters (such
as "method" and "indent") this is the local name of the parameter. For extended
serialization parameters, the key is a string in EQName format (for example
"Q{http://www.vendor.com/ns}indent-spaces").

The value part of the entry is represented according to the following rules:

* Where the value is a string (for example doctype-public or item-separator),
then an atomic value, where the parameter value is the result of casting the
supplied atomic value to a string. Note: The value supplied will normally be an
instance of xs:string, but it may also be xs:untypedAtomic, and in some cases
it may be convenient to supply an instance of xs:anyURI (say for
doctype-system) or xs:decimal (say for version).

* Where the required value is one of an enumerated set of values, then an
instance of xs:string; except:

** where the enumerated set is ("yes", "no"), then an instance of xs:boolean in
which "true" represents "yes" and "false" represents "no". 

** where the enumerated set is ("yes", "no", "omit"), then an instance of
xs:boolean? in which "true" represents "yes", "false" represents "no", and the
empty sequence represents "omit". 

* Where the required value is a decimal, then an instance of xs:decimal

* Where the required value is an expanded QName, then the representation may be
any of the following:

** an instance of xs:QName
** an xs:string in the form of an NCName representing a name in no namespace
** an xs:string in the form of an EQName

* Where the required value is a list of expanded QNames, then either a sequence
or an array, whose members represent these names using any of the three
representations described in the previous list item.

* Where the required value is a list of (character C, string S) pairs (that is,
for the use-character-maps parameter), a map of type map(xs:string, xs:string)
containing one entry for each pair, where the key is C represented as an
xs:string instance of length 1, and the associated value is S as an instance of
xs:string. 

Error handling works as with the existing serialization parameters (this means
it's an error if the value for a parameter is invalid, but it's not an error to
specify parameters that aren't defined in the spec.)

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Wednesday, 11 March 2015 11:03:34 UTC