XSLT 2.0 and XQuery 1.0 Serialization

According to 
http://www.w3.org/TR/2003/WD-xslt-xquery-serialization-20030502/#N400318


   The omit-xml-declaration parameter should be ignored if the standalone
   parameter is present, or if the encoding parameter specifies a value
   other than UTF-8 or UTF-16.

There is one other case where it would be very useful to omit the
declaration (or at least to use a value of utf-8) namely
iso-646 (aka ASCII aka US-ASCII).

It may be politically incorrect to say that ascii characters are still
more interoperable than non-ascii characters, but in practice this is
still the case. Especially in XML which specifies that a charset
specified in the mime headers takes precedence it is hard to give (say) a
utf8 file to someone to serve from their website without first finding
out what http server they use, and how to make sure it won't serve the
thing as latin 1 resulting in a non-well formed document.
(See current discussion on W3C'S TAG list about this).

One style of producing XML files that avoids these problems is to
produce files that don't have an xml declaration (or have one that
specifies utf-8) but to encode all non-ascii characters as numeric
character references.

Currently in an XSLT 1 usage in production I use
<xsl:output encoding="US-ASCII"/>
with saxon and post process with sed to remove the US-ASCII
encoding declaration (which stops the file being parsed on several XML
systems I have locally) I think that it would be very desirable if

<xsl:output encoding="iso-646" omit-xml-declaration="yes"/>

was defined to work, and produce files of the form described above.

Failing that it would be good if it would be allowed by the
specification if the system understood that encoding.

David

________________________________________________________________________
This e-mail has been scanned for all viruses by Star Internet. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:
http://www.star.net.uk
________________________________________________________________________

    

     Thank you for raising this issue.  The XSL and XQuery working groups 
discussed the issue and decided not to require processors to support the 
US-ASCII encoding and its aliases.  The working groups decided that the 
appropriate way of addressing your comment would be to replace the second 
paragraph of Section 4.5 of the last call working draft of XSLT 2.0 and 
XQuery 1.0 Serialization [1], which currently reads:

<<
The omit-xml-declaration parameter must be ignored if the standalone 
parameter is present, or if the encoding parameter specifies a value other 
than UTF-8 or UTF-16.
>>

with the following:

<<
The omit-xml-declaration parameter must be ignored if the standalone 
parameter is present, or if the encoding parameter specifies a value that 
is not UTF-8, UTF-16 or a subset of either of those encodings.  An 
encoding S is a subset of another encoding E if the set of codepoints that 
can be encoded in S is a subset of those that can be encoded in B, and the 
encodings of those codepoints in S is the same as the encodings of those 
same codepoints in encoding E.
>>

     That resolution seems to be in accord with the last sentence of your 
comment.  Please let us know whether you consider this resolution 
acceptable.

Thanks, looks good to me.

David

SAG-XQ-005 Serializing Arbitrary Sequences

We don't think that the mechanism for serializing an arbitrary sequence
described in section 2 of the Serialization specification meets any known
user requirement.

We do think that there is a requirement for an interoperable serialization
format for an arbitrary sequence, and that this should be defined. We think
that the requirement is for a format that wraps each item in the sequence in
an XML wrapper providing information about the type, the value, and in the
case of nodes, the name of the node. For example, an attribute node might be
serialized as

<res:attribute name="my:att" type="my:shoesize" value="7.3"/>

In the case of elements and documents, the tree rooted at that node would be
serialized. The format would be extensible to allow implementation-defined
attributes that represent the identity of nodes, allowing the information to
be used for a subsequent update, or for creating hyperlinks.

(Note, technically we are talking here about a representation of an
arbitrary sequence in the form of a document. Serializing that document is
entirely orthogonal).

Michael Kay
for Software AG

    

Walter,

     In [1] Michael Kay submitted the following comment from Software AG.

Michael Kay wrote on 2003-11-27 06:56:34 AM:
> SAG-XQ-005 Serializing Arbitrary Sequences 
> We don't think that the mechanism for serializing an arbitrary 
> sequence described in section 2 of the Serialization specification 
> meets any known user requirement.
> We do think that there is a requirement for an interoperable 
> serialization format for an arbitrary sequence, and that this should
> be defined. We think that the requirement is for a format that wraps
> each item in the sequence in an XML wrapper providing information 
> about the type, the value, and in the case of nodes, the name of the
> node. For example, an attribute node might be serialized as
> <res:attribute name="my:att" type="my:shoesize" value="7.3"/> 
> In the case of elements and documents, the tree rooted at that node 
> would be serialized. The format would be extensible to allow 
> implementation-defined attributes that represent the identity of 
> nodes, allowing the information to be used for a subsequent update, 
> or for creating hyperlinks.
> (Note, technically we are talking here about a representation of an 
> arbitrary sequence in the form of a document. Serializing that 
> document is entirely orthogonal).

     Thanks to Michael and Software AG for raising the comment.

     The XSL and XQuery working groups considered this comment and related 
comments.  There was general agreement that there is some need for a 
mechanism for serializing arbitrary sequences that preserves most or all 
of the properties of the items in an arbitrary sequence that is being 
serialized.

     However, the working groups decided that precisely defining all of 
the requirements for such a mechanism at this stage would be difficult, 
and would likely lead to a solution that would not satisfy real user 
requirements.  Therefore, the working groups decided to consider such a 
feature for a future revision of the recommendations, and close this 
comment without any changes to the specifications.

     May I ask you to confirm that this resolution is acceptable?

Thanks,

Henry
[1] 
http://lists.w3.org/Archives/Public/public-qt-comments/2003Nov/0305.html
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

Hello Henry,
although I do not understand all the arguments, I can live with that decision;
especially as we have a high interest in a finished XQuery recommendation 
as early as possible.

Best regards
Walter

SUGGESTION 4:
20 Serialization normalize-unicode?  attribute of the xsl:output element
Problem:
Not clear which normalization forms to use. "NFC"?
Why we should have "NFC" only, if we can support others as in
fn:normalize-unicode?

Solution:
normalize-unicode? = string
The attribute should follow the rules of the second
argument($normalizationForm   )
of the fn:normalize-unicode
(http://www.w3.org/TR/xquery-operators/#func-normalize-unicode)


Igor Hersht
XSLT Development
IBM Canada Ltd., 8200 Warden Avenue, Markham, Ontario L6G 1C7
Office D2-260, Phone (905)413-3240 ; FAX  (905)413-4839

Igor,

     In [1], you submitted the following comment on the XSLT 2.0 and 
Serialization last call drafts.

Igor Hersht wrote on 2004-01-11 05:01:13 PM:
> SUGGESTION 4:
> 20 Serialization normalize-unicode?  attribute of the xsl:output element
> Problem:
> Not clear which normalization forms to use. "NFC"?
> Why we should have "NFC" only, if we can support others as in
> fn:normalize-unicode?
> 
> Solution:
> normalize-unicode? = string
> The attribute should follow the rules of the second
> argument($normalizationForm   )
> of the fn:normalize-unicode
> (http://www.w3.org/TR/xquery-operators/#func-normalize-unicode)

     Thank you for your comment.

     The XSL and XQuery Working Groups discussed your comment, and agreed 
that the serialization parameter for Unicode normalization should be 
aligned with the fn:normalize-unicode function and permit additional 
normalization forms to be specified.  The working groups decided to make 
the following changes to the definition of the normalize-unicode 
serialization parameter:

1. Rename the parameter to "normalization-form".

2. The possible values of the parameter will be "NFC", "NFD", "NFKC", 
"NFKD", "fully-normalized", "none" or an implementation-defined 
normalization form.  The default value is "none".  We will also add
a note advising of the interoperability problems that can arise by
using anything other than NFC.

3. All of "NFC", "NFD", "NFKC", "NFKD", "fully-normalized", "none" and
any implementation-defined value are permitted for the xml, xhtml and
text output methods.  The values "NFC", "fully-normalized" and "none"
must be supported by an implementation for these output methods.

4. The normalization-form parameter is permitted to have the values
"NFC", "NFD", "NFKC", "NFKD", "none" or an implementation-defined value
if the output method is "html".  The values "NFC" and "none" must be
supported for the html output method.  The value "fully-normalized" is
not permitted if the output method is "html".

5. In the case of "fully-normalized", the normalization is the same as for 

NFC, but the processor must signal a serialization error if any of the 
"relevant constructs" of the result would begin with a combining 
character.

     The XSL Working Group will also make the corresponding changes to the 
xsl:output element in XSLT 2.0, replacing the normalize-unicode attribute 
with a normalization-form attribute.

     May I ask you to confirm that this response is acceptable?

Thanks,

Henry
[1] 
http://lists.w3.org/Archives/Public/public-qt-comments/2004Jan/0019.html
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

Hello,

     In [1], I asked Igor Hersht to confirm that he found the response to 
the issue labelled "SUGGESTION 4" in [2] acceptable.  I'm responding on 
Igor's behalf to indicate that the response is acceptable to IBM.

Thanks,

Henry
[1] 
http://lists.w3.org/Archives/Public/public-qt-comments/2004Mar/0276.html
[2] 
http://lists.w3.org/Archives/Public/public-qt-comments/2004Jan/0019.html
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

Jonathan said in another thread:

> If you do want to enter this as a last call comment, could you please start 
> a new thread that clearly says that?

I made the following comment on the previous draft serialization document:

http://lists.w3.org/Archives/Public/public-qt-comments/2003Nov/0050.html

Please take that as a last call comment on this draft (as the coment has
not been answered, and the situation is the same in this draft).

David


________________________________________________________________________
This e-mail has been scanned for all viruses by Star Internet. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:
http://www.star.net.uk
________________________________________________________________________

    

Serialization Section 2, "Serializing Arbitrary Data Models": This comment 
recapitulates a discussion from a recent (21 January) meeting of the Query 
and XSLT working groups. It is suggested that the serialization document 
should define two separate and independent processes, possibly called 
"documentization" and "serialization". 

The documentization process should be defined to convert any Query Data 
Model (QDM) instance (which in general may contain zero, one, or many 
documents, or documents mixed with non-document fragments) into a QDM 
instance that contains exactly one document. This can be done by replacing 
each top-level item in the QDM instance by a descriptive "wrapper" element 
that labels it with its kind: attribute, atomic value, element, document, 
etc. A new synthetic document element is then inserted as parent of all 
the wrapper elements.  This documentization process (unlike the one 
currently described in Section 2) should apply successfully to any QDM 
instance whatsoever. Thus (for example) if the QDM instance contains 
multiple documents, the boundaries between these documents is preserved. 
If documentization is invoked on a QDM instance that already contains a 
single document, that document is nevertheless wrapped in a descriptive 
element which is placed under a new synthetic parent document node (it is 
treated simply as a sequence of documents of length one).

The serialization process then needs to be defined only for QDM instances 
that contain exactly one document. A serialization parameter can be 
defined to control whether documentization is applied before serialization 
(possibly documentization could be defined to occur by default if the 
first item in the sequence to be serialized is not a node).

--Don Chamberlin

    

Don,

     In [1] you submitted the following comment on the serialization 
draft:

Don Chamberlin wrote on 2004-02-02 06:37:20 PM:
> Serialization Section 2, "Serializing Arbitrary Data Models": This 
> comment recapitulates a discussion from a recent (21 January) 
> meeting of the Query and XSLT working groups. It is suggested that 
> the serialization document should define two separate and 
> independent processes, possibly called "documentization" and 
"serialization". 
> 
> The documentization process should be defined to convert any Query 
> Data Model (QDM) instance (which in general may contain zero, one, 
> or many documents, or documents mixed with non-document fragments) 
> into a QDM instance that contains exactly one document. This can be 
> done by replacing each top-level item in the QDM instance by a 
> descriptive "wrapper" element that labels it with its kind: 
> attribute, atomic value, element, document, etc. A new synthetic 
> document element is then inserted as parent of all the wrapper 
> elements.  This documentization process (unlike the one currently 
> described in Section 2) should apply successfully to any QDM 
> instance whatsoever. Thus (for example) if the QDM instance contains
> multiple documents, the boundaries between these documents is 
> preserved. If documentization is invoked on a QDM instance that 
> already contains a single document, that document is nevertheless 
> wrapped in a descriptive element which is placed under a new 
> synthetic parent document node (it is treated simply as a sequence 
> of documents of length one). 
> 
> The serialization process then needs to be defined only for QDM 
> instances that contain exactly one document. A serialization 
> parameter can be defined to control whether documentization is 
> applied before serialization (possibly documentization could be 
> defined to occur by default if the first item in the sequence to be 
> serialized is not a node). 

     Thank you for submitting this comment.

     The XSL and XQuery working groups considered your comment and related 
comments.  There was general agreement that there is some need for a 
mechanism for serializing arbitrary sequences that preserves most or all 
of the properties of the items in an arbitrary sequence that is being 
serialized.

     However, the working groups decided that precisely defining all of 
the requirements for such a mechanism at this stage would be difficult, 
and would likely lead to a solution that would not satisfy real user 
requirements.  Therefore, the working groups decided to consider such a 
feature for a future revision of the recommendations, and close this 
comment without any changes to the specifications.

     May I ask you to confirm that this resolution is acceptable?

Thanks,

Henry
[1] 
http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0049.html
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

Henry,
Thanks for your response. I understand why the working group has chosen 
not to provide this feature in XQuery Version 1, and I do not intend to 
pursue this issue further at this time.
Regards,
--Don Chamberlin

Serialization Section 4, "XML Output Method": The first paragraph states 
that serialization produces either an XML document entity or an external 
general parsed entity. No indication is given about how the serialization 
process chooses between these alternatives. The normalization rules in 
Section 2 always reduce the data model instance to exactly one document, 
so it is not clear how the second alternative is ever invoked. 

Also in this section, the second paragraph adds nothing that is not 
already said in the first paragraph. It should be deleted.

--Don Chamberlin

    

The serialization process doesn't choose between these two alternatives
(indeed, the set of well-formed XML document entities and the set of
well-formed EGPEs have a large overlap). Rather, this sentence is
stating a constraint. If the document node contains multiple elements or
text nodes among its children then the result cannot be a well-formed
document entity, therefore it must be a well-formed EGPE. If a
standalone attribute is requested in the serialization parameters, then
the result cannot be a well-formed EGPE, therefore it must be a
well-formed document entity. If both conditions are true, there is a
conflict, and I think there are rules later on about how this conflict
should be resolved.
 
Michael Kay

Hi, Don.

     In [1], you submitted the following comment on the Last Call Working 
Draft of XSLT 2.0 and XQuery 1.0 Serialization:

Don Chamberlin wrote on 2004-02-02 07:14:53 PM:
> Serialization Section 4, "XML Output Method": The first paragraph 
> states that serialization produces either an XML document entity or 
> an external general parsed entity. No indication is given about how 
> the serialization process chooses between these alternatives. The 
> normalization rules in Section 2 always reduce the data model 
> instance to exactly one document, so it is not clear how the second 
> alternative is ever invoked. 
> 
> Also in this section, the second paragraph adds nothing that is not 
> already said in the first paragraph. It should be deleted. 

     Thank you for your comment.

     The XSL and XML Query Working Groups discussed your comment.  It was 
noted that, although there is only ever one document node to process, the 
document node could have no element node children, more than one element 
node child or text node children.  If any of those conditions holds, the 
serialization process produces an external general parsed entity; 
otherwise, it produces a document entity (which might also meet the 
syntactic criteria of an external general parsed entity).

     In order to clarify the first and third paragraphs of section 4, the 
working groups decided to make the following changes:

- in the first sentence of the third paragraph, change "and the"
  to "then", to make it clear the conditions under which a
  document entity will be the result of the serialization process.

- change the wording to make it clear that these rules describe
  requirements on the processor, rather than on the user.  The
  processor will be required to produce a serialization error if
  it is unable to produce a well-formed entity of the appropriate
  kind, unless that is because of the action of the character
  expansion phase of serialization.

     The working groups further agreed that the second paragraph of 
section 4 adds no useful information, and decided to delete it.

     As you were present when this decision was made, I will assume the 
response is acceptable to you.

Thanks,

Henry [On behalf of the XSL and XML Query Working Groups]
[1] 
http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0053.html
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

Serialization Section 4, "XML Output Method": The paragraph before the 
bullet list says that "if a new tree were constructed by parsing the 
[serialized] XML document and converting it into a data model as described 
in [Data Model], then the new data model would be the same as the starting 
data model." But this conversion process involves validation, which is 
schema-dependent. We need to specify that the schema used in this 
round-trip process is an effective schema consisting of the in-scope 
schema definitions in the static context.

--Don Chamberlin

    

After further discussion, it appears that it is not sufficient to use the 
in-scope-schema-definitions (ISSD) during round-tripping (serialization 
and re-parsing) of a data model instance. Round-tripping is used in 
validation, which in turn is used in every element constructor. It is 
necessary for round-tripping to preserve the type annotation of an element 
node, which may not be known in the ISSD. I think the schema used during 
round-tripping needs to be the union of the ISSD and the schema(s) from 
which the type annotations of the nodes were originally derived (called 
the "data model schema" in Section 2.2.5, Consistency Constraints).

--Don Chamberlin

Serialization Section 4, "XML Output Method": This section should specify 
the rules for serializing namespace nodes in the form of namespace 
declaration attributes. Does every namespace node attached to an element 
node result in an xmlns-attribute in that element's start-tag? Can the 
xmlns-attribute be omitted if it is present in the start-tag of a parent 
element?

--Don Chamberlin

    

I don't think it's necessary to specify these rules in detail. Any
output that satisfies the round-tripping constraints is acceptable. The
philosophy of the serialization spec is to state the basic constraints
that the output must specify, and beyond that, to be non-prescriptive. 
 
Michael Kay 

Don,

     In [1], you submitted the following comment on the Last Call Working 
Draft of XSLT 2.0 and XQuery 1.0 Serialization:

> Serialization Section 4, "XML Output Method": This section should 
> specify the rules for serializing namespace nodes in the form of 
> namespace declaration attributes. Does every namespace node attached
> to an element node result in an xmlns-attribute in that element's 
> start-tag? Can the xmlns-attribute be omitted if it is present in 
> the start-tag of a parent element?

     Thank you for your comment.

     The XSL and XML Query Working Groups discussed your comment, and 
concluded that any output that satisfies the round-tripping requirement 
for the XML output method can be used in serializing namespace nodes.  The 
responses to your specific questions are "No, the serialized start-tag for 
an element node does not have to have an xmlns-attribute for every 
namespace node," and "Yes, if an element node has a namespace node, the 
xmlns-attribute can be omitted if the start-tag for an ancestor element 
declares the namespace, subject to the usual constraints imposed by 
namespace undeclaration or changes in binding."  No change to the 
serialization specification is required.

     As you were present when this decision was made, I will assume the 
response is acceptable to you.

Thanks,

Henry [On behalf of the XSL and XML Query Working Groups]
[1] 
http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0057.html
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

Serialization Section 4, "XML Output Method": Bullet 5 says that type 
annotations are discarded during serialization. The note just below this 
bullet says that type annotations are optionally preserved during 
serialization. Which is true? If type annotations are optionally 
preserved, how is this option controlled? Is it implementation-defined, or 
controlled by a serialization parameter? It would be very helpful to have 
a note or example to illustrate how (and when) type annotations are 
serialized in the form of xsi:type attributes.

Also, the note below Bullet 5 is very awkwardly phrased. If retained, this 
note should be condensed as follows: "In order to preserve type 
annotations, the serialization process could use mechanisms such as 
xsi:type and xsi:schemaLocation attributes." 

--Don Chamberlin

    

I agree the wording of the note could be improved. The intent is to say
that type annotations are not retained through serialization, and if
this causes a problem, the user can include xsi:type or
xsi:schemaLocation attributes in the result tree, which will cause type
annotations to be reconstituted when the serialized document is
re-parsed. The serializer will never add these attributes itself. (Well,
there's no ban on an implementor adding options to do this of course,
but it's not part of serialization as specified).
 
Michael Kay

Don,

     In [1], you submitted the following comment on the Last Call Working 
Draft of XSLT 2.0 and XQuery 1.0 Serialization:

XML Query wrote on 2004-02-02 07:15:26 PM:> 
> Serialization Section 4, "XML Output Method": Bullet 5 says that 
> type annotations are discarded during serialization. The note just 
> below this bullet says that type annotations are optionally 
> preserved during serialization. Which is true? If type annotations 
> are optionally preserved, how is this option controlled? Is it 
> implementation-defined, or controlled by a serialization parameter? 
> It would be very helpful to have a note or example to illustrate how
> (and when) type annotations are serialized in the form of xsi:type 
attributes.
> 
> Also, the note below Bullet 5 is very awkwardly phrased. If 
> retained, this note should be condensed as follows: "In order to 
> preserve type annotations, the serialization process could use 
> mechanisms such as xsi:type and xsi:schemaLocation attributes." 

     Thank you for your comment.

     The XSL and XQuery Working Groups discussed your comment and decided 
that the note was intended to indicate that if the user would like type 
annotations to be preserved, the user should ensure the data model that 
the sequence that is input to the serialization process uses xsi:type and 
xsi:schemaLocation attributes.  The note wasn't intended to grant a 
license to the serialization process to manufacture such attributes.

     In order to clarify this, the working groups decided to replace the 
note in the bullet 5 of section 4 with the following:

<<
Note: In order to influence the type annotations in the data model that 
would result from processing a serialized XML document, the author of the 
XSLT stylesheet, XQuery expression or other process may wish to create the 
data model that is input to the serialization process so that it makes use 
of mechanisms provided by [XML Schema], such as xsi:type and 
xsi:schemaLocation attributes.  The serialization process will not 
automatically create such attributes in the serialized document if those 
attributes were not part of the result tree that is to be serialized.
>>

     As you were present when this decision was made, I will take it that 
the decision is acceptable to you.

Thanks,

Henry
[1] 
http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0058.html
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

Serialization Section 4, "XML Output Method": The statement in Bullet 6 is 
backward. Additional namespace nodes may be generated if the serialization 
process FAILS to undeclare namespaces. In addition, the namespace nodes 
may be different after round-tripping because the process of constructing 
an element node from an infoset may ignore namespaces that are not used in 
element or attribute names (see Data Model Section 6.2.4, Element Node 
Construction from Infoset".)

--Don Chamberlin

    

Don,

     In [1], you submitted the following comment on the Last Call Working 
Draft of XSLT 2.0 and XQuery 1.0 Serialization:

<<
Serialization Section 4, "XML Output Method": The statement in Bullet 6 is 
backward. Additional namespace nodes may be generated if the serialization 
process FAILS to undeclare namespaces. In addition, the namespace nodes 
may be different after round-tripping because the process of constructing 
an element node from an infoset may ignore namespaces that are not used in 
element or attribute names (see Data Model Section 6.2.4, Element Node 
Construction from Infoset".)
>>

     Thank you for your comment.

     The XSL and XML Query Working Groups discussed your comment, and 
decided to make the corrections that you had recommended, with a small 
refinement:  that namespace nodes must not be ignored if the round-tripped 
data model instance is constructed from PSVI if the namespace prefix was 
used in a value of type xs:QName.

     As you were present when this decision was made, I will assume the 
response is acceptable to you.

Thanks,

Henry [On behalf of the XSL and XML Query Working Groups]
[1] 
http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0059.html
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

Serialization Section 4, "XML Output Method": Bullet 7 says that 
"Additional nodes may be present in the new tree" due to character 
expansion. Please explain how character expansion could result in new 
nodes and provide an example.

Thanks,
--Don Chamberlin

    

Don,

     In [1], you submitted the following comment on the Last Call Working 
Draft of XSLT 2.0 and XQuery 1.0 Serialization.

> Serialization Section 4, "XML Output Method": Bullet 7 says that 
> "Additional nodes may be present in the new tree" due to character 
> expansion. Please explain how character expansion could result in 
> new nodes and provide an example. 

     Thank you for your comment.

     The XSL and XQuery working groups discussed your comment, and decided 
to add a note to clarify the situation.  I would like to add the following 
note to the final bullet of the bulleted list in section 4.

<<
Note:  The use-character-maps parameter can cause arbitrary characters to 
be inserted into the serialized XML document in an unescaped form, 
including characters that would be considered part of XML markup.  Such 
characters could result in arbitrary new element nodes, attribute nodes, 
and so on, in the new tree that results from processing the serialized XML 
document.
>>

     As you were present when this decision was made, I will take it that 
the decision is acceptable to you.

Thanks,

Henry
[1] 
http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0060.html
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

Serialization Section 4.1, "XML Output Method: the version Parameter": 
This section contains the words "If the processor does not support this 
version of XML ...". This seems to imply that support for XML versions is 
an optional feature. We should clearly specify the requirements in this 
area. Possibly support for XML 1.0 is required and support for XML 1.1 is 
an optional feature that should be included on our optional feature list?

--Don Chamberlin

    

I think the view of the XSL working group was that we should leave it to
the implementor to decide which versions of XML to support. It would be
commercial suicide for a vendor not to support XML 1.0 in a 2004
product, but by 2010 the situation may look different, and we want our
spec to be durable.

Michael Kay

Don,

     In [1], you submitted the following comment on the Last Call Working 
Draft of XSLT 2.0 and XQuery 1.0 Serialization:

<<
Serialization Section 4.1, "XML Output Method: the version Parameter": 
This section contains the words "If the processor does not support this 
version of XML ...". This seems to imply that support for XML versions is 
an optional feature. We should clearly specify the requirements in this 
area. Possibly support for XML 1.0 is required and support for XML 1.1 is 
an optional feature that should be included on our optional feature list?
>>

     Thank you for this comment.

     The XSL and XML Query Working Groups discussed your comment, and 
decided that the Serialization specification should be flexible in this 
regard and not place any requirements on the versions of XML or HTML that 
must be supported, although a particular host language might impose such 
requirements.

     The Serialization draft will be modified to state, for each of the 
xml and html output methods, that it is a serialization error if the value 
of the version parameter specifies a version of the XML or the HTML 
Recommendation that is not supported by the processor.  The Serialization 
draft will not place any requirements on the processor on which versions 
of XML or HTML must be supported by a processor.

     The XQuery Working Group further decided that the XML Query language 
will require the processor to support the value 1.0 in the version 
parameter if the output method is xml. 

     As you were present when this decision was made, I will assume the 
response is acceptable to you.

Thanks,

Henry [On behalf of the XSL and XML Query Working Groups]
[1] 
http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0061.html
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

Serialization Section 4.1, "XML Output Method: the version Parameter": 
This section should explain what it means to serialize a data model using 
XML Version 1.0 or Version 1.1. These versions are distinguished mainly by 
the characters they allow in names. Does the data model need to specify 
which XML version it is using? (Currently the data model does not provide 
any way to do this.) What happens if serialization is using XML Version 
1.0 but it encounters a name that contains a character in the Version 1.1 
character set?

Also, this section should specify whether XML Version 1.1 interpreted to 
include Namespaces Version 1.1 as well. If not, should a separate version 
parameter be defined for this purpose?

--Don Chamberlin

    

The Serialization document says nothing about how the "nilled" property of 
an element node is serialized. Does this property always result in an 
xsi:nil attribute on the generated element? Does this process depend on 
anything (for example, the type of the element and/or whether it is 
"nillable")?

--Don Chamberlin

    

Don,

     In [1], you submitted the following comment on the Last Call Working 
Draft of XSLT 2.0 and XQuery 1.0 Serialization:

> The Serialization document says nothing about how the "nilled" 
> property of an element node is serialized. Does this property always
> result in an xsi:nil attribute on the generated element? Does this 
> process depend on anything (for example, the type of the element 
> and/or whether it is "nillable")? 

     Thank you for your comment.

     The XSL and XQuery working groups discussed your comment and decided 
that it could happen that an element has the nilled property with the 
value true, but has no xsi:nil attribute.  The working groups decided to 
add a note stating that, in such cases, the serialization process will not 
create an xsi:nil attribute for the element.

     As you were present when this decision was made, I will take it that 
the decision is acceptable to you.

Thanks,

Henry
[1] 
http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0064.html
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

It seems useful for the XML output method to allow a canonical 
parameter which if true would cause the processor to emit canonical 
XML. This should not be required of processors, but should be 
allowed. (i.e. it's optional like indent).

The trickiest part is that this could conflict with other properties 
like indent and omit-xml-declaration. The processor could either 
signal an error if there was an explicit conflict, or recover by 
simply outputting canonical XML.  I prefer the latter solution.
-- 

   Elliotte Rusty Harold
   elharo@metalab.unc.edu
   Effective XML (Addison-Wesley, 2003)
   http://www.cafeconleche.org/books/effectivexml
   http://www.amazon.com/exec/obidos/ISBN%3D0321150406/ref%3Dnosim/cafeaulaitA

    

Elliotte,

     In [1], you submitted the following comment on the Last Call Working 
Draft of XSLT 2.0 and XQuery 1.0 Serialization:

> It seems useful for the XML output method to allow a canonical 
> parameter which if true would cause the processor to emit canonical 
> XML. This should not be required of processors, but should be 
> allowed. (i.e. it's optional like indent).
> 
> The trickiest part is that this could conflict with other properties 
> like indent and omit-xml-declaration. The processor could either 
> signal an error if there was an explicit conflict, or recover by 
> simply outputting canonical XML.  I prefer the latter solution.

     Thank you for your comment.

     The XSL and XML Query Working Groups discussed your comment.  The 
working groups decided that it was too late in the process to add a new 
feature to serialization to support canonicalization, particularly in 
light of the fact that a solution to this problem is currently available: 
serialize using the xml output method, and post-process that serialized 
result with a processor that converts the XML documents to the appropriate 
type of canonical XML.  In addition, the lack of type-awareness in 
existing definitions of canonicalization was of concern to the working 
groups.

     May I ask you to confirm that this response is acceptable to you?

Thanks,

Henry [On behalf of the XSL and XML Query Working Groups]
[1] 
http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0146.html
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

Consider the following schema fragment:

<xs:element name="A">
    <xs:complexType>
       <xs:sequence>
          <xs:element name="C" type="myns:Type1"/>
       </xs:sequence>
    </xs:complexType>
</xs:element>

<xs:element name="B">
    <xs:complexType>
       <xs:sequence>
          <xs:element name="C" type="myns:Type2"/>
       </xs:sequence>
    </xs:complexType>
</xs:element>

Now if we consider a document (or any other data source) containing
both A and B elements, the following query

<result>
{
    for $x in doc("myDocument")//C
    return $x
}
</result>

returns a result that cannot be strongly typed without losing type
information by any valid schema, as the schema spec forbids elements
with the same name and a different type in the same content model.

It seems to me that the only way of retaining type information would
be to annotate produced C elements with xsi:type. This could be a
serialization parameter, similar to the
cdata-section-elements. However, this would raise another issue, as
anonymous type names would then be exposed, and would thus require to
be handled in a consistent way by different XQuery and XML Schema
processors.

This issue is important, especially for tools that perform distributed
XQuery processing, and that need to retain consistent type information
when moving XML data from one processing node to another.

Hello,

     In [1], you submitted the following comment on the Last Call Working 
Draft of XSLT 2.0 and XQuery 1.0 Serialization:

<<
Consider the following schema fragment:

<xs:element name="A">
    <xs:complexType>
       <xs:sequence>
          <xs:element name="C" type="myns:Type1"/>
       </xs:sequence>
    </xs:complexType>
</xs:element>

<xs:element name="B">
    <xs:complexType>
       <xs:sequence>
          <xs:element name="C" type="myns:Type2"/>
       </xs:sequence>
    </xs:complexType>
</xs:element>

Now if we consider a document (or any other data source) containing
both A and B elements, the following query

<result>
{
    for $x in doc("myDocument")//C
    return $x
}
</result>

returns a result that cannot be strongly typed without losing type
information by any valid schema, as the schema spec forbids elements
with the same name and a different type in the same content model.

It seems to me that the only way of retaining type information would
be to annotate produced C elements with xsi:type. This could be a
serialization parameter, similar to the
cdata-section-elements. However, this would raise another issue, as
anonymous type names would then be exposed, and would thus require to
be handled in a consistent way by different XQuery and XML Schema
processors.

This issue is important, especially for tools that perform distributed
XQuery processing, and that need to retain consistent type information
when moving XML data from one processing node to another.
>>

     Thank you for this comment.  The XSL and XML Query Working Groups 
discussed your comment and several related comments.  There was general 
agreement that there is some need for a mechanism that preserves most or 
all of the properties of the items in the sequence that is being 
serialized.

     However, the working groups decided that precisely defining all of 
the requirements for such a mechanism at this stage would be difficult, 
and would likely lead to a solution that would not satisfy real user 
requirements.  Therefore, the working groups decided to consider such a 
feature for a future revision of the recommendations, and close this 
comment without any changes to the specifications.

     May I ask you to confirm that this response is acceptable to you?

Thanks,

Henry [On behalf of the XSL and XML Query Working Groups]
[1] 
http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0188.html
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

Technical

[A] [Section 3: Serialization Parameters] This section outlines 15
serialization parameters. These parameters have informal descriptions - such
as 'The value must be yes or no', etc. It is possible to describe all the
parameters, except 'use-character-maps', using XML Schema data types.
Suggested descriptions are,

 encoding: a new datatype derived from 'xs:string'
 cdata-section-element: a list of 'xs:QName'
 doctype-system: a new datatype derived from 'xs:string'
 doctype-public: a new datatype derived from 'xs:string'
 escape-uri-attributes: 'xs:boolean'
 include-content-type: 'xs:boolean'
 indent: 'xs:boolean'
 media-type: a new datatype derived from 'xs:string'
 normalize-unicode: 'xs:boolean'
 omit-xml-declaration: 'xs:boolean'
 standalone: 'xs:boolean'
 undeclare-namespaces: 'xs:boolean'
 version: a new datatype derived from 'xs:string'
 use-character-maps: NONE (see related issue, [N])
 method: 'xs:QName'


On behalf of the XML Schema WG.

	-- Mary
	   Holstege@mathling.com

    

Seems a good idea in principle. The types as listed aren't quite right,
for example standalone is xs:boolean? rather than xs:boolean, but this
only adds to the argument for formalising them.

Michael Kay (personal response)

Mary,

     In [1], you submitted the following comment on the Serialization last 
call draft on behalf of the XML Schema WG.

Mary Holstege wrote on 2004-02-12 04:11:28 PM:
> [A] [Section 3: Serialization Parameters] This section outlines 15
> serialization parameters. These parameters have informal descriptions - 
such
> as 'The value must be yes or no', etc. It is possible to describe all 
the
> parameters, except 'use-character-maps', using XML Schema data types.
> Suggested descriptions are,
> 
>  encoding: a new datatype derived from 'xs:string'
>  cdata-section-element: a list of 'xs:QName'
>  doctype-system: a new datatype derived from 'xs:string'
>  doctype-public: a new datatype derived from 'xs:string'
>  escape-uri-attributes: 'xs:boolean'
>  include-content-type: 'xs:boolean'
>  indent: 'xs:boolean'
>  media-type: a new datatype derived from 'xs:string'
>  normalize-unicode: 'xs:boolean'
>  omit-xml-declaration: 'xs:boolean'
>  standalone: 'xs:boolean'
>  undeclare-namespaces: 'xs:boolean'
>  version: a new datatype derived from 'xs:string'
>  use-character-maps: NONE (see related issue, [N])
>  method: 'xs:QName'

     Thanks to you and the Schema WG for this comment.

     The XSL and XQuery working groups considered the comment, and agreed 
that the definitions of the permissible sets of values need to be 
specified more clearly.  However, the working groups did not feel it was 
necessary to describe the values with reference to the XML Schema data 
types, as the serialization parameters are not part of an API, but merely 
a formalism used between specifications.

     The working groups would like to replace the descriptions of the 
values of the parameters that appears in the bulleted list in Section 3, 
with a table.  The following is my proposed replacement.

<<
+----------------------+------------------------------------------------+
|PARAMETER NAME        |PERMITTED VALUES FOR PARAMETER                  |
+----------------------+------------------------------------------------+
|cdata-section-elements|A list of expanded-QNames, possibly empty.      |
+----------------------+------------------------------------------------+
|doctype-public        |A string of Unicode characters.  This parameter |
|                      |is optional.                                    |
+----------------------+------------------------------------------------+
|doctype-system        |A string of Unicode characters.  This parameter |
|                      |is optional.                                    |
+----------------------+------------------------------------------------+
|encoding              |A string of Unicode characters in the range #x21|
|                      |to #x7E (that is, printable ASCII characters);  |
|                      |the value should be a charset registered with   |
|                      |the Internet Assigned Numbers Authority [IANA], |
|                      |[RFC2278] or begin with the characters x- or X-.|
+----------------------+------------------------------------------------+
|escape-uri-attributes |One of the enumerated values yes or no          |
+----------------------+------------------------------------------------+
|include-content-type  |One of the enumerated values yes or no          |
+----------------------+------------------------------------------------+
|indent                |One of the enumerated values yes or no          |
+----------------------+------------------------------------------------+
|media-type            |A string of Unicode characters specifying the   |
|                      |media type (MIME content type) [RFC2376]; the   |
|                      |charset parameter of the media type must not be |
|                      |specified explicitly.                           |
+----------------------+------------------------------------------------+
|method                |An expanded-QName with a null namespace URI, and|
|                      |the local part of the name equal to xml, xhtml, |
|                      |html or text, or having a non-null namespace    |
|                      |URI.  If the namespace URI is non-null, the     |
|                      |parameter specifies an implementation-defined   |
|                      |output method.                                  |
+----------------------+------------------------------------------------+
|normalize-unicode     |One of the enumerated values yes or no          |
+----------------------+------------------------------------------------+
|omit-xml-declaration  |One of the enumerated values yes or no          |
+----------------------+------------------------------------------------+
|standalone            |One of the enumerated values yes, no or none    |
+----------------------+------------------------------------------------+
|undeclare-namespaces  |One of the enumerated values yes or no          |
+----------------------+------------------------------------------------+
|use-character-maps    |A list of pairs, possibly empty, with each pair |
|                      |consisting of a single Unicode character and a  |
|                      |string of Unicode characters.                   |
+----------------------+------------------------------------------------+
|version               |A string of Unicode characters.                 |
+----------------------+------------------------------------------------+
>>

     May I ask you to confirm that this response is acceptable to the XML 
Schema WG?

Thanks,

Henry
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

The Schema WG thanks you for your response. We find your response a distinct
improvement and are content with it, although certain members of the WG
continue to feel that the definitions would be cleaner if you did, in fact, go
the final step to using concrete datatypes for the serialization parameter
definitions. 

//Mary

Technical

[B] [Section 2: Serializing Arbitrary Data Models] "cast as xs:string" is a
key phrase in this section. To improve readability, there should be a
pointer to what "cast as xs:string" means.

We found 2 locations where how to "cast as xs:string" is indirectly
described,

[1]
http://www.w3.org/TR/2003/WD-xpath-datamodel-20031112/#ElementNodeAccessors
(see dm:string-value)
[2]
http://www.w3.org/TR/2003/WD-xpath-datamodel-20031112/#AttributeNodeAccessors 
(see dm:string-value)

We found 1 location where how to "cast to string is directly described,

[3] http://www.w3.org/TR/2003/WD-xpath-functions-20031112/#casting-to-string


On behalf of the XML Schema WG.

	-- Mary
	   Holstege@mathling.com

    

Mary,

     In [1], you submitted the following comment on the Last Call Working 
Draft of XSLT 2.0 and XQuery 1.0 Serialization on behalf of the XML Schema 
Working Group:

> [B] [Section 2: Serializing Arbitrary Data Models] "cast as xs:string" 
is a
> key phrase in this section. To improve readability, there should be a
> pointer to what "cast as xs:string" means.
> 
> We found 2 locations where how to "cast as xs:string" is indirectly
> described,
> 
> [1]
> 
http://www.w3.org/TR/2003/WD-xpath-datamodel-20031112/#ElementNodeAccessors

> (see dm:string-value)
> [2]
> 
http://www.w3.org/TR/2003/WD-xpath-datamodel-20031112/#AttributeNodeAccessors

> (see dm:string-value)
> 
> We found 1 location where how to "cast to string is directly described,
> 
> [3] 
http://www.w3.org/TR/2003/WD-xpath-functions-20031112/#casting-to-string

     Thanks to you and to the working group for this comment.

     The XSL and XML Query Working Groups discussed the comment, and 
agreed that the description should indicate that Section 2 of 
Serialization should refer to a normative definition of casting to string. 
 The working groups decided the normative definition should be that found 
in the Functions and Operators draft.[3]

     May I ask you to confirm that the working group finds the response 
acceptable?

Thanks,

Henry [On behalf of the XSL and XML Query Working Groups]
[4] 
http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0262.html
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

The Schema WG thanks you for your response to our comment, and are happy with
it.

//Mary

Technical

[C] [Section 2: Serializing Arbitrary Data Models] Saying the process fails
for sequences containing xs:QName or xs:NOTATION nodes seems unhelpful. What
happens if I have such a sequence? This appears to be a serialization error
because processor is unable to cast an atomic value to string. Suggestion:
replace 'process will fail' statement with 'serialization error'.

On behalf of the XML Schema WG.

	-- Mary
	   Holstege@mathling.com

    

Mary,

     In [1], you submitted the following comment on the Last Call Working 
Draft of XSLT 2.0 and XQuery 1.0 Serialization on behalf of the XML Schema 
Working Group:

> [C] [Section 2: Serializing Arbitrary Data Models] Saying the process 
fails
> for sequences containing xs:QName or xs:NOTATION nodes seems unhelpful. 
What
> happens if I have such a sequence? This appears to be a serialization 
error
> because processor is unable to cast an atomic value to string. 
Suggestion:
> replace 'process will fail' statement with 'serialization error'.

     Thanks to you and the working group for this comment.

     The XSL and XML Query Working Groups discussed the comment, and 
agreed that the description should indicate that this is a serialization 
error.  In fact, the second and sixth items in the numbered list in 
Section 2 already normatively indicate that fact.  For clarity, the note 
in Section 2 will be changed to use the term "serialization error" as 
well.

     As that is the change the XML Schema Working Group recommended, I 
trust it will be acceptable.  May I ask you to confirm that the working 
group finds the response acceptable?

Thanks,

Henry [On behalf of the XSL and XML Query Working Groups]
[1] 
http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0263.html
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

Henry Zongaro writes:
> 
> Mary,
> 
>      In [1], you submitted the following comment on the Last Call Working 
> Draft of XSLT 2.0 and XQuery 1.0 Serialization on behalf of the XML Schema 
> Working Group:
> 
> > [C] [Section 2: Serializing Arbitrary Data Models] Saying the process 
> fails
> > for sequences containing xs:QName or xs:NOTATION nodes seems unhelpful. 
> What
> > happens if I have such a sequence? This appears to be a serialization 
> error
> > because processor is unable to cast an atomic value to string. 
> Suggestion:
> > replace 'process will fail' statement with 'serialization error'.
> 
>      Thanks to you and the working group for this comment.
> 
>      The XSL and XML Query Working Groups discussed the comment, and 
> agreed that the description should indicate that this is a serialization 
> error.  In fact, the second and sixth items in the numbered list in 
> Section 2 already normatively indicate that fact.  For clarity, the note 
> in Section 2 will be changed to use the term "serialization error" as 
> well.
> 
>      As that is the change the XML Schema Working Group recommended, I 
> trust it will be acceptable.  May I ask you to confirm that the working 
> group finds the response acceptable?

The Schema WG thanks you for this response. We find the clarification as a
serialization error an improvement and accept that. We continue to be deeply
troubled, however, by the fact that data models with xs:QNames fail to
serialize and therefore validate correctly. We are heartened by our knowledge
that the Query/XSL Working groups have continued to discuss that matter, and
encourage them in that effort.

//Mary

Technical

[D] [Section 1: Introduction] "Ed. Note: This material has been moved out of
the XSLT draft and into a separate document. The Working Groups also
considered moving this material directly into the Data Model document, but
elected to keep it separate for the moment, principally in order to advance
the Data Model to Last Call. In the future, this material may be moved into
the Data Model. The Working Groups solicit public opinion about which
alternative is superior. "

We prefer keeping this material in this separate document. This way, it
makes serialization as independent as possible.


On behalf of the XML Schema WG.

	-- Mary
	   Holstege@mathling.com

    

Mary,

     In [1], you submitted the following comment on the Last Call Working 
Draft of XSLT 2.0 and XQuery 1.0 Serialization on behalf of the XML Schema 
working group:

<<
[D] [Section 1: Introduction] "Ed. Note: This material has been moved out 
of
the XSLT draft and into a separate document. The Working Groups also
considered moving this material directly into the Data Model document, but
elected to keep it separate for the moment, principally in order to 
advance
the Data Model to Last Call. In the future, this material may be moved 
into
the Data Model. The Working Groups solicit public opinion about which
alternative is superior. "

We prefer keeping this material in this separate document. This way, it
makes serialization as independent as possible.
>>

     Thanks to you and the schema working group for this comment.

     The XSL and XML Query Working Groups discussed the comment, and 
agreed that it would be best to specify the serialization process in a 
separate document.  The editorial note will be deleted.

     I trust the XML Schema Working Group will find that response 
acceptable, as it is as they suggested.  May I ask you to confirm that it 
is?

Thanks,

Henry [On behalf of the XSL and XML Query Working Groups]
[1] 
http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0264.html
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

Technical/Editorial

[E] [Section 2: Serializing Arbitrary Data Models] This section talks about
serialization of a "arbitrary" data model but in fact will fail for some
data model instances. In addition, section 4 implicitly adds additional
constraints on the data model (by putting constraints on the serialized
form) without making it clear what those constraints are.

Suggested changes are,

- Change title of section 2 to Normalization.
- Be clearer about actual goal (in particular: to serialize to well formed
XML? to serialize to XML in such a way as to ensure 1:1 roundtrippability?
other?).
- List explicitly the conditions for successful serialization (and/or
successful serialization to Well Formed XML, and/or successful serialization
to XML which when schema-validated will produce the same data model
instance).

Section 4  (XML Output Method)  does state:
   "The xml output method outputs the data model as an XML entity that must
   satisfy the rules for either a well-formed XML document entity or a
   well-formed XML external general parsed entity, or both, unless the
   processor is unable to satisfy those rules due to either serialization
   errors or the requirements of the character expansion phase of
   serialization, as described in 3 Serialization Parameters."

It is not clear what happens when there are problems (when "the
processor is unable to satisfy those rules"): failure? output of
non-WF XML?

On behalf of the XML Schema WG.

	-- Mary
	   Holstege@mathling.com

    

Technical/Editorial

[F] [Section 2: Serializing Arbitrary Data Models] The first paragraph of
this section states:

"An instance of the data model that is input to the serialization process is
a sequence. The serialization process must first place that input sequence
into a normalized form for serialization; it is the normalized sequence that
is actually serialized. The normalized form for serialization is constructed
by applying all of the following rules in order, with the initial sequence
being input to the first step, and the sequence that results from any step
being used as input to the subsequent step."

We think wording in this section tends to imply a required implementation,
which, given the destructive nature of the implementation described, leads to
the conclusion that serialized data models cannot subsequently be used for
anything else. We believe what is intended is the description of a mapping
between data models and normalized data models, without attempting to constrain
implementations. We request that the text in this section be recast in a more
declarative fashion to make these intentions clear.

On behalf of the XML Schema WG.

	-- Mary
	   Holstege@mathling.com

    

Technical/Editorial

[G] [Section 3: Serialization Parameters] Namespace binding generation ought
to be explicitly called out either as its own phase or as part of markup
generation.


On behalf of the XML Schema WG.

	-- Mary
	   Holstege@mathling.com

    

Technical/Editorial

[H] [Section 4: XML Output Method] The exception to the round-trippability
of the serialization is unclear: "Additional nodes may be present in the new
tree, and the values of attribute nodes and text nodes in the new tree may
be different from those in the original tree, due to the character expansion
phase of serialization."

What additional nodes may be present? How may they differ? As written this
sentence is ambiguous and may be read as allowing _any_ additional nodes in
the tree. 


On behalf of the XML Schema WG.

	-- Mary
	   Holstege@mathling.com

    

Mary,

     In [1], you submitted the following comment on the Last Call Working 
Draft of XSLT 2.0 and XQuery 1.0 Serialization on behalf of the XML Schema 
Working Group.

> [H] [Section 4: XML Output Method] The exception to the 
round-trippability
> of the serialization is unclear: "Additional nodes may be present in the 
new
> tree, and the values of attribute nodes and text nodes in the new tree 
may
> be different from those in the original tree, due to the character 
expansion
> phase of serialization."
> 
> What additional nodes may be present? How may they differ? As written 
this
> sentence is ambiguous and may be read as allowing _any_ additional nodes 
in
> the tree. 

     Thanks to Mary and the XML Schema Working Group for this comment.

     The XSL and XQuery Working Groups discussed the comment, and decided 
to add a note to clarify the situation.  I would like to add the following 
note to the final bullet of the bulleted list in section 4.

<<
Note:  The use-character-maps parameter can cause arbitrary characters to 
be inserted into the serialized XML document in an unescaped form, 
including characters that would be considered part of XML markup.  Such 
characters could result in arbitrary new element nodes, attribute nodes, 
and so on, in the new tree that results from processing the serialized XML 
document.
>>

     May I ask you to confirm that this response is acceptable to the XML 
Schema Working Group?

Thanks,

Henry
[1] 
http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0268.html
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

>      The XSL and XQuery Working Groups discussed the comment, and decided 
> to add a note to clarify the situation.  I would like to add the following 
> note to the final bullet of the bulleted list in section 4.
> 
> <<
> Note:  The use-character-maps parameter can cause arbitrary characters to 
> be inserted into the serialized XML document in an unescaped form, 
> including characters that would be considered part of XML markup.  Such 
> characters could result in arbitrary new element nodes, attribute nodes, 
> and so on, in the new tree that results from processing the serialized XML 
> document.
> >>
> 
>      May I ask you to confirm that this response is acceptable to the XML 
> Schema Working Group?

The Schema WG thanks you for your response, and finds it acceptable.

	-- Mary
	   Holstege@mathling.com

Technical/Editorial

[I] [Section 4.3: XML Output Method: the indent Parameter] licenses the
addition of additional whitespace; this is not called out as permitted under
the rules in section 4, however.


On behalf of the XML Schema WG.

	-- Mary
	   Holstege@mathling.com

    

Mary,

     In [1], you submitted the following comment on the Last Call Working 
Draft of XSLT 2.0 and XQuery 1.0 Serialization on behalf of the XML Schema 
Working Group.

> [I] [Section 4.3: XML Output Method: the indent Parameter] licenses the
> addition of additional whitespace; this is not called out as permitted 
under
> the rules in section 4, however.

     Thanks to you and the XML Schema Working Group for this comment.

     The XSL and XQuery Working Groups discussed the comment, and agreed. 
The following item will be added to the bulleted list in section 4 to 
address this comment:

<<
o Additional text nodes consisting of whitespace characters may be present 
in the new tree and some text nodes in the new tree may contain additional 
whitespace characters that were not present in the original tree if the 
indent parameter has the value yes, as described in 4.3 XML Output Method: 
the indent Parameter.
>>

     May I ask you to confirm that this response is acceptable to the XML 
Schema Working Group?

Thanks,

Henry
[1] 
http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0269.html
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

Henry Zongaro writes:
>      The XSL and XQuery Working Groups discussed the comment, and agreed. 
> The following item will be added to the bulleted list in section 4 to 
> address this comment:
> 
> <<
> o Additional text nodes consisting of whitespace characters may be present 
> in the new tree and some text nodes in the new tree may contain additional 
> whitespace characters that were not present in the original tree if the 
> indent parameter has the value yes, as described in 4.3 XML Output Method: 
> the indent Parameter.
> >>
> 
>      May I ask you to confirm that this response is acceptable to the XML 
> Schema Working Group?

The Schema WG thanks you for this response and finds it acceptable.


	-- Mary
	   Holstege@mathling.com

Technical

[K] [General] In the absence of 'Conformance' Section, what should a
processor do to claim conformance to this specification?

On behalf of the XML Schema WG.

	-- Mary
	   Holstege@mathling.com

    

Technical

[L] [Section 4.1] Given that XML 1.1 is not [Should be "now". HZ] a
recommendation, we believe that
the serialization specification should give guidance to users and implementers
about serializing as 1.0 or 1.1. We believe this section (4.1) is a good start,
but needs more details about how serializers should deal with characters in the
range x00 to x1F (ref http://www.w3.org/TR/2004/REC-xml11-20040204/#sec-xml11). 
See our related comment on the data model.

On behalf of the XML Schema WG.

	-- Mary
	   Holstege@mathling.com

    

Dear XML Query WG and XSL WG,

Below please find the I18N WGs comments on your last call document
"XSLT 2.0 and XQuery 1.0 Serialization"
(http://www.w3.org/TR/2003/WD-xslt-xquery-serialization-20031112/).

Please note the following:
- Please address all replies to there comments to the I18N IG mailing
   list (w3c-i18n-ig@w3.org), not just to me.
- Our comments are numbered in square brackets [nn].


We look forward to further discussion with you.

[this mail is copied to the DOM WG to tell them what we are
telling you about UTF-16 and endianness, which they should
adopt for the
Document Object Model (DOM) Level 3 Load and Save Specification]

[4] This only defines serialization into bytes. In some contexts
   (e.g. Databases, in-program,...), serialization into a stream
   of characters is also important. The spec should specify how
   this is done.

Regards,    Martin.

Hello,

     In [1], Martin Duerst submitted the following comment on the Last 
Call Working Draft of XSLT 2.0 and XQuery 1.0 Serialization on behalf of 
the I18N Working Group.

> [4] This only defines serialization into bytes. In some contexts
>    (e.g. Databases, in-program,...), serialization into a stream
>    of characters is also important. The spec should specify how
>    this is done.

     Thanks to Martin and the I18N Working Group for this comment.

     The XSL and XQuery Working Groups discussed the comment.  The working 
groups noted that there is an analogy in parsing XML documents.  XML 1.0 
and XML 1.1 parsed entities are defined as sequences of character code 
points, each in some encoding.  Though it is common practice to parse XML 
documents that have already been decoded into a sequence of characters, 
the XML 1.0 and XML 1.1 Recommendations do not describe the actions of an 
XML processor in those terms.

     Based on this analogy, the working groups decided that it was not 
appropriate for Serialization to specify normatively how to serialize into 
a stream of characters.  The working groups did decide to add a note to 
Section 3 of Serialization indicating that a processor could provide an 
option that would permit the fourth phase of serialization (Encoding) to 
be skipped.

     May I ask the I18N Working Group to confirm that this response is 
acceptabe?

Thanks,

Henry [On behalf of the XSL and XQuery Working Groups.]
[1] 
http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0362.html
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

Henry Zongaro a écrit :
>      In [1], Martin Duerst submitted the following comment on the Last 
> Call Working Draft of XSLT 2.0 and XQuery 1.0 Serialization on behalf of 
> the I18N Working Group.
> 
> 
>>[4] This only defines serialization into bytes. In some contexts
>>   (e.g. Databases, in-program,...), serialization into a stream
>>   of characters is also important. The spec should specify how
>>   this is done.
> 
> 
>      Thanks to Martin and the I18N Working Group for this comment.
> 
>      The XSL and XQuery Working Groups discussed the comment.  The working 
> groups noted that there is an analogy in parsing XML documents.  XML 1.0 
> and XML 1.1 parsed entities are defined as sequences of character code 
> points, each in some encoding.  Though it is common practice to parse XML 
> documents that have already been decoded into a sequence of characters, 
> the XML 1.0 and XML 1.1 Recommendations do not describe the actions of an 
> XML processor in those terms.
> 
>      Based on this analogy, the working groups decided that it was not 
> appropriate for Serialization to specify normatively how to serialize into 
> a stream of characters.  The working groups did decide to add a note to 
> Section 3 of Serialization indicating that a processor could provide an 
> option that would permit the fourth phase of serialization (Encoding) to 
> be skipped.

We are not really satisfied with this resolution and would like to 
request further clarification.  In particular, conformance when one is 
actually serializing to characters instead of bytes is not clear at all 
to us.  Allowing this but not normatively is very strange, one is left 
to wonder what would be the conformance status of an implementation that 
*only* serializes to characters (because that's all that is required in 
a given context).

> [1] 
> http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0362.html

Regards,

-- 
François Yergeau

Hello, François.

François Yergeau wrote on 2004-06-14 09:28:11 PM:
>Henry Zongaro a écrit :
>>      In [1], Martin Duerst submitted the following comment on the Last 
>> Call Working Draft of XSLT 2.0 and XQuery 1.0 Serialization on behalf 
of 
>> the I18N Working Group.
>> 
>>>[4] This only defines serialization into bytes. In some contexts
>>>   (e.g. Databases, in-program,...), serialization into a stream
>>>   of characters is also important. The spec should specify how
>>>   this is done.
>>      The XSL and XQuery Working Groups discussed the comment.  The 
working 
>> groups noted that there is an analogy in parsing XML documents.  XML 
1.0 
>> and XML 1.1 parsed entities are defined as sequences of character code 
>> points, each in some encoding.  Though it is common practice to parse 
XML 
>> documents that have already been decoded into a sequence of characters, 

>> the XML 1.0 and XML 1.1 Recommendations do not describe the actions of 
an 
>> XML processor in those terms.
>> 
>>      Based on this analogy, the working groups decided that it was not 
>> appropriate for Serialization to specify normatively how to serialize 
into 
>> a stream of characters.  The working groups did decide to add a note to 

>> Section 3 of Serialization indicating that a processor could provide an 

>> option that would permit the fourth phase of serialization (Encoding) 
to 
>> be skipped.
>
>We are not really satisfied with this resolution and would like to 
>request further clarification.  In particular, conformance when one is 
>actually serializing to characters instead of bytes is not clear at all 
>to us.  Allowing this but not normatively is very strange, one is left 
>to wonder what would be the conformance status of an implementation that 
>*only* serializes to characters (because that's all that is required in 
>a given context).
> 
>> [1] 
>> 
http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0362.html

     Thank you for your response.  The intent of the note was to indicate 
that an implementer might supply such a feature as an extension, because 
it is often required, but that such a feature is explicitly beyond the 
scope of the specification.  An implementer might supply anything as an 
extension, and doesn't require permission to do so - we would just like to 
mention this one as a useful extension.

     Here is the text of the note that I'm proposing:

<<
Note: Serialization is only defined in terms of encoding the result as a 
stream of bytes. However, a processor may provide an option that allows 
the encoding phase to be skipped, so that the result of serialization is a 
stream of Unicode characters. The effect of any such option is 
implementation-defined, and a processor is not required to support such an 
option.
>>

     I don't believe there is a question of conformance here. 
Serialization to characters is explicitly a usage that is beyond the 
specification, and the behaviour of a processor that supplies such a 
feature is unspecified.  Similarly, many XML parsers are able to parse 
characters in addition to parsing encoded characters, but the conformance 
of such parsers is not in question in spite of the fact that this feature 
is an extension that is not described by the XML 1.0 or 1.1 
Recommendations.

     Does the I18N Working Group feel it would be better not to include 
such a note at all?

Thanks,

Henry
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

Dear XML Query WG and XSL WG,

Below please find the I18N WGs comments on your last call document
"XSLT 2.0 and XQuery 1.0 Serialization"
(http://www.w3.org/TR/2003/WD-xslt-xquery-serialization-20031112/).

Please note the following:
- Please address all replies to there comments to the I18N IG mailing
   list (w3c-i18n-ig@w3.org), not just to me.
- Our comments are numbered in square brackets [nn].


We look forward to further discussion with you.

[this mail is copied to the DOM WG to tell them what we are
telling you about UTF-16 and endianness, which they should
adopt for the
Document Object Model (DOM) Level 3 Load and Save Specification]

[5] Section 2, point 3: "each separated by a single space":
   Inserting a space may not be the right thing, in particular for
   Chinese, Japanese, Thai,... which don't have spaces between words.
   This has to be checked very carefully.

Regards,    Martin.

This isn't trying to achieve linguistic separation, it is trying to
achieve separation of tokens that meets the rules defined in XML Schema.
XML Schema allows any sequence of whitespace characters between the
items in a list, we mandate a single space character because that's the
simplest whitespace sequence.

Hello,

     In [1], Martin Duerst submitted the following comment on the Last 
Call Working Draft of XSLT 2.0 and XQuery 1.0 Serialization on behalf of 
the I18N Working Group:

> [5] Section 2, point 3: "each separated by a single space":
>    Inserting a space may not be the right thing, in particular for
>    Chinese, Japanese, Thai,... which don't have spaces between words.
>    This has to be checked very carefully.

     Thanks to Martin and the working group for this comment.

     The XSL and XML Query Working Groups discussed the comment, and 
decided that no change to the Serialization specification is required. The 
reason for separating each pair of string values by a single space is not 
to achieve any kind of linguistic separation of words, but to separate 
values in a way that would be consistent with the requirements for an XML 
Schema type derived by list, for instance.

     May I ask the I18N Working Group to confirm that this response is 
acceptable?

Thanks,

Henry [On behalf of the XSL and XML Query Working Groups]
[1] 
http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0362.html
[2] 
http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0401.html
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

Hello Henry,

Many thanks for your responses. The I18N WG (Core TF) has looked
at your response below, and unfortunately, we have to say that we
cannot accept it. At the least, we need some more information
exchange to make sure we understand each other well.

Below, you write that the convention of inserting a space isn't
for linguistic separation, but for creating XML Schema lists.
This may be the intention of the spec-writers, but who guarantees
that this is how this will be used? In cases where it will be used
in other ways, there would be serious problems when adapting a
query or transformation to a different language (in particular
Chinese, Japanese, Thai,...).

So in particular, we need to know more about the following questions:
- How/when/why would sequences of strings (or other atomic data types)
   typically be generated?
- How would e.g. combinations of data values, strings,... be serialized
   other than though this mechanism? We think that in many cases, in
   particular for XML Query, this could be the mechanism of choice to
   write out texts mixed with e.g. stringified numbers.
- What would the effort be to change a script relying on this mechanism
   so that it works for Chinese/Japanese,...?
- How can the distinction between strings and text nodes be used to
   affect/create the right behavior, and how can we make sure that
   programmers use the solution that is easily adapted to all kinds
   of languages.

Regards,    Martin.


At 11:55 04/04/28 -0400, Henry Zongaro wrote:

>Hello,
>
>      In [1], Martin Duerst submitted the following comment on the Last
>Call Working Draft of XSLT 2.0 and XQuery 1.0 Serialization on behalf of
>the I18N Working Group:
>
> > [5] Section 2, point 3: "each separated by a single space":
> >    Inserting a space may not be the right thing, in particular for
> >    Chinese, Japanese, Thai,... which don't have spaces between words.
> >    This has to be checked very carefully.
>
>      Thanks to Martin and the working group for this comment.
>
>      The XSL and XML Query Working Groups discussed the comment, and
>decided that no change to the Serialization specification is required. The
>reason for separating each pair of string values by a single space is not
>to achieve any kind of linguistic separation of words, but to separate
>values in a way that would be consistent with the requirements for an XML
>Schema type derived by list, for instance.
>
>      May I ask the I18N Working Group to confirm that this response is
>acceptable?
>
>Thanks,
>
>Henry [On behalf of the XSL and XML Query Working Groups]
>[1]
>http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0362.html
>[2]
>http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0401.html
>------------------------------------------------------------------
>Henry Zongaro      Xalan development
>IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
>mailto:zongaro@ca.ibm.com

Dear XML Query WG and XSL WG,

Below please find the I18N WGs comments on your last call document
"XSLT 2.0 and XQuery 1.0 Serialization"
(http://www.w3.org/TR/2003/WD-xslt-xquery-serialization-20031112/).

Please note the following:
- Please address all replies to there comments to the I18N IG mailing
   list (w3c-i18n-ig@w3.org), not just to me.
- Our comments are numbered in square brackets [nn].


We look forward to further discussion with you.

[this mail is copied to the DOM WG to tell them what we are
telling you about UTF-16 and endianness, which they should
adopt for the
Document Object Model (DOM) Level 3 Load and Save Specification]

[6] Section 3, 'encoding': Given that this is already required for
   the XML output method, we think it's highly desirable to make
   the requirement for support for UTF-8 and UTF-16 general
   (including text).

Regards,    Martin.

I can't think of any reason not to make this change.

Martin,

     In [1], you submitted the following comment on the Last Call Working 
Draft of XSLT 2.0 and XQuery 1.0 Serialization on behalf of the I18N 
working group:

<<
[6] Section 3, 'encoding': Given that this is already required for
   the XML output method, we think it's highly desirable to make
   the requirement for support for UTF-8 and UTF-16 general
   (including text).
>>

     Thanks to you and the I18N working group for this comment.

     The XSL and XML Query Working Groups discussed the working group's 
comment, and decided to accept the I18N working group's suggestion.  The 
serialization specification will be modified to require support for UTF-8 
and UTF-16 encodings for all the output methods defined by the 
specification - namely, the xml, xhtml, html and text output methods.

     As this is the change the I18N working group proposed, I believe the 
response should be acceptable to the working group.  May I ask you to 
confirm that it is?

Thanks,

Henry [On behalf of the XSL and XML Query Working Groups]
[1] 
http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0362.html
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

Dear XML Query WG and XSL WG,

Below please find the I18N WGs comments on your last call document
"XSLT 2.0 and XQuery 1.0 Serialization"
(http://www.w3.org/TR/2003/WD-xslt-xquery-serialization-20031112/).

Please note the following:
- Please address all replies to there comments to the I18N IG mailing
   list (w3c-i18n-ig@w3.org), not just to me.
- Our comments are numbered in square brackets [nn].


We look forward to further discussion with you.

[this mail is copied to the DOM WG to tell them what we are
telling you about UTF-16 and endianness, which they should
adopt for the
Document Object Model (DOM) Level 3 Load and Save Specification]

[7] Section 3, 'encoding': Here or for each individual output method,
   something should be said about the BOM. We think it should be
   the following:
   - XML/XHTML: UTF-16: required; UTF-8: may be used.
   - HTML/text: UTF-16: recommended; UTF-8: may be used.

Regards,    Martin.

I agree. In Saxon, I've added an extension attribute to control whether
a BOM should be emitted, and I think it would be a good idea to make
this a standard feature. The default should be yes for UTF-16, no for
UTF-8.

Dear XML Query WG and XSL WG,

Below please find the I18N WGs comments on your last call document
"XSLT 2.0 and XQuery 1.0 Serialization"
(http://www.w3.org/TR/2003/WD-xslt-xquery-serialization-20031112/).

Please note the following:
- Please address all replies to there comments to the I18N IG mailing
   list (w3c-i18n-ig@w3.org), not just to me.
- Our comments are numbered in square brackets [nn].


We look forward to further discussion with you.

[this mail is copied to the DOM WG to tell them what we are
telling you about UTF-16 and endianness, which they should
adopt for the
Document Object Model (DOM) Level 3 Load and Save Specification]

[8] Section 3, 'encoding': This should say that for UTF-16,
   endianness implementation-dependent (or implementation-defined)

Regards,    Martin.

Agreed.

Dear XML Query WG and XSL WG,

Below please find the I18N WGs comments on your last call document
"XSLT 2.0 and XQuery 1.0 Serialization"
(http://www.w3.org/TR/2003/WD-xslt-xquery-serialization-20031112/).

Please note the following:
- Please address all replies to there comments to the I18N IG mailing
   list (w3c-i18n-ig@w3.org), not just to me.
- Our comments are numbered in square brackets [nn].


We look forward to further discussion with you.

[this mail is copied to the DOM WG to tell them what we are
telling you about UTF-16 and endianness, which they should
adopt for the
Document Object Model (DOM) Level 3 Load and Save Specification]

[9] Section 3, 'encoding': "If this parameter is not specified, and
   the output method does not specify any additional requirements,
   the encoding used is implementation defined."
   This should be more specific. In the absence of an 'encoding'
   parameter, information e.g. given to an implementation via an
   option, and specific information for a particular 'host language'
   (e.g. other than XQuery or XSLT), there should be a default of
   UTF-8.

Regards,    Martin.

Off-hand, I don't see any objection to this except that it might give
some vendors a backwards compatibility problem.

Dear XML Query WG and XSL WG,

Below please find the I18N WGs comments on your last call document
"XSLT 2.0 and XQuery 1.0 Serialization"
(http://www.w3.org/TR/2003/WD-xslt-xquery-serialization-20031112/).

Please note the following:
- Please address all replies to there comments to the I18N IG mailing
   list (w3c-i18n-ig@w3.org), not just to me.
- Our comments are numbered in square brackets [nn].


We look forward to further discussion with you.

[this mail is copied to the DOM WG to tell them what we are
telling you about UTF-16 and endianness, which they should
adopt for the
Document Object Model (DOM) Level 3 Load and Save Specification]

[12] [Should be "10". HZ]
   Section 3, 'escape-uri-attributes' (and other places in this spec):
   RFC 2396, section 2.4.1, only specifies how to escape a string of
   bytes in an URI, and cannot directly be applied to a string of
   (Unicode) characters. In accordance with the IRI draft and many
   other W3C specifications, this must be specified to use UTF-8
   first and then use RFC 2396, section 2.4.1 (%-escaping).

Regards,    Martin.

Agreed.

Dear XML Query WG and XSL WG,

Below please find the I18N WGs comments on your last call document
"XSLT 2.0 and XQuery 1.0 Serialization"
(http://www.w3.org/TR/2003/WD-xslt-xquery-serialization-20031112/).

Please note the following:
- Please address all replies to there comments to the I18N IG mailing
   list (w3c-i18n-ig@w3.org), not just to me.
- Our comments are numbered in square brackets [nn].


We look forward to further discussion with you.

[this mail is copied to the DOM WG to tell them what we are
telling you about UTF-16 and endianness, which they should
adopt for the
Document Object Model (DOM) Level 3 Load and Save Specification]

[11] Section 3, 'include-content-type': Why is this parameter needed?
   It seems that it may be better to always include a <meta> element.
   Please remove the parameter or tell us when/why it's necessary to
   not have a <meta> element

Regards,    Martin.

This parameter has been requested by users a number of times, but the
situations that justify it are difficult to describe concisely. The
simplest case is where the user wants to output the meta element "by
hand", to give greater control. The other cases I've seen are where the
encoding isn't known until after subsequent stages in the processing
pipeline.

Dear XML Query WG and XSL WG,

Below please find the I18N WGs comments on your last call document
"XSLT 2.0 and XQuery 1.0 Serialization"
(http://www.w3.org/TR/2003/WD-xslt-xquery-serialization-20031112/).

Please note the following:
- Please address all replies to there comments to the I18N IG mailing
   list (w3c-i18n-ig@w3.org), not just to me.
- Our comments are numbered in square brackets [nn].


We look forward to further discussion with you.

[this mail is copied to the DOM WG to tell them what we are
telling you about UTF-16 and endianness, which they should
adopt for the
Document Object Model (DOM) Level 3 Load and Save Specification]

[12] The description of 'media-type' is confusing. Does it change
   something in the output, or only in the way the output is labelled?
   Does it affect the <meta>, if output? Can it affect other things,
   e.g. a Content-Type header in HTTP? This should be clarified.

Regards,    Martin.

You're not the only one who's confused. It's often used by
transformation servlets to set the HTTP headers, but as far as the
serializer itself is concerned, it's documentary.

Dear XML Query WG and XSL WG,

Below please find the I18N WGs comments on your last call document
"XSLT 2.0 and XQuery 1.0 Serialization"
(http://www.w3.org/TR/2003/WD-xslt-xquery-serialization-20031112/).

Please note the following:
- Please address all replies to there comments to the I18N IG mailing
   list (w3c-i18n-ig@w3.org), not just to me.
- Our comments are numbered in square brackets [nn].


We look forward to further discussion with you.

[this mail is copied to the DOM WG to tell them what we are
telling you about UTF-16 and endianness, which they should
adopt for the
Document Object Model (DOM) Level 3 Load and Save Specification]

[13] Section 3, 'normalize-unicode': Using Normalization Form C is
   the right thing, but XML 1.1, in accordance with the Character
   Model, defines some additional start conditions in some cases.
   How are these guaranteed (e.g. by adding an initial space if
   necessary)? If there is no such guarantee, there should at least
   be a warning, but a guarantee is highly preferable.

Regards,    Martin.

Martin,

    In [1], you submitted the following comment on the Serialization last 
call draft.

Martin Duerst wrote on 2004-02-15 12:37:30 PM:
> [13] Section 3, 'normalize-unicode': Using Normalization Form C is
>    the right thing, but XML 1.1, in accordance with the Character
>    Model, defines some additional start conditions in some cases.
>    How are these guaranteed (e.g. by adding an initial space if
>    necessary)? If there is no such guarantee, there should at least
>    be a warning, but a guarantee is highly preferable.

     Our thanks to you and the I18N WG for submitting this comment.
 
     The XSL and XQuery Working Groups discussed the comment and related 
comments, and decided to make the following changes to the 
normalize-unicode parameter:

1. Rename the parameter to "normalization-form".

2. The possible values of the parameter will be "NFC", "NFD", "NFKC", 
"NFKD", "fully-normalized", "none" or an implementation-defined 
normalization form.  The default value is "none".  We will also add a note 
advising of the interoperability problems that can arise by using anything 
other than NFC.

3. All of "NFC", "NFD", "NFKC", "NFKD", "fully-normalized", "none" and any 
implementation-defined value are permitted for the xml, xhtml and text 
output methods.  The values "NFC", "fully-normalized" and "none" must be 
supported by an implementation for these output methods.

4. The normalization-form parameter is permitted to have the values "NFC", 
"NFD", "NFKC", "NFKD", "none" or an implementation-defined value if the 
output method is "html".  The values "NFC" and "none" must be supported 
for the html output method.  The value "fully-normalized" is not permitted 
if the output method is "html".

5. In the case of "fully-normalized", the normalization is the same as for 
NFC, but the processor must signal a serialization error if any of the 
"relevant constructs" of the result would begin with a combining 
character.

     We believe that item 5 on this list addresses the particular concern 
raised in the comment, that guarantees should be provided that the start 
conditions of the Character Model are not violated.

     May I ask you to confirm that this is an acceptable response to the 
I18N WG's comment?

Thanks,

Henry
[1] 
http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0362.html
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

Dear XML Query WG and XSL WG,

Below please find the I18N WGs comments on your last call document
"XSLT 2.0 and XQuery 1.0 Serialization"
(http://www.w3.org/TR/2003/WD-xslt-xquery-serialization-20031112/).

Please note the following:
- Please address all replies to there comments to the I18N IG mailing
   list (w3c-i18n-ig@w3.org), not just to me.
- Our comments are numbered in square brackets [nn].


We look forward to further discussion with you.

[this mail is copied to the DOM WG to tell them what we are
telling you about UTF-16 and endianness, which they should
adopt for the
Document Object Model (DOM) Level 3 Load and Save Specification]

[14] Section 3, four phases of serialization: Character expansion
   comes before Encoding, but encoding depends on character
   expansion (using numeric character references for characters
   that don't exist in a certain encoding). This has to be
   sorted out very carefully and explained in detail, ideally
   with examples. There's also an interaction between mapping and
   normalization.  If there's a mapping combining grave->̀,
   normalization must be aware that ̀ is not an ASCII string!

Regards,    Martin.

You are probably right that we need to analyze and explain the
interactions between the different options better than we do at the
moment.

Dear XML Query WG and XSL WG,

Below please find the I18N WGs comments on your last call document
"XSLT 2.0 and XQuery 1.0 Serialization"
(http://www.w3.org/TR/2003/WD-xslt-xquery-serialization-20031112/).

Please note the following:
- Please address all replies to there comments to the I18N IG mailing
   list (w3c-i18n-ig@w3.org), not just to me.
- Our comments are numbered in square brackets [nn].


We look forward to further discussion with you.

[this mail is copied to the DOM WG to tell them what we are
telling you about UTF-16 and endianness, which they should
adopt for the
Document Object Model (DOM) Level 3 Load and Save Specification]

[15] Section 4, "To anticipate the proposed changes to end-of-line
   handling in XML 1.1, implementations may also output the characters
   x85 and x2028 as character references. This will not affect the way
   they are interpreted by an XML 1.0 parser.": XML 1.1 is now a REC,
   so this is no longer anticipated. See
   http://www.w3.org/TR/2004/REC-xml11-20040204/#sec-line-ends

Regards,    Martin.

Yes. Now that XML+NS 1.1 is at Rec status, I think the WGs need to take
a fresh top-level look at our policy towards them; serialization is just
one aspect of this.

Hello,

     In [1], Martin Duerst submitted the following comment on the Last 
Call Working Draft of XSLT 2.0 and XQuery 1.0 Serialization:

> [15] Section 4, "To anticipate the proposed changes to end-of-line
>    handling in XML 1.1, implementations may also output the characters
>    x85 and x2028 as character references. This will not affect the way
>    they are interpreted by an XML 1.0 parser.": XML 1.1 is now a REC,
>    so this is no longer anticipated. See
>    http://www.w3.org/TR/2004/REC-xml11-20040204/#sec-line-ends

     Thanks to Martin and the working group for this comment.

     The XSL and XML Query Working Groups discussed the comment, and 
agreed that the Serialization specification should be amended so that it 
no longer refers to XML 1.1 as if it were not yet a recommendation. 
Furthermore, the working groups decided that the handling of x85 and x2028 
should be such that they can be successfully processed by either an XML 
1.0 or an XML 1.1 processor without being normalized to a line-feed 
character, even if the value of the version parameter is 1.0.  Following 
are the changes required to implement that change:

Replace the paragraph after the bulleted list in Section 4 with the 
following:

<<
A consequence of this rule is that certain whitespace characters must be
output as character references, to ensure that they survive the round
trip through serialization and parsing. Specifically, CR, NEL and LINE
SEPARATOR characters in text nodes must be output respectively as &#xD;,
&#x85;, and &#x2028;, or their equivalents; while CR, NL, TAB, NEL and
LINE SEPARATOR characters in attribute nodes must be output respectively
as &#xD;, &#xA;, &#x9;, &#x85;, and &#x2028;, or their equivalents
>>

And replace the note following the bulleted list with the following note:

<<
Note:  XML 1.0 did not permit processors to normalize NEL or LINE
SEPARATOR characters to a LINE FEED character.  However, if a document
entity that specifies version 1.1 invokes an external general parsed
entity with no TextDecl or a TextDecl that specifies a version of 1.0,
the external parsed entity is processed according to the rules of XML
1.1.  For this reason, NEL and LINE SEPARATOR characters in text and
attribute nodes must always be escaped using character references or
CDATA sections, regardless of the value of the version parameter.
>>

     May I ask the working group to confirm that this response is 
acceptable to it?

Thanks,

Henry [On behalf of the XSL and XML Query Working Groups]
[1] 
http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0362.html
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

Dear XML Query WG and XSL WG,

Below please find the I18N WGs comments on your last call document
"XSLT 2.0 and XQuery 1.0 Serialization"
(http://www.w3.org/TR/2003/WD-xslt-xquery-serialization-20031112/).

Please note the following:
- Please address all replies to there comments to the I18N IG mailing
   list (w3c-i18n-ig@w3.org), not just to me.
- Our comments are numbered in square brackets [nn].


We look forward to further discussion with you.

[this mail is copied to the DOM WG to tell them what we are
telling you about UTF-16 and endianness, which they should
adopt for the
Document Object Model (DOM) Level 3 Load and Save Specification]

[16] Section 4.2 (XML output method, encoding): "If no encoding parameter
   is specified, then the processor must use either UTF-8 or UTF-16.":
   It may be desirable to further narrow this to UTF-8 for higher
   predictability. On the other hand, this should not say
   "If no encoding parameter is specified", but "If no encoding
   is specified (either with an encoding parameter or externally)"
   to allow e.g. specification of encoding with an option.

Regards,    Martin.

On the first point: yes, perhaps.

On the second, the serializer is driven by a set of parameters. I think
that by the time the serializer is invoked, the parameter values have
been fully computed, regardless where they came from, so the
serialization spec does not need to discuss different ways of supplying
the parameters.

Michael Kay a écrit :
> On the second, the serializer is driven by a set of parameters. I think
> that by the time the serializer is invoked, the parameter values have
> been fully computed, regardless where they came from, so the
> serialization spec does not need to discuss different ways of supplying
> the parameters.

If the parameters are the only way to influence serialization behaviour, 
then this should be clarified.  Section 3 now starts "There are a number 
of parameters that influence...", which doesn't seem to claim to 
exhaustiveness.

Dear XML Query WG and XSL WG,

Below please find the I18N WGs comments on your last call document
"XSLT 2.0 and XQuery 1.0 Serialization"
(http://www.w3.org/TR/2003/WD-xslt-xquery-serialization-20031112/).

Please note the following:
- Please address all replies to there comments to the I18N IG mailing
   list (w3c-i18n-ig@w3.org), not just to me.
- Our comments are numbered in square brackets [nn].


We look forward to further discussion with you.

[this mail is copied to the DOM WG to tell them what we are
telling you about UTF-16 and endianness, which they should
adopt for the
Document Object Model (DOM) Level 3 Load and Save Specification]

[17] Section 4.2 (XML output method, encoding): "When outputting a newline
   character in the data model, the implementation is free to represent
   it using any character sequence that will be normalized to a newline
   character by an XML parser,...": This should probably says that
   for interoperability, it is better to avoid x85 and x2028.

Regards,    Martin.

I don't see a specific need to say that: if you're generating XML 1.0
then you need to avoid these characters and if you're generating XML 1.1
then you don't. This seems to be covered by the statement as written.

Hello,

     In [1], Martin Duerst submitted the following comment on the Last 
Call Working Draft of XSLT 2.0 and XQuery 1.0 Serialization on behalf of 
the I18N Working Group.

> [17] Section 4.2 (XML output method, encoding): "When outputting a 
newline
>    character in the data model, the implementation is free to represent
>    it using any character sequence that will be normalized to a newline
>    character by an XML parser,...": This should probably says that
>    for interoperability, it is better to avoid x85 and x2028.

     In [2], Michael Kay responded:

> I don't see a specific need to say that: if you're generating XML 1.0
> then you need to avoid these characters and if you're generating XML 1.1
> then you don't. This seems to be covered by the statement as written.

     Thanks to Martin and the I18N Working Group for this comment.

     The XSL and XQuery Working Groups discussed the comment, and agreed 
with Michael Kay that the statement regarding the representation of 
newline characters in the serialized document was correct as written, and 
that no change is required.

     May I ask the I18N Working Group to confirm that this response is 
acceptable?

Thanks,

Henry [On behalf of the XSL and XQuery Working Groups.]
[1] 
http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0362.html
[2] 
http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0401.html
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

Hello Henry,

Sorry for the delay in replying to your mails.

The I18N WG (Core TF) has looked at your response,
and we are glad to tell you that it is acceptable for us.

Regards,    Martin.

At 10:59 04/04/13 -0400, Henry Zongaro wrote:

>Hello,
>
>      In [1], Martin Duerst submitted the following comment on the Last
>Call Working Draft of XSLT 2.0 and XQuery 1.0 Serialization on behalf of
>the I18N Working Group.
>
> > [17] Section 4.2 (XML output method, encoding): "When outputting a
>newline
> >    character in the data model, the implementation is free to represent
> >    it using any character sequence that will be normalized to a newline
> >    character by an XML parser,...": This should probably says that
> >    for interoperability, it is better to avoid x85 and x2028.
>
>      In [2], Michael Kay responded:
>
> > I don't see a specific need to say that: if you're generating XML 1.0
> > then you need to avoid these characters and if you're generating XML 1.1
> > then you don't. This seems to be covered by the statement as written.
>
>      Thanks to Martin and the I18N Working Group for this comment.
>
>      The XSL and XQuery Working Groups discussed the comment, and agreed
>with Michael Kay that the statement regarding the representation of
>newline characters in the serialized document was correct as written, and
>that no change is required.
>
>      May I ask the I18N Working Group to confirm that this response is
>acceptable?
>
>Thanks,
>
>Henry [On behalf of the XSL and XQuery Working Groups.]
>[1]
>http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0362.html
>[2]
>http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0401.html
>------------------------------------------------------------------
>Henry Zongaro      Xalan development
>IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
>mailto:zongaro@ca.ibm.com

Dear XML Query WG and XSL WG,

Below please find the I18N WGs comments on your last call document
"XSLT 2.0 and XQuery 1.0 Serialization"
(http://www.w3.org/TR/2003/WD-xslt-xquery-serialization-20031112/).

Please note the following:
- Please address all replies to there comments to the I18N IG mailing
   list (w3c-i18n-ig@w3.org), not just to me.
- Our comments are numbered in square brackets [nn].


We look forward to further discussion with you.

[this mail is copied to the DOM WG to tell them what we are
telling you about UTF-16 and endianness, which they should
adopt for the
Document Object Model (DOM) Level 3 Load and Save Specification]

[18] Section 4.5 (XML output method, omit-xml-declaration): "The
   omit-xml-declaration parameter must be ignored if the standalone
   parameter is present, or if the encoding parameter specifies a
   value other than UTF-8 or UTF-16.": This disallows producing
   XML other than UTF-8 or UTF-16 without an xml declaration even
   though this is legal e.g. if served over HTTP with a corresponding
   charset parameter. We are not sure this is intended, and we
   are not sure this is a good thing. On the other hand,
   omit-xml-declaration must also be ignored if version is not 1.0.

Regards,    Martin.

This rule overriding omit-xml-declaration has proved controversial with
some users, usually because they want to output fragments of XML that
they can concatenate into a single file. We should review it. On the
other hand, users do complain if the serializer produces output that an
XML parser then rejects.

Hello,

     In [1], Martin Duerst submitted the following comment on the Last 
Call Working Draft of XSLT 2.0 and XQuery 1.0 Serialization on behalf of 
the I18N Working Group.

> [18] Section 4.5 (XML output method, omit-xml-declaration): "The
>    omit-xml-declaration parameter must be ignored if the standalone
>    parameter is present, or if the encoding parameter specifies a
>    value other than UTF-8 or UTF-16.": This disallows producing
>    XML other than UTF-8 or UTF-16 without an xml declaration even
>    though this is legal e.g. if served over HTTP with a corresponding
>    charset parameter. We are not sure this is intended, and we
>    are not sure this is a good thing. On the other hand,
>    omit-xml-declaration must also be ignored if version is not 1.0.

     Thanks to Martin and the I18N Working Group for this comment.

     The XSL and XQuery Working groups discussed this comment.

     Regarding the second point, although XML 1.1 requires a document 
entity to have an XML declaration, it does not require an external general 
parsed entity to have a text declaration.  The setting of the 
omit-xml-declaration parameter could still be meaningful, even if the 
version parameter has a value other than 1.0.

     Regarding the first point, as originally written, XML 1.0 required an 
XML declaration or a text declaration if the encoding of the document or 
external general parsed entity was anything other than UTF-8 or UTF-16. 
XSLT 1.0 enforced that requirement in its serialization mechanism.  The 
draft of Serialization inherited that behaviour from XSLT 1.0.  However, 
an erratum to XML 1.0 removed that requirement.

     In response to both points, the working groups decided that the 
Serialization specification should permit an XML declaration or text 
declaration to be omitted in precisely those circumstances in which it can 
be omitted according to XML 1.0 and XML 1.1.

     In particular, the working groups decided that if the serialized 
result could be considered to be the text declaration of an external 
general parsed entity, the omit-xml-declaration parameter could have the 
value yes or the value no, and the parameter's setting would take effect. 
They further decided that if the serialized result could only be 
considered to be a document entity because

  o the standalone parameter had the value yes or no; or
  o the version parameter had a value other than 1.0 and the
    doctype-system parameter was supplied

the omit-xml-declaration parameter must have the value no.  Otherwise, a 
serialization error results.  A host language would, of course, have the 
option of ensuring such conflicts never arise through whatever 
language-specific mechanism it uses to specify serialization parameters.

     May I ask the working group to confirm that that response is 
acceptable?

Thanks,

Henry [On behalf of the XSL and XQuery Working Groups.]
[1] 
http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0362.html
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

Hello Henry,

The I18N WG (Core TF) has looked at your response.
We can confirm that we are okay with your solution under the
assumption that the default is still the same (i.e.
omit-xml-declaration='no', i.e. it is the default to omit an
XML declaration).

Regards,    Martin.

At 11:17 04/04/13 -0400, Henry Zongaro wrote:

>Hello,
>
>      In [1], Martin Duerst submitted the following comment on the Last
>Call Working Draft of XSLT 2.0 and XQuery 1.0 Serialization on behalf of
>the I18N Working Group.
>
> > [18] Section 4.5 (XML output method, omit-xml-declaration): "The
> >    omit-xml-declaration parameter must be ignored if the standalone
> >    parameter is present, or if the encoding parameter specifies a
> >    value other than UTF-8 or UTF-16.": This disallows producing
> >    XML other than UTF-8 or UTF-16 without an xml declaration even
> >    though this is legal e.g. if served over HTTP with a corresponding
> >    charset parameter. We are not sure this is intended, and we
> >    are not sure this is a good thing. On the other hand,
> >    omit-xml-declaration must also be ignored if version is not 1.0.
>
>      Thanks to Martin and the I18N Working Group for this comment.
>
>      The XSL and XQuery Working groups discussed this comment.
>
>      Regarding the second point, although XML 1.1 requires a document
>entity to have an XML declaration, it does not require an external general
>parsed entity to have a text declaration.  The setting of the
>omit-xml-declaration parameter could still be meaningful, even if the
>version parameter has a value other than 1.0.
>
>      Regarding the first point, as originally written, XML 1.0 required an
>XML declaration or a text declaration if the encoding of the document or
>external general parsed entity was anything other than UTF-8 or UTF-16.
>XSLT 1.0 enforced that requirement in its serialization mechanism.  The
>draft of Serialization inherited that behaviour from XSLT 1.0.  However,
>an erratum to XML 1.0 removed that requirement.
>
>      In response to both points, the working groups decided that the
>Serialization specification should permit an XML declaration or text
>declaration to be omitted in precisely those circumstances in which it can
>be omitted according to XML 1.0 and XML 1.1.
>
>      In particular, the working groups decided that if the serialized
>result could be considered to be the text declaration of an external
>general parsed entity, the omit-xml-declaration parameter could have the
>value yes or the value no, and the parameter's setting would take effect.
>They further decided that if the serialized result could only be
>considered to be a document entity because
>
>   o the standalone parameter had the value yes or no; or
>   o the version parameter had a value other than 1.0 and the
>     doctype-system parameter was supplied
>
>the omit-xml-declaration parameter must have the value no.  Otherwise, a
>serialization error results.  A host language would, of course, have the
>option of ensuring such conflicts never arise through whatever
>language-specific mechanism it uses to specify serialization parameters.
>
>      May I ask the working group to confirm that that response is
>acceptable?
>
>Thanks,
>
>Henry [On behalf of the XSL and XQuery Working Groups.]
>[1]
>http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0362.html
>------------------------------------------------------------------
>Henry Zongaro      Xalan development
>IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
>mailto:zongaro@ca.ibm.com

Hello, Martin,

     Regarding the response to the I18N WG's comment number [18], you 
wrote:

Martin Duerst <duerst@w3.org> wrote on 2004-05-05 04:12:39 AM:
> The I18N WG (Core TF) has looked at your response.
> We can confirm that we are okay with your solution under the
> assumption that the default is still the same (i.e.
> omit-xml-declaration='no', i.e. it is the default to omit an
> XML declaration).

     In response to another last call comment, default settings for 
parameters to serialization will be determined by the process that sets 
those parameters.  The particular default settings specified by XSLT 2.0 
and XQuery 1.0 have not changed, however.  In particular, the XSLT 2.0 
specifies a default value of no for the value of the omit-xml-declaration 
parameter, while XQuery 1.0 specifies a default value of yes.

Thanks,

Henry
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

Hello Henry,

We have looked at the response below, and are fine with it,
i.e. we think that it satisfactorily addresses our original comment.

Regards,    Martin.

At 08:50 04/05/05 -0400, Henry Zongaro wrote:

>Hello, Martin,
>
>      Regarding the response to the I18N WG's comment number [18], you
>wrote:
>
>Martin Duerst <duerst@w3.org> wrote on 2004-05-05 04:12:39 AM:
> > The I18N WG (Core TF) has looked at your response.
> > We can confirm that we are okay with your solution under the
> > assumption that the default is still the same (i.e.
> > omit-xml-declaration='no', i.e. it is the default to omit an
> > XML declaration).
>
>      In response to another last call comment, default settings for
>parameters to serialization will be determined by the process that sets
>those parameters.  The particular default settings specified by XSLT 2.0
>and XQuery 1.0 have not changed, however.  In particular, the XSLT 2.0
>specifies a default value of no for the value of the omit-xml-declaration
>parameter, while XQuery 1.0 specifies a default value of yes.
>
>Thanks,
>
>Henry
>------------------------------------------------------------------
>Henry Zongaro      Xalan development
>IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
>mailto:zongaro@ca.ibm.com

Dear XML Query WG and XSL WG,

Below please find the I18N WGs comments on your last call document
"XSLT 2.0 and XQuery 1.0 Serialization"
(http://www.w3.org/TR/2003/WD-xslt-xquery-serialization-20031112/).

Please note the following:
- Please address all replies to there comments to the I18N IG mailing
   list (w3c-i18n-ig@w3.org), not just to me.
- Our comments are numbered in square brackets [nn].


We look forward to further discussion with you.

[this mail is copied to the DOM WG to tell them what we are
telling you about UTF-16 and endianness, which they should
adopt for the
Document Object Model (DOM) Level 3 Load and Save Specification]

[19] 6.4 HTML Output Method: Writing Character Data: "When outputting
   a sequence of whitespace characters in the data model, within an
   element where whitespace is treated normally, (but not in elements
   such as pre and textarea) the html output method may represent it
   using any character sequence that will be treated as whitespace
   by an HTML user agent.": @@@ We need to check whether this (which
   allows replacement of whitespace including linebreaks by whitespace
   not including linebreaks and vice-versa) is okay for Chinese,
   Japanese, Thai,... (languages without spaces between words).
   This has to be checked extremely carefully.

Regards,    Martin.

I think it's better if we don't try to define the detailed rules here,
but just state the constraint: you can replace one whitespace sequence
by another if user agents treat them as equivalent. If we try to be more
precise than this, we will get it wrong.

The current text does not say that, it says that one sequence of white 
can be replaced by another if HTML user agents consider the latter as 
whitespace (presumably in the XML sense).  But HTML user agents need to 
distinguish line breaks from other whitespace, for the reasons hinted to 
by Martin. See list item 9 in 
http://www.w3.org/TR/2001/REC-xhtml-modularization-20010410/conformance.html#s_conform_user_agent 
for the gory details.

Thanks, distinction noted.

Hi, Martin.

     In [1], you submitted the following comment on the Last Call Working 
Draft of XSLT 2.0 and XQuery 1.0 Serialization on behalf of the I18N 
working group:

Martin Duerst wrote on 2004-02-15 12:37:30 PM:
> [19] 6.4 HTML Output Method: Writing Character Data: "When outputting
>    a sequence of whitespace characters in the data model, within an
>    element where whitespace is treated normally, (but not in elements
>    such as pre and textarea) the html output method may represent it
>    using any character sequence that will be treated as whitespace
>    by an HTML user agent.": @@@ We need to check whether this (which
>    allows replacement of whitespace including linebreaks by whitespace
>    not including linebreaks and vice-versa) is okay for Chinese,
>    Japanese, Thai,... (languages without spaces between words).
>    This has to be checked extremely carefully.

In [2], François Yergeau added the following information, in response to a 
note from Michael Kay on the topic:

> > I think it's better if we don't try to define the detailed rules here,
> > but just state the constraint: you can replace one whitespace sequence
> > by another if user agents treat them as equivalent.
> 
> The current text does not say that, it says that one sequence of white 
> can be replaced by another if HTML user agents consider the latter as 
> whitespace (presumably in the XML sense).  But HTML user agents need to 
> distinguish line breaks from other whitespace, for the reasons hinted to 

> by Martin. See list item 9 in 
> 
http://www.w3.org/TR/2001/REC-xhtml-modularization-20010410/conformance.html#s_conform_user_agent 

> for the gory details.

     Thanks to you and the I18N working group for this comment.

     The XSL and XML Query Working Groups discussed the comment.  The 
working groups were unable to find any statement in HTML 4.01 that 
different whitespace characters can be treated differently, ignoring such 
elements as pre and textarea.  The reference that François provided was 
from the XHTML Modularization Recommendation, although the original 
comment was on the html output method.

     In discussing the comment, some members of the WGs thought that XHTML 
Modularization probably better reflected the requirements placed on HTML 
user agents in order to support languages such as those you mentioned. The 
WGs decided to add a normative requirement in the description of the html 
output method stating that whitespace characters can be replaced only with 
any other sequence of whitespace characters that has the same effect in a 
user agent.  The WGs also decided to add a non-normative reference 
pointing to bullet 9 of section 3.5 of XHTML Modularization, to provide 
further information on the issues involved.

     May I ask you to confirm that this response is acceptable to the I18N 
Working Group?

Thanks,

Henry [On behalf of the XSL and XML Query Working Groups]
[1] 
http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0362.html
[2] 
http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/1025.html
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

Dear XML Query WG and XSL WG,

Below please find the I18N WGs comments on your last call document
"XSLT 2.0 and XQuery 1.0 Serialization"
(http://www.w3.org/TR/2003/WD-xslt-xquery-serialization-20031112/).

Please note the following:
- Please address all replies to there comments to the I18N IG mailing
   list (w3c-i18n-ig@w3.org), not just to me.
- Our comments are numbered in square brackets [nn].


We look forward to further discussion with you.

[this mail is copied to the DOM WG to tell them what we are
telling you about UTF-16 and endianness, which they should
adopt for the
Document Object Model (DOM) Level 3 Load and Save Specification]

[20] 6.4 HTML Output Method: Writing Character Data: "Certain characters,
   specifically the control characters #x7F-#x9F, are legal in XML but
   not in HTML. ... The processor may signal the error, but is not
   required to do so.": Please change this to require the processor
   to produce an error.

Regards,    Martin.

I worry that we will get many complaints from users who are misusing
these codepoints if we do this. Their code will stop working, and it may
be quite difficult for them to fix it. (Though it's a good use case for
character maps...)

Hello,

     In [1], Martin Duerst submitted the following comment on the Last 
Call Working Draft of XSLT 2.0 and XQuery 1.0 Serialization on behalf of 
the I18N Working Group.

> [20] 6.4 HTML Output Method: Writing Character Data: "Certain 
characters,
>    specifically the control characters #x7F-#x9F, are legal in XML but
>    not in HTML. ... The processor may signal the error, but is not
>    required to do so.": Please change this to require the processor
>    to produce an error.

     In [2], Michael Kay responded:

> I worry that we will get many complaints from users who are misusing
> these codepoints if we do this. Their code will stop working, and it may
> be quite difficult for them to fix it. (Though it's a good use case for
> character maps...)

     Thanks to Martin and the I18N Working Group for this comment.

     The XSL and XQuery Working Groups discussed the comment, and decided 
to endorse Michael Kay's response without any change to the Serialization 
specification.

     May I ask the I18N Working Group to confirm that this response is 
acceptable?

Thanks,

Henry [On behalf of the XSL and XQuery Working Groups.]
[1] 
http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0362.html
[2] 
http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0401.html
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

Hello Henry,

Many thanks for your replies to our comments.
The I18N WG (Core TF) has looked at your reply below.

We are sorry, but we have to clearly disagree.
We think that producing junk is never a good idea.
See below for further discussion.


At 11:17 04/04/13 -0400, Henry Zongaro wrote:

>Hello,
>
>      In [1], Martin Duerst submitted the following comment on the Last
>Call Working Draft of XSLT 2.0 and XQuery 1.0 Serialization on behalf of
>the I18N Working Group.
>
> > [20] 6.4 HTML Output Method: Writing Character Data: "Certain
>characters,
> >    specifically the control characters #x7F-#x9F, are legal in XML but
> >    not in HTML. ... The processor may signal the error, but is not
> >    required to do so.": Please change this to require the processor
> >    to produce an error.
>
>      In [2], Michael Kay responded:
>
> > I worry that we will get many complaints from users who are misusing
> > these codepoints if we do this.

How are they misusing these code points? The case we know is that
bytes in the rage 0x80-0x9F are used e.g. in iso-8859-1 but with
the intent of giving them the windows-1252 semantics. If somebody
is reading in windows-1252 documents, then it's simple to just
declare them that way. Also, if somebody wants windows-1252 as
output, they can just say so using XSLT. Neither reading windows-1252
nor writing out windows-1252 is in any way a misuse of XML, HTML,
or XSLT. HTML allows using the *bytes* 0x80-0x9F if in the encoding
used, they are encoding *characters* that are allowed by HTML.

If it is some other misuse that you are speaking about, please
inform us about the details.


> > Their code will stop working,

In some way just a detail, but: There is currently no XSLT 2.0
code that will stop working. XSTL 1.0 doesn't have the XHTML
output method.

With kind regards,    Martin.


> > and it may
> > be quite difficult for them to fix it. (Though it's a good use case for
> > character maps...)
>
>      Thanks to Martin and the I18N Working Group for this comment.
>
>      The XSL and XQuery Working Groups discussed the comment, and decided
>to endorse Michael Kay's response without any change to the Serialization
>specification.
>
>      May I ask the I18N Working Group to confirm that this response is
>acceptable?
>
>Thanks,
>
>Henry [On behalf of the XSL and XQuery Working Groups.]
>[1]
>http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0362.html
>[2]
>http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0401.html
>------------------------------------------------------------------
>Henry Zongaro      Xalan development
>IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
>mailto:zongaro@ca.ibm.com

Dear XML Query WG and XSL WG,

Below please find the I18N WGs comments on your last call document
"XSLT 2.0 and XQuery 1.0 Serialization"
(http://www.w3.org/TR/2003/WD-xslt-xquery-serialization-20031112/).

Please note the following:
- Please address all replies to there comments to the I18N IG mailing
   list (w3c-i18n-ig@w3.org), not just to me.
- Our comments are numbered in square brackets [nn].


We look forward to further discussion with you.

[this mail is copied to the DOM WG to tell them what we are
telling you about UTF-16 and endianness, which they should
adopt for the
Document Object Model (DOM) Level 3 Load and Save Specification]

[21] Section 8: There should be a reference to XSLT to show examples
   of use of character maps.

Regards,    Martin.

Dear XML Query WG and XSL WG,

Below please find the I18N WGs comments on your last call document
"XSLT 2.0 and XQuery 1.0 Serialization"
(http://www.w3.org/TR/2003/WD-xslt-xquery-serialization-20031112/).

Please note the following:
- Please address all replies to there comments to the I18N IG mailing
   list (w3c-i18n-ig@w3.org), not just to me.
- Our comments are numbered in square brackets [nn].


We look forward to further discussion with you.

[this mail is copied to the DOM WG to tell them what we are
telling you about UTF-16 and endianness, which they should
adopt for the
Document Object Model (DOM) Level 3 Load and Save Specification]

General last call comments, not i18n-related:

[22] There shouldbe some warning about denormalization when using
   charmaps

Regards,    Martin.

I agree.

Martin,

     In [1], you submitted the following comment on the Last Call Working 
Draft of XSLT 2.0 and XQuery 1.0 Serialization on behalf of the I18N 
working group:

<<
[22] There should be some warning about denormalization when using
   charmaps
>>

     Thanks to you and the I18N working group for this comment.

     The XSL and XML Query Working Groups discussed the working group's 
comment, and decided to add a note indicating that the use of character 
maps may result in a serialized document that is not normalized.

     May I ask you to confirm that this response is acceptable to the 
working group?

Thanks,

Henry [On behalf of the XSL and XML Query Working Groups]
[1] 
http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0362.html
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

Hello Henry,

We just decided at the I18N WG Core TF teleconf that we are happy
with this resolution.

Regards,    Martin.

At 13:09 04/07/13 -0400, Henry Zongaro wrote:

>Martin,
>
>      In [1], you submitted the following comment on the Last Call Working
>Draft of XSLT 2.0 and XQuery 1.0 Serialization on behalf of the I18N
>working group:
>
><<
>[22] There should be some warning about denormalization when using
>    charmaps
> >>
>
>      Thanks to you and the I18N working group for this comment.
>
>      The XSL and XML Query Working Groups discussed the working group's
>comment, and decided to add a note indicating that the use of character
>maps may result in a serialized document that is not normalized.
>
>      May I ask you to confirm that this response is acceptable to the
>working group?
>
>Thanks,
>
>Henry [On behalf of the XSL and XML Query Working Groups]
>[1]
>http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0362.html
>------------------------------------------------------------------
>Henry Zongaro      Xalan development
>IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
>mailto:zongaro@ca.ibm.com

Dear XML Query WG and XSL WG,

Below please find the I18N WGs comments on your last call document
"XSLT 2.0 and XQuery 1.0 Serialization"
(http://www.w3.org/TR/2003/WD-xslt-xquery-serialization-20031112/).

Please note the following:
- Please address all replies to there comments to the I18N IG mailing
   list (w3c-i18n-ig@w3.org), not just to me.
- Our comments are numbered in square brackets [nn].


We look forward to further discussion with you.

[this mail is copied to the DOM WG to tell them what we are
telling you about UTF-16 and endianness, which they should
adopt for the
Document Object Model (DOM) Level 3 Load and Save Specification]

General last call comments, not i18n-related:

[23] Section 4: "The base URIs of nodes in the two trees may be different."
   Does this mean that base URIs are not serialized? This should be
   checked or at least explained.

Regards,    Martin.

Yes, the base URI typically is supplied at the time a tree is built by a
parser, it is not normally explicit in the content of the tree.

Hello,

     In [1], Martin Duerst submitted the following comment on the Last 
Call Working Draft of XSLT 2.0 and XQuery 1.0 Serialization on behalf of 
the I18N Working Group.

>[23] Section 4: "The base URIs of nodes in the two trees may be 
different."
>  Does this mean that base URIs are not serialized? This should be
>  checked or at least explained.

     Thanks to Martin and the I18N Working Group for this comment.  In [2] 
Michael Kay responded as follows:

>Yes, the base URI typically is supplied at the time a tree is built by a
>parser, it is not normally explicit in the content of the tree.

     The XSL and XQuery Working Groups discussed this comment, and 
concurred with Michael Kay's response.  The working groups did not feel 
any clarification of the specification was required.

     May I ask the I18N Working Group to confirm that this response is 
acceptable?

Thanks,

Henry
[1] 
http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0362.html
[2] 
http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0401.html
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

Dear XML Query WG and XSL WG,

Below please find the I18N WGs comments on your last call document
"XSLT 2.0 and XQuery 1.0 Serialization"
(http://www.w3.org/TR/2003/WD-xslt-xquery-serialization-20031112/).

Please note the following:
- Please address all replies to there comments to the I18N IG mailing
   list (w3c-i18n-ig@w3.org), not just to me.
- Our comments are numbered in square brackets [nn].


We look forward to further discussion with you.

[this mail is copied to the DOM WG to tell them what we are
telling you about UTF-16 and endianness, which they should
adopt for the
Document Object Model (DOM) Level 3 Load and Save Specification]

General last call comments, not i18n-related:

[24] Cases of creation of non-wellformed XML where the processor is not
   required to signal an error: It would be good to have an option to
   request well-formedness checking even if Character Maps are used.

Regards,    Martin.

Hello,

     In [1], Martin Duerst submitted the following comment on the Last 
Call Working Draft of XSLT 2.0 and XQuery 1.0 Serialization on behalf of 
the I18N Working Group.

> [24] Cases of creation of non-wellformed XML where the processor is not
>    required to signal an error: It would be good to have an option to
>    request well-formedness checking even if Character Maps are used.

     Thanks to Martin and the I18N Working Group for this comment.

     The XSL and XQuery Working Groups discussed the comment, and 
concluded that, although such a mechanism might be useful, an XML parser 
would be capable of performing the same well-formedness checking.  On 
those grounds, the working groups decided it was not necessary to 
duplicate that functionality in Serialization.

     May I ask the working group to confirm that this response is 
acceptable?

Thanks,

Henry [On behalf of the XSL and XQuery Working Groups.]
[1] 
http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0362.html
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

Henry Zongaro a écrit :
>      In [1], Martin Duerst submitted the following comment on the Last 
> Call Working Draft of XSLT 2.0 and XQuery 1.0 Serialization on behalf of 
> the I18N Working Group.
> 
> 
>>[24] Cases of creation of non-wellformed XML where the processor is not
>>   required to signal an error: It would be good to have an option to
>>   request well-formedness checking even if Character Maps are used.
> 
> 
>      Thanks to Martin and the I18N Working Group for this comment.
> 
>      The XSL and XQuery Working Groups discussed the comment, and 
> concluded that, although such a mechanism might be useful, an XML parser 
> would be capable of performing the same well-formedness checking.  On 
> those grounds, the working groups decided it was not necessary to 
> duplicate that functionality in Serialization.

We are not satisfied with this resolution.  We feel that 1) 
well-formedness is very important ; 2) using a parser to check it is 
just a possible implementation strategy and 3) that this strategy may 
not even be available when serializing to other than a local file, e.g. 
to a network socket.

> [1] 
> http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0362.html

Regards,

-- 
François Yergeau

Dear XML Query WG and XSL WG,

Below please find the I18N WGs comments on your last call document
"XSLT 2.0 and XQuery 1.0 Serialization"
(http://www.w3.org/TR/2003/WD-xslt-xquery-serialization-20031112/).

Please note the following:
- Please address all replies to there comments to the I18N IG mailing
   list (w3c-i18n-ig@w3.org), not just to me.
- Our comments are numbered in square brackets [nn].


We look forward to further discussion with you.

[this mail is copied to the DOM WG to tell them what we are
telling you about UTF-16 and endianness, which they should
adopt for the
Document Object Model (DOM) Level 3 Load and Save Specification]

General last call comments, not i18n-related:

[25] 7, Text Output Method: "The media-type parameter is applicable for
   the text output method.": What does that mean? How is it applied?

Regards,    Martin.

It means, go and read the general (method-independent) description of
this parameter (which in this case, is not very enlightening...)

SECTION 2: 

Serialization of the Data Model is important because we want to be
able to share Data Model instances between applications over a
network in a standard way. Today the spec does not support this
(e.g. document boundaries are blurred, scalar values are converted
to text nodes).

We should use XML itself to solve the problem. The idea
is the same as using XML to represent XML schema and using XML to
represent XQuery (XQueryX).

First, we can  define an XML schema that describes the
XQuery data model , then serialize the XQuery data model instance
based on this XML schema.
The key is to define a comprehensive XML schema to describe an
XQuery data model instance.

For example, consider an XQuery data model instance that consists
of 2 items, an xs:integer  of value 1, followed by an xs:string of
value 'abc'. It can be serialized as:

<xqdm:seq xmlns:xqdm="http://www.w3.org/2004/xqdm" >
   <xqdm:item>
        <xqdm:type>xs_integer<xqdm:type>
        <xqdm:value>1<xqdm:value>
   </xqdm:item>
    <xqdm:item>
        <xqdm:type>xs_string<xqdm:type>
        <xqdm:value>abc<xqdm:value>
   </xqdm:item>
</xqdm:seq>

With this kind of serialization, the Data Model can be serialized
in exactly one way.


- Steve B.

    

Steve,

     In [1] you submitted the following comment on the serialization 
draft:

Steve Buxton wrote on 2004-02-17 06:31:41 AM:
> SECTION 2: 
> 
> Serialization of the Data Model is important because we want to be 
> able to share Data Model instances between applications over a 
> network in a standard way. Today the spec does not support this (e.
> g. document boundaries are blurred, scalar values are converted to 
> text nodes).
> 
> We should use XML itself to solve the problem. The idea
> is the same as using XML to represent XML schema and using XML to 
> represent XQuery (XQueryX).
> 
> First, we can  define an XML schema that describes the
> XQuery data model , then serialize the XQuery data model instance
> based on this XML schema.
> The key is to define a comprehensive XML schema to describe an XQuery
> data model instance.
> 
> For example, consider an XQuery data model instance that consists of
> 2 items, an
> xs:integer  of value 1, followed
> by an xs:string of value 'abc'. It can be serialized as:
> 
> <xqdm:seq xmlns:xqdm="http://www.w3.org/2004/xqdm" >
>    <xqdm:item>
>         <xqdm:type>xs_integer<xqdm:type>
>         <xqdm:value>1<xqdm:value>
>    </xqdm:item>
>     <xqdm:item>
>         <xqdm:type>xs_string<xqdm:type>
>         <xqdm:value>abc<xqdm:value>
>    </xqdm:item>
> </xqdm:seq>
> 
> With this kind of serialization, the Data Model can be serialized in
> exactly one way.

     Thank you for submitting this comment.

     The XSL and XQuery working groups considered your comment and related 
comments.  There was general agreement that there is some need for a 
mechanism for serializing arbitrary sequences that preserves most or all 
of the properties of the items in an arbitrary sequence that is being 
serialized.

     However, the working groups decided that precisely defining all of 
the requirements for such a mechanism at this stage would be difficult, 
and would likely lead to a solution that would not satisfy real user 
requirements.  Therefore, the working groups decided to consider such a 
feature for a future revision of the recommendations, and close this 
comment without any changes to the specifications.

     May I ask you to confirm that this resolution is acceptable?

Thanks,

Henry
[1] 
http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0918.html
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

SECTION 3: Serialization parameters

It says "The method identifies the overall method...
If the QName is in a namespace, then it identifies an 
implementation-defined output method; the behavior in this case 
is not specified by this document."  However, you have specified
that normalization (section 2) occurs prior to invoking the 
method.  This implies that the implementation-defined method
has no control over the normalization.  It would be desirable to
reverse this, so that normalization occurs inside the method
rather than prior to the method.  In that case, normalization
would be part of the standard-defined methods but 
implementation-defined methods might have other algorithms
for dealing with values permitted by the data model that do
not correspond to well-formed XML.

To accomplish this, simply make the current section 2 into 
the first phase, prior to "Markup generation".

- Steve B.

    

Steve,

     In [1], you submitted the following comment on the Last Call Working 
Draft of XSLT 2.0 and XQuery 1.0 Serialization:

<<
SECTION 3: Serialization parameters

It says "The method identifies the overall method...
If the QName is in a namespace, then it identifies an 
implementation-defined output method; the behavior in this case 
is not specified by this document."  However, you have specified
that normalization (section 2) occurs prior to invoking the 
method.  This implies that the implementation-defined method
has no control over the normalization.  It would be desirable to
reverse this, so that normalization occurs inside the method
rather than prior to the method.  In that case, normalization
would be part of the standard-defined methods but 
implementation-defined methods might have other algorithms
for dealing with values permitted by the data model that do
not correspond to well-formed XML.

To accomplish this, simply make the current section 2 into 
the first phase, prior to "Markup generation".
>>

     Thank you for this comment.

     The XSL and XML Query Working Groups discussed your comment, and 
agreed that implementation-defined output methods should be granted 
control of whether the normalization of arbitrary sequences that is 
specified by section 2 occurs.

     As a representative of Oracle was present when this decision was 
made, I will assume the response is acceptable to you.

Thanks,

Henry [On behalf of the XSL and XML Query Working Groups]
[1] 
http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0921.html
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

SECTION 3: Serialization parameters

It is not clear what the scope of phase 1, "Markup generation", is.
It says that this phase "produces the representation of start
and end tags for elements, and other constructs such as ...".
The use of "such as..." is non-specific.  It would be better to
provide a complete list of what is included.  Even the phrase
"representation of start and end tags for elements" is not very
clear -- does this include the attributes and namespace declarations
within the start tag?


- Steve B.

    

SECTION 3: Serialization parameters

Perhaps there should be a parameter to indicate whether to 
output elements with no children as start-tag plus end-tag or as
empty-element tags.

- Steve B.

    

SECTION 4: XML output method

Second para: "In all other circumstances, the serialized form must
comply with the requirements described for the xml output method."
It is not clear what "all other circumstances" is constrasting
itself with.  One naturally looks back to the first paragraph
to see what conditions it lays out.  The only condition in that
paragraph appears to be "unless the processor is unable to 
satisfy those rules...".  Thus the logical structure appears to
be:

test if the processor is able to satisfy such-and-such rules
  if yes, the beginning of the first paragraph appies
  if no, the second paragraph applies.

But this seems unlikely to be your intent.


- Steve B.

    

Steve,

     In [1], you submitted the following comment on the Last Call Working 
Draft of XSLT 2.0 and XQuery 1.0 Serialization:

<<
SECTION 4: XML output method

Second para: "In all other circumstances, the serialized form must
comply with the requirements described for the xml output method."
It is not clear what "all other circumstances" is constrasting
itself with.  One naturally looks back to the first paragraph
to see what conditions it lays out.  The only condition in that
paragraph appears to be "unless the processor is unable to 
satisfy those rules...".  Thus the logical structure appears to
be:

test if the processor is able to satisfy such-and-such rules
  if yes, the beginning of the first paragraph appies
  if no, the second paragraph applies.

But this seems unlikely to be your intent.
>>

     Thank you for this comment.

     The XSL and XML Query Working Groups discussed your comment.  In 
response to other comments in Section 4, the working groups decided to 
reword the first and third paragraphs of that section in order to make it 
clear that a serialization error results if the serialized result is not a 
well-formed document entity or external general parsed entity.  In 
addition, the second paragraph of section 4 was deleted.

     The working groups believe that these changes address your comment as 
well.

     I believe that a representative of Oracle was present when this 
decision was made, so I will assume the response is acceptable to you.

Thanks,

Henry [On behalf of the XSL and XML Query Working Groups]
[1] 
http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0924.html
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

SECTION 4: XML output method

Setting the indent parameter to yes may introduce additional
whitespace in the output.  Reparsing the output value may 
retain this additional whitespace, for example, if it is added
to an element of mixed content.  This exception is not listed.
(You have an exception for the character expansion phase, but
the indent parameter is processed by the Markup generation 
phase, so the exception for character expansion does not 
cover the action of the indent parameter.)


- Steve B.

    

Steve,

     In [1], you submitted the following comment on the Last Call Working 
Draft of XSLT 2.0 and XQuery 1.0 Serialization.

> SECTION 4: XML output method
> 
> Setting the indent parameter to yes may introduce additional
> whitespace in the output.  Reparsing the output value may 
> retain this additional whitespace, for example, if it is added
> to an element of mixed content.  This exception is not listed.
> (You have an exception for the character expansion phase, but
> the indent parameter is processed by the Markup generation 
> phase, so the exception for character expansion does not 
> cover the action of the indent parameter.)

     Thank you for your comment.

     The XSL and XQuery working groups discussed your comment, and agreed 
with your analysis.  The following item will be added to the bulleted list 
in section 4 to address this comment:

<<
o Additional text nodes consisting of whitespace characters may be present 
in the new tree and some text nodes in the new tree may contain additional 
whitespace characters that were not present in the original tree if the 
indent parameter has the value yes, as described in 4.3 XML Output Method: 
the indent Parameter.
>>

     As you were present when this decision was made, I will take it that 
the decision is acceptable to you.

Thanks,

Henry
[1] 
http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0926.html
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

SECTION 4: XML output method

Final bullet says "Additional nodes may be present in the new tree
.. due to the character expansion phase of serialization."
Could you please give an example of how character expansion can
cause new nodes?  I don't see how any of the four kinds of
character expansion (URI escaping, CDATA sections, character
mapping, special character references) can cause a new node.
While these character expansions might change the physical 
presentation of a text node, I don't see how they can cause one
text node to become two text nodes, for example.


- Steve B.

    

Steve,

     In [1], you submitted the following comment on the Last Call Working 
Draft of XSLT 2.0 and XQuery 1.0 Serialization.

> SECTION 4: XML output method
> 
> Final bullet says "Additional nodes may be present in the new tree
> .. due to the character expansion phase of serialization."
> Could you please give an example of how character expansion can
> cause new nodes?  I don't see how any of the four kinds of
> character expansion (URI escaping, CDATA sections, character
> mapping, special character references) can cause a new node.
> While these character expansions might change the physical 
> presentation of a text node, I don't see how they can cause one
> text node to become two text nodes, for example.

     Thank you for your comment.

     The XSL and XQuery working groups discussed your comment, and decided 
to add a note to clarify the situation.  I would like to add the following 
note to the final bullet of the bulleted list in section 4.

<<
Note:  The use-character-maps parameter can cause arbitrary characters to 
be inserted into the serialized XML document in an unescaped form, 
including characters that would be considered part of XML markup.  Such 
characters could result in arbitrary new element nodes, attribute nodes, 
and so on, in the new tree that results from processing the serialized XML 
document.
>>

     As you were present when this decision was made, I will take it that 
the decision is acceptable to you.

Thanks,

Henry
[1] 
http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0927.html
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

SECTION 4.5: XML output method: the omit-xml-declaration parameter

The last sentence says "The omit-xml-declaration parameter must
be ignored if the standlone parameter is present, or if the 
encoding parameter specifies a value other than UTF-8 or UTF-16."
That is, if standalone is specified, then an XML declaration is 
mandatory in the output.  Isn't an XML declaration also mandatory
if the version is not 1.0?  That should probably be added to 
the list in this sentence.


- Steve B.

    

Steve,

     In [1], you submitted the following comment on the Last Call Working 
Draft of XSLT 2.0 and XQuery 1.0 Serialization.

> SECTION 4.5: XML output method: the omit-xml-declaration parameter
> 
> The last sentence says "The omit-xml-declaration parameter must
> be ignored if the standlone parameter is present, or if the 
> encoding parameter specifies a value other than UTF-8 or UTF-16."
> That is, if standalone is specified, then an XML declaration is 
> mandatory in the output.  Isn't an XML declaration also mandatory
> if the version is not 1.0?  That should probably be added to 
> the list in this sentence.

     Thank you for your comment.

     The XSL and XQuery working groups discussed your comment, and 
concluded that, although XML 1.1 requires a document entity to have an XML 
declaration, it does not require an external general parsed entity to have 
a text declaration.

     However, prompted by your comment, the working groups decided to 
formulate their requirements for the omit-xml-declaration parameter to fit 
with the requirements of XML 1.0 and XML 1.1.  The specification will 
require the setting of the omit-xml-declaration parameter to be obeyed 
always, and to require conflicts between the settings of that parameter 
and other parameters to be considered a serialization error.  A host 
language would, of course, have the option of ensuring such conflicts 
never arise through whatever language-specific mechanism it uses to 
specify serialization parameters.

     In particular, the working groups decided that if the serialized 
result could be considered to be the text declaration of an external 
general parsed entity, the omit-xml-declaration parameter could have the 
value yes or the value no, and the parameter's setting would take effect. 
They further decided that if the serialized result could only be 
considered to be a document entity because

  o the standalone parameter had the value yes or no; or
  o the version parameter had a value other than 1.0 and the
    doctype-system parameter was supplied

the omit-xml-declaration parameter must have the value no.  Otherwise, a 
serialization error results.

     As you were present when this decision was made, I will take it that 
the decision is acceptable to you.

Thanks,

Henry [On behalf of the XSL and XQuery Working Groups.]
[1] 
http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0928.html
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

SECTION 4: XML output method

Fifth paragraph says "In addition, the output must be such that 
if a new tree was constructed by parsing the XML document and 
converting it into a data model 
as specified in [Data Model], then the new data model
would be the same as the starting data model, with the following
possible exceptions:...".  The word "same" is not defined for
data models (sic; you mean "sequence", "item", "node" or 
"document node").  One cannot apply the word "same" 
literally to properties that are sequences of nodes, 
such as parent, children, attributes, and namespaces, since it
is impossible to construct nodes with the same node identity as
the original value.  You may wish to look at how SQL/XML:2003
handled this issue (see Subclause 10.3 "Determination of 
identical values").

- Steve B.

    

SECTION 3: serialization parameters

It says "indent specifies whether the processor may add additional
whitespace when outputting the data model...".  
It is not clear to what extent this interacts with the 
properties of nodes.  For example, if an element's type permits
mixed content, then adding whitespace to that element's content
potentially damages that element's semantics.  If an element has
not been validated, then it is possible that that element is 
intended to have mixed content and the processor just doesn't know
it, so again, the conservative thing to do is to prohibit adding
whitespace.  If an element has been validated and is known to 
have only elements in its content model, then it would be permissible
to add whitespace to that element's content on output as a 
pretty-printing option.  The conclusion is that this parameter
should only govern the output of such elements.


- Steve B.

    

SECTION 4: XML output method

The constraints expressed in the third paragraph, as currently
worded, seem incomplete.  The paragraph says
"If the document node of the data model has a single element node 
child and no text node children, and the serialized output is a 
well-formed XML document entity, the serialized output must conform 
to the XML Namespaces Recommendation [XML Names]. If the data model 
does not take this form, and the serialized output is a well-formed 
XML external general parsed entity, then the serialized output must 
be an entity which, when referenced within a trivial XML document 
wrapper like this

<!DOCTYPE doc [
<!ENTITY e SYSTEM "entity-URI">
]>
<doc>&e;</doc>

where entity-URI is a URI for the entity, produces a document which 
must itself be a well-formed XML document conforming to the XML 
Namespaces Recommendation [XML Names]."

This language seems to leave open the following possibilities:
1. The document node has a single element node child and no text
node child, but the serialized output is not well-formed XML.
2. The document node does not have a single element node child,
or has a text node child, but the serialized output is not a 
well-formed XML external general parsed entity.

I think the solution is to reword the paragraph as follows:

If the document node of the input value has a single element node 
child and no text node children, then the serialized output shall
be a well-formed XML document entity that conforms to the XML 
Namespaces Recommendation [XML Names]. Otherwise, the serialized
output shall be a well-formed XML external general parsed entity, 
which, when referenced within a trivial XML document wrapper like 
this

<!DOCTYPE doc [
<!ENTITY e SYSTEM "entity-URI">
]>
<doc>&e;</doc>

where entity-URI is a URI for the entity, produces a document 
which must itself be a well-formed XML document conforming to the 
XML Namespaces Recommendation [XML Names].





- Steve B.

    

Hi, Steve.

     In [1], you submitted the following comment on the Last Call Working 
Draft of XSLT 2.0 and XQuery 1.0 Serialization:

Steve Buxton wrote on 2004-02-17 06:44:15 AM:
> SECTION 4: XML output method
> 
> The constraints expressed in the third paragraph, as currently
> worded, seem incomplete.  The paragraph says
> "If the document node of the data model has a single element node 
> child and no text node children, and the serialized output is a 
> well-formed XML document entity, the serialized output must conform 
> to the XML Namespaces Recommendation [XML Names]. If the data model 
> does not take this form, and the serialized output is a well-formed 
> XML external general parsed entity, then the serialized output must 
> be an entity which, when referenced within a trivial XML document 
> wrapper like this
> 
> <!DOCTYPE doc [
> <!ENTITY e SYSTEM "entity-URI">
> ]>
> <doc>&e;</doc>
> 
> where entity-URI is a URI for the entity, produces a document which 
> must itself be a well-formed XML document conforming to the XML 
> Namespaces Recommendation [XML Names]."
> 
> This language seems to leave open the following possibilities:
> 1. The document node has a single element node child and no text
> node child, but the serialized output is not well-formed XML.
> 2. The document node does not have a single element node child,
> or has a text node child, but the serialized output is not a 
> well-formed XML external general parsed entity.
> 
> I think the solution is to reword the paragraph as follows:
> 
> If the document node of the input value has a single element node 
> child and no text node children, then the serialized output shall
> be a well-formed XML document entity that conforms to the XML 
> Namespaces Recommendation [XML Names]. Otherwise, the serialized 
> output shall be a well-formed XML external general parsed entity, 
> which, when referenced within a trivial XML document wrapper like 
> this
> 
> <!DOCTYPE doc [
> <!ENTITY e SYSTEM "entity-URI">
> ]>
> <doc>&e;</doc>
> 
> where entity-URI is a URI for the entity, produces a document 
> which must itself be a well-formed XML document conforming to the 
> XML Namespaces Recommendation [XML Names].

     Thank you for your comment.

     The XSL and XML Query Working Groups discussed your comment.  The 
working groups agreed that the first paragraph of section 4 was intended 
to place a requirement on the serialization process that it must produce a 
well-formed entity (a document entity or external general parsed entity, 
as appropriate), unless it is unable to do so because of the effect of the 
character expansion phase of serialization.  Otherwise, a serialization 
error results.

     In response to your comment and a related comment on the first three 
paragraphs of section 4, the working groups decided to make clear the 
intent of the first and third paragraphs of section 4 by making the 
following changes:

- in the first sentence of the third paragraph, change "and the"
  to "then", to make it clear the conditions under which a
  document entity will be the result of the serialization process.

- change the wording to make it clear that these rules describe
  requirements on the processor, rather than on the user.  The
  processor will be required to produce a serialization error if
  it is unable to produce a well-formed entity of the appropriate
  kind, unless that is because of the action of the character
  expansion phase of serialization.

     As this seems to be in agreement with your proposed rewording, and a 
representative of Oracle was present when this decision was made, I will 
assume the response is acceptable.

Thanks,

Henry [On behalf of the XSL and XML Query Working Groups]
[1] 
http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0932.html
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

SECTION 4: XML output method

The third bullet says "The base URIs in the two trees may be
different."  Document nodes also have a property called 
document-uri; probably the document-uri is not recoverable by
reparsing a serialization either.


- Steve B.

    

[My apologies that these comments are coming in after the end of the Last 
Call comment period.]

Section 6

This section states that the default value for the version method is 4.0, 
while section 3 states that the default is implementation defined.  The 
two statements need to be reconciled.  The same comment probably applies 
to other parameters.

Thanks,

Henry
[Speaking on behalf of reviewers from IBM.]
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

    

> 
> Section 6
> 
> This section states that the default value for the version 
> method is 4.0, 
> while section 3 states that the default is implementation 
> defined.  The 
> two statements need to be reconciled.  The same comment 
> probably applies 
> to other parameters.
> 

Actually, I think that the Serialization spec should not define default
values for any parameters. This should be up to the client application
to specify.

Michael Kay

Hello,

     In [1], I submitted the following comment on the last call draft of 
Serialization on behalf of IBM:

Henry Zongaro/Toronto/IBM wrote on 2004-02-17 08:45:45 PM:
> Section 6
>
> This section states that the default value for the version method is
> 4.0, while section 3 states that the default is implementation 
> defined.  The two statements need to be reconciled.  The same 
> comment probably applies to other parameters.

In response [2], Michael Key proposed:

Michael Kay wrote on 2004-02-18 03:31:48 AM:
> Actually, I think that the Serialization spec should not define default
> values for any parameters. This should be up to the client application
> to specify.

     The XSL and XQuery working groups considered this comment, and 
decided to accept Michael Kay's suggestion.

     This note announces the decision and signals my acceptance of the 
response.

Thanks,

Henry
[1] 
http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0976.html
[2] 
http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0988.html
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

[My apologies that these comments are coming in after the end of the Last 
Call comment period.]

Section 6

The default version of HTML should probably be 4.01.  That's the default 
specified by XSLT.

Thanks,

Henry
[Speaking on behalf of reviewers from IBM.]
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

    

Hello,

     In [1], I submitted the following comment on the last call draft of 
Serialization on behalf of IBM:

Henry Zongaro/Toronto/IBM wrote on 2004-02-17 08:46:35 PM:
> Section 6
> 
> The default version of HTML should probably be 4.01.  That's the 
> default specified by XSLT.

     The XSL and XQuery working groups considered this comment, and 
decided to have client specifications of serialization specify all 
parameter value settings.  No defaults will be specified by the 
serialization specification.

     This note announces the decision and signals my acceptance of the 
response.

Thanks,

Henry
[1] 
http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0977.html
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

[My apologies that these comments are coming in after the end of the Last 
Call comment period.]

Section 5

The third bullet of this section states, "The serializer should avoid 
outputting line breaks and multiple whitespace characters within attribute 
values."  It's not clear what a processor should do in such cases.  This 
should state that these characters should be replaced by a single space 
character.

Thanks,

Henry
[Speaking on behalf of reviewers from IBM.]
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

    

Hello,

     In [1], I submitted the following comment on the Last Call Working 
Draft of XSLT 2.0 and XQuery 1.0 Serialization on behalf of IBM:

Henry Zongaro/Toronto/IBM wrote on 2004-02-17 08:53:23 PM:
> Section 5
> 
> The third bullet of this section states, "The serializer should 
> avoid outputting line breaks and multiple whitespace characters 
> within attribute values."  It's not clear what a processor should do
> in such cases.  This should state that these characters should be 
> replaced by a single space character.

     The XSL and XML Query Working Groups discussed the comment, and 
decided to remove this rule about whitespace in attributes for the xhtml 
output method.  All the other rules for describing the formatting 
requirements of the xhtml output method are strictly under the control of 
the processor, but in this case, the user has control of the content of 
the data model instance that is to be serialized, so the serialization 
process should just leave that to the user's control.  Instead, the rule 
will be replaced with a non-normative reference to the compatibility 
appendix of XHTML as guidance to the user. 

     This note announces and acknowledges that decision.

Thanks,

Henry [On behalf of the XSL and XML Query Working Groups]
[1] 
http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0980.html
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

4.5 XML Output Method: the omit-xml-declaration Parameter 
http://www.w3.org/TR/2003/WD-xslt-xquery-serialization-20031112/#N105F3 

This says: "The omit-xml-declaration parameter must be ignored if the 
standalone parameter is present, or if the encoding parameter specifies 
a value other than UTF-8 or UTF-16." 
 
I would like to control the output of the omit-xml-declaration parameter,
where the encoding parameter specifies a value other than UTF-8 or UTF-16.
I often don't use Unicode. I would like the option to output with
non-standard encoding as XHTML. The XHTML standard
(http://www.w3.org/TR/xhtml1/) specifies that "an XML declaration is not
required in all XML documents"; it is often desirable to omit it, given
that it is known that there are unexpected results with some user agents.
 
Thanks
 
Deborah


BBCi at http://www.bbc.co.uk/


This e-mail (and any attachments) is confidential and may contain
personal views which are not the views of the BBC unless specifically
stated.
If you have received it in error, please delete it from your system. 
Do not use, copy or disclose the information in any way nor act in
reliance on it and notify the sender immediately. Please note that the
BBC monitors e-mails sent or received. 
Further communication will signify your consent to this.

    

Deborah,

     In [1], you submitted the following comment on the Last Call Working 
Draft of XSLT 2.0 and XQuery 1.0 Serialization.

> 4.5 XML Output Method: the omit-xml-declaration Parameter 
> http://www.w3.org/TR/2003/WD-xslt-xquery-serialization-20031112/#N105F3 
> 
> This says: "The omit-xml-declaration parameter must be ignored if the 
> standalone parameter is present, or if the encoding parameter specifies 
> a value other than UTF-8 or UTF-16." 
> 
> I would like to control the output of the omit-xml-declaration 
> parameter, where the encoding parameter specifies a value other than
> UTF-8 or UTF-16. I often don't use Unicode. I would like the option 
> to output with non-standard encoding as XHTML. The XHTML standard (
> http://www.w3.org/TR/xhtml1/) specifies that "an XML declaration is 
> not required in all XML documents"; it is often desirable to omit 
> it, given that it is known that there are unexpected results with 
> some user agents.

     Thank you for your comment.

     The XSL and XQuery Working groups discussed your comment.  As 
originally written, XML 1.0 required an XML declaration or a text 
declaration if the encoding of the document or external general parsed 
entity was anything other than UTF-8 or UTF-16.  XSLT 1.0 enforced that 
requirement in its serialization mechanism.  The draft of Serialization 
inherited that behaviour from XSLT 1.0.  However, an erratum to XML 1.0 
removed that requirement.

     In response to your comment, the working groups decided to require 
the XML declaration or text declaration to be omitted, regardless of the 
setting of the encoding parameter.  Serialization will permit an XML 
declaration or text declaration to be omitted in precisely those 
circumstances in which it can be omitted according to XML 1.0 and XML 1.1. 
 This would affect both the xml and xhtml output methods.

     As that is the change you requested, I believe that decision will be 
acceptable to you.   May I ask you to confirm that it is?

Thanks,

Henry [On behalf of the XSL and XQuery Working Groups.]
[1] 
http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0996.html
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

SECTION 3: Serialization parameters

It says "standalone specifies whether the processor is to emit
a standlone document declaration and the value of the declaration;
the value must be yes or no."  The first sentence implies that
standalone is a parameter with three possible values:
don't emit a standalone declaration; do emit and its value is yes;
do emit and its value is no.  Having only two values for the
parameter is not adequate for its task.  

In section 4.5 "XML output method: the omit-xml-declaration
parameter", the last paragraph includes the phrase
"...if the standalone parameter is present...".  This indicates
that your model is that parameters are optional.  With that 
model you can indeed get by with two values for the parameter,
because the third state would be indicated by the absense of
the parameter.  If this is your intent, you should preface the
list of parameters by saying that they are optional.  Also,
most of the parameter descriptions include a sentence of the 
form "If this parameter is not specified..." but a few do not.
It would be good to supply this sentence for all parameters.

- Steve B.

    

Steve,

     In [1], you submitted the following comment on the Serialization last 
call draft:

Steve Buxton wrote on 2004-02-18 05:22:15 PM:
> SECTION 3: Serialization parameters
> 
> It says "standalone specifies whether the processor is to emit
> a standlone document declaration and the value of the declaration;
> the value must be yes or no."  The first sentence implies that
> standalone is a parameter with three possible values:
> don't emit a standalone declaration; do emit and its value is yes;
> do emit and its value is no.  Having only two values for the
> parameter is not adequate for its task. 
> 
> In section 4.5 "XML output method: the omit-xml-declaration
> parameter", the last paragraph includes the phrase
> "...if the standalone parameter is present...".  This indicates
> that your model is that parameters are optional.  With that 
> model you can indeed get by with two values for the parameter,
> because the third state would be indicated by the absense of
> the parameter.  If this is your intent, you should preface the
> list of parameters by saying that they are optional.  Also,
> most of the parameter descriptions include a sentence of the 
> form "If this parameter is not specified..." but a few do not.
> It would be good to supply this sentence for all parameters.

     Thank you for submitting your comment.

     The XSL and XQuery Working groups discussed your comment and several 
related comments.  In most cases, the serialization draft treated a 
parameter whose value was not specified by the client specification as if 
it had been specified with a particular default value that was defined by 
either the serialization draft or by the implementation.  Such parameters, 
though optional from the point of view of the client specification, always 
had some value.  In a few instances - as with the standalone parameter - 
the absence of a parameter was treated as if it was a distinct setting for 
the parameter.

     The working groups decided to place the onus on the client 
specifications (XSLT and XQuery for now) to specify default values for 
parameters, if appropriate, rather than defining any in the Serialization 
specification.  With this change, only the doctype-public and 
doctype-system parameters could be absent.

     The following table, which will replace the descriptions of the 
parameter values that currently appear in Section 3, should clarify this. 
Corresponding changes to the uses of the parameter values in subsequent 
sections will similarly be made.

<<
+----------------------+------------------------------------------------+
|PARAMETER NAME        |PERMITTED VALUES FOR PARAMETER                  |
+----------------------+------------------------------------------------+
|cdata-section-elements|A list of expanded-QNames, possibly empty.      |
+----------------------+------------------------------------------------+
|doctype-public        |A string of Unicode characters.  This parameter |
|                      |is optional.                                    |
+----------------------+------------------------------------------------+
|doctype-system        |A string of Unicode characters.  This parameter |
|                      |is optional.                                    |
+----------------------+------------------------------------------------+
|encoding              |A string of Unicode characters in the range #x21|
|                      |to #x7E (that is, printable ASCII characters);  |
|                      |the value should be a charset registered with   |
|                      |the Internet Assigned Numbers Authority [IANA], |
|                      |[RFC2278] or begin with the characters x- or X-.|
+----------------------+------------------------------------------------+
|escape-uri-attributes |One of the enumerated values yes or no          |
+----------------------+------------------------------------------------+
|include-content-type  |One of the enumerated values yes or no          |
+----------------------+------------------------------------------------+
|indent                |One of the enumerated values yes or no          |
+----------------------+------------------------------------------------+
|media-type            |A string of Unicode characters specifying the   |
|                      |media type (MIME content type) [RFC2376]; the   |
|                      |charset parameter of the media type must not be |
|                      |specified explicitly.                           |
+----------------------+------------------------------------------------+
|method                |An expanded-QName with a null namespace URI, and|
|                      |the local part of the name equal to xml, xhtml, |
|                      |html or text, or having a non-null namespace    |
|                      |URI.  If the namespace URI is non-null, the     |
|                      |parameter specifies an implementation-defined   |
|                      |output method.                                  |
+----------------------+------------------------------------------------+
|normalize-unicode     |One of the enumerated values yes or no          |
+----------------------+------------------------------------------------+
|omit-xml-declaration  |One of the enumerated values yes or no          |
+----------------------+------------------------------------------------+
|standalone            |One of the enumerated values yes, no or none    |
+----------------------+------------------------------------------------+
|undeclare-namespaces  |One of the enumerated values yes or no          |
+----------------------+------------------------------------------------+
|use-character-maps    |A list of pairs, possibly empty, with each pair |
|                      |consisting of a single Unicode character and a  |
|                      |string of Unicode characters.                   |
+----------------------+------------------------------------------------+
|version               |A string of Unicode characters.                 |
+----------------------+------------------------------------------------+
>>

     May I ask you to confirm that this response to your comment is 
acceptable?

Thanks,

Henry
[1] 
http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/1042.html
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

Section 1 Introduction	
Editorial	

We think it may be better, if the serialization document is kept
separate, so other serialization formats can be added without impacting
the general datamodel document.

Michael,

     In [1], you submitted the following comment on the Last Call Working 
Draft of XSLT 2.0 and XQuery 1.0 Serialization:

<<
Section 1 Introduction 
Editorial 

We think it may be better, if the serialization document is kept
separate, so other serialization formats can be added without impacting
the general datamodel document.
>>

     Thank you for this comment.

     The XSL and XML Query Working Groups discussed your comment, and 
agreed that it would be best to specify the serialization process in a 
separate document.  The editorial note will be deleted.

     I am unsure whether any representative of Microsoft, apart from the 
chair of the XML Query WG, was present when this decision was made.  May I 
ask you to confirm that this response is acceptable to you?

Thanks,

Henry [On behalf of the XSL and XML Query Working Groups]
[1] 
http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/1195.html
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

Section 2	
Editorial/Technical	

Please rewrite "Replace any string in the sequence with a text node
whose string value is equal to the string." as "Replace any string with
length greater than 0 in the sequence with a text node whose string
value is equal to the string. Remove any zero-length string from the
sequence."

Section 4		
Editorial/Technical	

Please rewrite "and this may result in type annotations that are either
more or less precise than those in the original result tree." as "and
this may result in type annotations that are different from those in the
original result tree."

General		
Editorial	

Section 2 introduces the term of a normalized sequence. Use this instead
of "data model" in the rules that operate on the normalized sequence.

General		
Technical	

We see a use for an XML-based markup vocabulary or XQuery
expression-based serialization to describe a full data model instance
that provides for all items using a fixed schema that exposes the data
model's node structure and property information. However, we believe
that such a modus should be done in a future version and not delay the
current publication cycle.

Michael,

     In [1], you submitted the following comment on the serialization last 
call:

> General 
> Technical 
> 
> We see a use for an XML-based markup vocabulary or XQuery
> expression-based serialization to describe a full data model instance
> that provides for all items using a fixed schema that exposes the data
> model's node structure and property information. However, we believe
> that such a modus should be done in a future version and not delay the
> current publication cycle.

     Thank you for submitting this comment.

     The XSL and XQuery working groups considered your comment and related 
comments.  There was general agreement that there is some need for a 
mechanism for serializing arbitrary sequences that preserves most or all 
of the properties of the items in an arbitrary sequence that is being 
serialized.

     The working groups decided that precisely defining all of the 
requirements for such a mechanism at this stage would be difficult, and 
would likely lead to a solution that would not satisfy real user 
requirements.  Therefore, the working groups decided to consider such a 
feature for a future revision of the recommendations, and close this 
comment without any changes to the specifications.

     As this seems to be the outcome you proposed, I trust this resolution 
is acceptable to you.  May I ask you to confirm?

Thanks,

Henry
[1] 
http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/1205.html
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

Confirmed.

Thanks
Michael

Section 4.7		
Editorial	

Please add the xml namespace node to the example, since that node is
always in-scope. Also consider to represent the data model nodes without
using an XML serialized form.

Dear XML Query WG and XSL WG,

This is a last call comment on your Serialization document.
We are sorry that this last call comment is late, but it is
very important.

We have earlier sent comments on the Data Model and on XSLT
where we have urged better support for the inheritance of
xml:lang (or for inherited attributes in general). Without
any such support, it is extremely tedious to write a
transformation or query that adequately copies xml:lang
from the input to the output.

In internal discussion, Liam Quin suggested that
it might be more appropriate to submit our comment against
Serialization. The reason for this is that XPath/XSLT offers
reasonable support for extracting xml:lang information from
source documents into the data model. However, when serialized,
this leads in most cases to a completely unnecessary and
undesirable multiplication of xml:lang attributes on
virtually every element. Adding some support for reducing
unnecessary xml:lang attributes from the output on
serialization would be highly desirable. As I think we
have written previously, better support for xml:lang
(and maybe inherited attributes in general) was something
that was left over as 'future work' from XSLT 1.0. Your
current work is the best chance to fix this problem.

Regards,     Martin.

Hello!

[Sorry if this issue has been raised already.]

I believe the following words are a bit misleading:

"2.2.4 Serialization

[Definition: Serialization is the process of converting a set of nodes 
from the data model into a sequence of octets (step DM4 in Figure 1.) ]"
[1]

So, only nodes from DM are to be serialized? What about atomic values?

[1] http://www.w3.org/TR/xquery/#id-serialization
-- 
Oleg Tkachenko
http://www.tkachenko.com/blog
Multiconn Technologies, Israel

    

Serialization Section 2, "Serializing Arbitrary Data Models": The note at 
the end of this section contains code that is too wide to print. Also, the 
XQuery expression in this node will not parse because it has no 
parentheses around the conditional part of the if-expression. This note 
should be edited as necessary because of the "documentization" process 
described above. The resulting code should be checked for validity and 
broken into lines of suitable length.

--Don Chamberlin

    

Serialization Section 3, "Serialization Parameters": The 
"undeclare-namespaces" parameter needs a better explanation. I am guessing 
that it means the following: If no namespace node attached to an element E 
defines the namespace prefix P, but P is defined by a namespace node 
attached to the parent of element E, then the serialization of element E 
must contain a namespace declaration attribute that binds the prefix P to 
an empty URI.

--Don Chamberlin

    

Serialization Section 4, "XML Output Method": The third paragraph contains 
a circular definition of the serialized output that depends on the 
serialized output. Presumably it intends to say something like this: "If 
the document node of the data model has a single element node and no text 
node children, then the serialized output is a well-formed XML document 
entity that conforms to the XML Namespaces Recomendation. Otherwise, the 
serialized output is a well-formed XML external general parsed entity 
which, when referenced within a trivial XML document wrapper like this 
..."   (This will clean up the circular logic. But this whole paragraph 
should be edited based on the "documentization" process described is 
separate comment IBM-SE-001.) 

--Don Chamberlin

    

Serialization Section 4, "XML Output Method": The paragraph before the 
bullet list says that the round-tripped data model must be "the same as 
the starting data model". This should be clarified to mean the data model 
after the "normalization" (or "documentization") process described in 
Section 2.

--Don Chamberlin

    

Editorial

[J] [Section 6.5 HTML Output Method] Encoding states that [style-1] "then
unless the include-content-type parameter is present and has the value "no""
But, for all other parameters, the style is [style-2] "If the xxx parameter
has the value yes". We have a preference for [style-2]. For consistency, we
request you to recast the sentence in Section 6.5 using [style-2].

On behalf of the XML Schema WG.

	-- Mary
	   Holstege@mathling.com

    

Yes. There are a few phrases like this that predate the separation of
the serialization spec from XSLT, and that make assumptions about the
default values of parameters: the theory is that defaults should be
defined in the XSLT specification, not here, but this has not always
been carried through.

Michael Kay (speaking personally)

Editorial

[M] [Section 1: Introduction] The key words defined in RFC 2119 are in
uppercase and should be here too and where used as a term of art. e.g.
s/may/MAY s/must/MUST etc. or a note should be added clarifying that the
lowercase forms are always used as terms of art.

On behalf of the XML Schema WG.

	-- Mary
	   Holstege@mathling.com

    

Editorial

[N] [Section 2: Serializing Arbitrary Data Models] This section uses terms
from 'XQuery 1.0 and XPath 2.0 Data Model' and 'XQuery 1.0 and XPath 2.0
Functions and Operators' - such as 'sequence', 'atomic value', 'text node',
'document node', 'casting to xs:string', etc. For readability, these terms
should be cross linked to the extent that it is possible.

On behalf of the XML Schema WG.

	-- Mary
	   Holstege@mathling.com

    

Editorial

[O] [Section 3: Serialization Parameters] 'use-character-maps' is a
misnomer. It is not a boolean parameter as it sounds. It is a list of
{character, string} pairs. Similar to cdata-section-elements, it should be
'character-maps'.

On behalf of the XML Schema WG.

	-- Mary
	   Holstege@mathling.com

    

Editorial

[P] [Section 3: Serialization Parameters] Though the title is 'Serialization
Parameters', this section also outlines the four phases of serialization.
Request to break this section into two: 'Serialization Parameters' and
'Serialization'.


On behalf of the XML Schema WG.

	-- Mary
	   Holstege@mathling.com

    

Mary,

     In [1], you submitted the following comment on the Last Call Working 
Draft of XSLT 2.0 and XQuery 1.0 Serialization on behalf of the XML Schema 
Working Group:


Mary Holstege wrote on 2004-02-12 04:18:57 PM:
> Editorial
> 
> [P] [Section 3: Serialization Parameters] Though the title is 
'Serialization
> Parameters', this section also outlines the four phases of 
serialization.
> Request to break this section into two: 'Serialization Parameters' and
> 'Serialization'.

     I have applied the editorial change that you suggested, splitting the 
section into two.  I named the second section "Phases of Serialization". 
Thanks to you and the Schema WG for this comment.

Thanks,

Henry
[1] 
http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0276.html
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

Editorial

[Q] [Section 4.5: XML Output Method: the omit-xml-declaration Parameter]
This section jams two parameters, omit-xml-declaration and standalone.
Suggestion: split them into 2 sections.

On behalf of the XML Schema WG.

	-- Mary
	   Holstege@mathling.com

    

Mary,

     In [1], you submitted the following comment on the Last Call Working 
Draft of XSLT 2.0 and XQuery 1.0 Serialization on behalf of the XML Schema 
Working Group:

Mary Holstege wrote on 2004-02-12 04:19:19 PM:
> Editorial
> 
> [Q] [Section 4.5: XML Output Method: the omit-xml-declaration Parameter]
> This section jams two parameters, omit-xml-declaration and standalone.
> Suggestion: split them into 2 sections.

     Thanks to you and the Schema Working Group for this comment.  I felt 
that the effect of the standalone parameter is too tightly coupled with 
the effect of the omit-xml-declaration parameter to split this section 
into two.  Rather than make the proposed change, I decided to rename the 
section "XML Output Method: the omit-xml-declaration and standalone 
Parameters".

     I hope that change will be acceptable to the working group.

Thanks,

Henry
[1] 
http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0278.html
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

Dear XML Query WG and XSL WG,

Below please find the I18N WGs comments on your last call document
"XSLT 2.0 and XQuery 1.0 Serialization"
(http://www.w3.org/TR/2003/WD-xslt-xquery-serialization-20031112/).

Please note the following:
- Please address all replies to there comments to the I18N IG mailing
   list (w3c-i18n-ig@w3.org), not just to me.
- Our comments are numbered in square brackets [nn].


We look forward to further discussion with you.

[this mail is copied to the DOM WG to tell them what we are
telling you about UTF-16 and endianness, which they should
adopt for the
Document Object Model (DOM) Level 3 Load and Save Specification]

Editorial:

[26] Normalization: This term is used for different things:
   - Character normalization (Charmod, NFC)
   - Normalization as described in section 2 of this document.
   - Normalization as described in the formal semantics document.
   These should be very clearly distinguished and labeled.

[27] Section 3, 'media-type', says "... the charset parameter of the
   media type must not be specified explicitly". This should be
   changed to "... the charset parameter of the media type must
   not be specified explicitly here." to make clear that this
   is just a statement about this parameter, not in general.

[28] Section 3, "omit-xml-declaration specifies whether the serialization
   process is to output an XML declaration. The value must be yes or no
   If this parameter is not specified, the value is implementation defined."
   The wording should be improved to make clear which is yes and which
   is no. (and please add a period after 'no').

[29] Section 4: "Additional nodes may be present in the new tree, and
   the values of attribute nodes and text nodes in the new tree may be
   different from those in the original tree, due to the character
   expansion phase of serialization.": this should clearly state
   that this applies only to URI escaping and character mapping, and
   that CDATA sections and escaping of special characters cannot
   create differences.

[30] 4.8: "If the output method is xml and the value of the version
   parameter is 1.0, namespace >UN<declaration is not performed,
   and the undeclare-namespace parameter is ignored."

[31] Section 5 and Section 6: "If the data model includes a head element
   that has a meta element child, the processor should replace any
   content attribute of the meta element, or add such an attribute,
   with the value as described above, rather than output a new meta element."
   This is written as if there would be only one <meta> element.
   Replacement should only take place if the <meta> element has a
   http-equiv attribute with value 'Content-Type'.

[32] Section 5 and Section 6: Note starting: "This escaping is deliberately
   confined to non-ASCII characters,": There are certain ASCII characters
   that are not allowed in URIs. They should be escaped.

[33] Section 7, freestanding paragraph "The default encoding for the text
   output method is implementation-defined.": this is a repetition from
   the previous paragraph and should be removed.

[34] RFC 2376 is obsoleted by RFC 3023.

Regards,    Martin.

> [32] Section 5 and Section 6: Note starting: "This escaping 
> is deliberately
>    confined to non-ASCII characters,": There are certain 
> ASCII characters
>    that are not allowed in URIs. They should be escaped.

The decision here is very deliberate, as the text says. Note that
appendix B.2.1 of the HTML 4.0 specification also refers to %HH escaping
only in connection with non-ASCII characters.

Although characters such as spaces are not allowed in URIs, if you
escape them in URIs that are interpreted client-side, such as
javascript: URIs, the URI stops working in most browsers.  

Also, you can't escape an id attribute that acts as the target of a
link, because % is not valid in an ID attribute. In practice (whatever
the spec says) if you escape the URI fragment identifier of a same-page
URI reference but don't escape the corresponding ID attribute, the
browser doesn't match them up. In fact, the evidence appears to be that
browsers don't unescape URIs at all, they leave this to be done at the
server. Escaping non-ASCII characters, as we currently specify, appears
to work for fragment identifiers referring to a different page, but not
for same-page references. It's a mess, which is one reason why we now
provide the option to switch off automatic escaping of URIs and allow
the user to do it themselves using the escape-uri() function.

Regards,

Michael Kay

SECTION 1.7: Namespaces and prefixes

This section describes three namespaces, which have distinct URIs,
prefixes and purposes.  It would be great to have a table that 
summarizes all of this.  As it is right now, in the middle of the 
section you have a bulleted list that pulls together two out of 
three of these ingredients (the namespace URI and the purpose) but
not the prefix.  The correct prefixes are certainly deducible from
other material in this section, but why not just put all the 
information together in one convenient table?

- Steve B.

    

SECTION 2: Serializing arbitrary data models

Step 1 says to replace an empty sequence by a zero-length string,
which is presumably an atomic value of type xs:string of length
0.  Step 2 casts this xs:string to xs:string, a no-op.
Step 3 would add a space if there were more than one 
atomic value in the sequence, but there is not, so this step is 
a no-op.
Step 4 says to convert this atomic value into a text node
with the same string value.  But a text node may not have a 
zero-length string as its content; this is a bug in the 
specification.  Perhaps step 4 should be 
interpreted as simply deleting any zero-length xs:string 
values from the sequence.  In that case, if we started with an
empty sequence, we are back to an empty sequence, and one wonders
why step 1 is there.  Or perhaps step 4 is intended to raise 
a serialization error.  If that is the intention, please say so.

- Steve B.

    

SECTION 4.7 : XML output method: the undeclare-namespaces parameter

Last sentence: "If the output method is xml and the value of the
version parameter is 1.0, namespace declaration is not performed...".
This statement looks incorrect.  Surely the output of an XML 1.0
method must declare namespaces, otherwise the result will not 
conform to Namespaces 1.0 Recommendation.  I think "declaration"
is a typo here; I think you mean "undeclaration".


- Steve B.

    

Steve,

     In [1], you submitted the following comment on the Last Call Working 
Draft of XSLT 2.0 and XQuery 1.0 Serialization.


Stephen Buxton wrote on 2004-02-17 06:32:42 AM:
> SECTION 4.7 : XML output method: the undeclare-namespaces parameter
> 
> Last sentence: "If the output method is xml and the value of the
> version parameter is 1.0, namespace declaration is not performed...".
> This statement looks incorrect.  Surely the output of an XML 1.0
> method must declare namespaces, otherwise the result will not 
> conform to Namespaces 1.0 Recommendation.  I think "declaration"
> is a typo here; I think you mean "undeclaration".

     Thank you for pointing out this typographical error.  In response to 
another issue, this conflict in the settings of parameters has become a 
serialization error; the subsequent rewording removed the typo.

Thanks,

Henry
[1] 
http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0920.html
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

SECTION 3: Serialization parameters

The parameter "version" is said to be "the version of the output
method".  Viewing an output method as a deliverable product,
or component of a deliverable product,
the version of the output method is not subject to
change from invocation to invocation, and hence is not a 
parameter in the usual meaning of the term, being rather a 
descriptive identifier about the output method, just the same as
the name of the vendor selling the output method is not a 
parameter, it is a descriptive identifier.  Perhaps what is meant
is the version of XML to be generated.  This is corroborated by
section 4.1 "XML output method: the version parameter".

- Steve B.

    

SECTION 4: XML output method

Sixth open circle bullet: "Additional namespace nodes may be 
present in the new tree if the serialization process undeclared
namespaces...".  On first reading, this sentence seemed 
ungrammatical.  The problem was that it felt like "the 
serialization" was the subject, and "process" was the verb,
which should either be "processes" or "processed", and then
"undeclared namespaces" would be the direct object.
Rewording it as "Additional namespace nodes may be 
present in the new tree if the serialization process undeclared
one or more namespaces..." might help.

- Steve B.

    

Steve,

     In [1], you submitted the following comment on the Last Call Working 
Draft of XSLT 2.0 and XQuery 1.0 Serialization.

Stephen Buxton wrote on 2004-02-17 06:44:21 AM:
> SECTION 4: XML output method
> 
> Sixth open circle bullet: "Additional namespace nodes may be 
> present in the new tree if the serialization process undeclared
> namespaces...".  On first reading, this sentence seemed 
> ungrammatical.  The problem was that it felt like "the 
> serialization" was the subject, and "process" was the verb,
> which should either be "processes" or "processed", and then
> "undeclared namespaces" would be the direct object.
> Rewording it as "Additional namespace nodes may be 
> present in the new tree if the serialization process undeclared
> one or more namespaces..." might help.

     Thank you for pointing out the potential difficulty in parsing this 
sentence.

     I have reworded the clause as follows:  "Additional namespace nodes 
may be present in the new tree if the serialization process did not 
undeclare one or more namespaces. . . ."  Note that "undeclared" has 
become "did not undeclare" in response to a substantive comment.  I hope 
you will find that the new version is not so difficult to parse.

Thanks,

Henry
[1] 
http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0933.html
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

SECTION 3: Serialization parameters

Assuming that phase 1, "Markup generation", is responsible for
creating namespace declarations, the parameter undeclare-namespaces
is relevant to this phase and should be listed here.


- Steve B.

    

Steve,

     In [1], you submitted the following comment on the Last Call Working 
Draft of XSLT 2.0 and XQuery 1.0 Serialization.

Stephen Buxton wrote on 2004-02-17 06:44:00 AM:
> SECTION 3: Serialization parameters
> 
> Assuming that phase 1, "Markup generation", is responsible for
> creating namespace declarations, the parameter undeclare-namespaces
> is relevant to this phase and should be listed here.

     Yes, creation of namespace declarations falls under the purview of 
the markup generation phase.  I have added the undeclare-namespaces 
parameter to the list of parameters that influence that phase of 
serialization.  Thank you for pointing out the omission.

Thanks,

Henry
[1] 
http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0934.html
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

SECTION 4: XML output method

Last sentence concludes with "...if nodes in the model contain
characters that are invalid in XML (introduced, perhaps, by
calling a user-written extension function: this is an error
but the processor is not required to signal it)." It is not
clear what is meant by "processor".  Does this refer to the 
XQuery engine that invoked the user-written extension and 
thereby obtained a corrupt value, or does it refer to the 
XML output method?  Probably the former, since there does 
not appear to be any provision for calling user-written 
functions from the output method.  This could be fixed by
changing "processor" to "XQuery processor".

- Steve B.

    

SECTION 4: XML output method

Sixth bullet, "Additional namespace nodes may be present in the 
new tree if the serialization process undeclared namespaces."
This seems to be a misstatement of what you intend.  Given a
document node D with an element node E1 with a child E2 with fewer
inscope namespaces than its parent E1, then there are four scenarios
to consider, forming a two-by-two matrix: The output method may
undeclare namespaces, or it may not; and the parse of the output
may be an XML 1.0 parser or an XML 1.1 parser.  The analysis of
the four cases is:

undeclare, reparse with XML 1.0: this will generate an error 
during the reparse, since undeclaring is not a feature of XML 1.0.

undeclare, reparse with XML 1.1: this will restore the original
value.

no undeclare, reparse with XML 1.0: no error during the reparse
step (at least for namespace undeclarations), so the resulting
document node will have more namespace nodes in the regenerated
E2 than it should have.

no undeclare, reparse with XML 1.1: same analysis as preceeding case.

Thus the correct statement is that additional namespaces nodes 
may be present in the new tree if the serialization process did
not undeclare namespaces.

That is replace "undeclared" with "did not undeclare".


- Steve B.

    

[My apologies that these comments are coming in after the end of the Last 
Call comment period.]

Hello,

     Following are comments on Serialization that we believe to be 
editorial in nature.


------------------------------------------------------------------

Section 2

The last sentence states that xs:NOTATION cannot be converted to 
xs:string.  That's no longer true.

------------------------------------------------------------------

Section 3

In the second bullet (cdata-section-elements), the value should be a list 
of expanded QNames rather than names.

------------------------------------------------------------------

Section 3

In the second bullet (cdata-section-elements), the clause "no elements 
will be treated specially" appears.  The meaning of "treated specially" is 
not clear - the statement should be made more clear.

------------------------------------------------------------------

Section 3

In the penultimate bullet (use-character-maps), the word "provides" is 
vague.  This should use the word "specifies", as do other bullets.

------------------------------------------------------------------

Section 3

In the penultimate bullet (use-character-maps), the name of the parameter 
is not entirely accurate.  In fact, there is just one mapping, though it 
may map many characters to strings.

------------------------------------------------------------------

Section 4.4

The last bullet refers to the xml:space attribute.  A reference to the 
definition of that attribute would be appropriate.

------------------------------------------------------------------

Section 4.4

In the last bullet, the style used to describe the value of the xml:space 
attribute isn't appropriate.  Change 'xml:space="preserve" attribute' to 
"xml:space attribute with the value 'preserve'".

------------------------------------------------------------------

Section 4.5

The last sentence describes circumstances in which the 
omit-xml-declaration parameter should be ignored.  Rather than saying it's 
ignored, it might be easier to understand if this indicated it's treated 
as if the value was "no".

------------------------------------------------------------------

Section 5

In the note in the fifth bullet, "in in" should be "in".

------------------------------------------------------------------

Section 5

Suggest replacing the note in the fifth bullet with the following:

<<
NOTE: Where the process used to construct the input data model does not 
provide complete control over the prefix (or lack thereof) used for an 
element name in the data model, implementors are encouraged to produce 
namepace syntax appropriate to the kind of document being serialized (when 
possible). For example, when serializing a document as XHTML it is 
preferable to bind "http://www.w3.org/1999/xhtml" as the default namespace 
(no prefix), like so: 

<html xmlns="http://www.w3.org/1999/xhtml"> ... </html> 

for best compatability with pre-XHTML applications.
>>

------------------------------------------------------------------

Section 5

The sixth bullet states, "The content type should be set to the value 
given for the media-type parameter; the default value for XHTML is 
text/html. The value application/xhtml+xml, registered in [RFC3236], may 
also be used."  It is not clear whether this means that a processor has 
two choices of media-type to use as the default, or "may also be used" 
refers to what the client of the serialization process may specify as the 
value of the parameter.  That needs to be clearly specified.  If the 
latter, it also needs to be clearly specified whether those are the only 
two values permitted.

------------------------------------------------------------------

Appendix A

Add references to XML 1.1 and Namespaces in XML 1.1.

------------------------------------------------------------------

Thanks,

Henry
[Speaking on behalf of reviewers from IBM.]
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

    

SECTION 2: Serializing arbitrary data models

Step 2 says "If the data model instance contains any atomic
values, or sequences that contain atomic values, ...".
But the input to the normalization process is a single sequence,
and sequences do not nest, so what does it mean to say that
a sequence contains a sequence?  Perhaps you mean the second 
sequence to be a subsequence of the input sequence.  But there
is no need for this case, since if a subsequence contains an
atomic value, the input sequence also contains an atomic value.
The phrase "or sequences that contain atomic values" can be
deleted.

- Steve B.

    

Steve,

     In [1], you submitted the following comment on the Last Call Working 
Draft of XSLT 2.0 and XQuery 1.0 Serialization.


Stephen Buxton wrote on 2004-02-18 05:21:15 PM:
> SECTION 2: Serializing arbitrary data models
> 
> Step 2 says "If the data model instance contains any atomic
> values, or sequences that contain atomic values, ...".
> But the input to the normalization process is a single sequence,
> and sequences do not nest, so what does it mean to say that
> a sequence contains a sequence?  Perhaps you mean the second 
> sequence to be a subsequence of the input sequence.  But there
> is no need for this case, since if a subsequence contains an
> atomic value, the input sequence also contains an atomic value.
> The phrase "or sequences that contain atomic values" can be
> deleted.

     I am not entirely certain why that phrase appeared here, but I agree 
that it is entirely redundant.  I have applied the editorial change that 
you suggested.  Thank you for your comment.

Thanks,

Henry
[1] 
http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/1037.html
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

SECTION 4: XML output method

The first four words of this section are "The xml output method".
The specification is non-constructive and non-deterministic.  
This is a good thing, but it means that there is more than one
acceptable algorithm for an xml output method.  Consequently
calling it "the xml output method" is misleading.  It would be
better to say explicitly that the specification is non-constructive
and non-deterministic, and talk about the requirements on 
"an xml output method" rather than "the xml output method".
Similarly, the title might be "XML output methods" rather than
the singular.

- Steve B.

    

SECTION 4.8:  XML output method: other parameters

There is no section for the standalone parameter, and it is not
mentioned here either.  In section 3 "Serialization parameters"
two paragraphs after the list of parameters, last sentence, it 
says "If the semantics of a parameter are not described for an 
output method, then it is not applicable to that output method."
This would seem to imply that the standalone parameter is not
applicable to the XML output method.  But that can't be; see
section 4.5 "XML output method: the omit-xml-declaration parameter,
which describes interactions between the omit-xml-declaration
parameter and the standalone parameter.  Arguably these mentions
are sufficient, but it would be better if either the standalone
property appeared in the title of some section, or was listed
in this section as one of the "other parameters".

- Steve B.

    

Steve,

     In [1], you submitted the following comment on the Last Call Working 
Draft of XSLT 2.0 and XQuery 1.0 Serialization.

Stephen Buxton wrote on 2004-02-18 05:21:28 PM:
> SECTION 4.8:  XML output method: other parameters
> 
> There is no section for the standalone parameter, and it is not
> mentioned here either.  In section 3 "Serialization parameters"
> two paragraphs after the list of parameters, last sentence, it 
> says "If the semantics of a parameter are not described for an 
> output method, then it is not applicable to that output method."
> This would seem to imply that the standalone parameter is not
> applicable to the XML output method.  But that can't be; see
> section 4.5 "XML output method: the omit-xml-declaration parameter,
> which describes interactions between the omit-xml-declaration
> parameter and the standalone parameter.  Arguably these mentions
> are sufficient, but it would be better if either the standalone
> property appeared in the title of some section, or was listed
> in this section as one of the "other parameters".

     In response to your comment, I applied an editorial change to rename 
the section that was previously entitled "XML output method: the 
omit-xml-declaration Parameter" to "XML Output Method: the 
omit-xml-declaration and standalone Parameters".  I believe that should 
make it clear that the standalone parameter is applicable to the xml 
output method.

     Thank you for submitting your comment.

Thanks,

Henry
[1] 
http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/1039.html
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

SECTION 3: Serialization parameters

Phase 2, "Character markup", fourth bullet, mentions 
escaping of special characters such as <.  You could 
also mention here the creation of character references 
for characters that are not representable in the encoding.


- Steve B.

    

SECTION 2: serializing arbitrary data models

The term "serialization error" is used in various places
but never formally defined and therefore it
is not clear what this term encompasses.  Step 2 says 
"It is a serialization error if the value cannot be cast to 
xs:string." and step 6 says "It is a serialization error if an 
item in the sequence is an attribute node or a namespace node."
So "serialization error" includes at least these two conditions,
but it is not clear on reading this section whether there might
be others defined later in the specification.  The paragraph
after the six steps says "If the normalization process results 
in a serialization error, the processor must signal the error."
So it must signal the two just described; are there any others?


- Steve B.

    

SECTION 3: Serialization parameters

It says "undeclare-namespaces specifies whether namespaces, are..."
The comma should be removed.



- Steve B.

    

Steve,

     In [1], you submitted the following comment on the Last Call Working 
Draft of XSLT 2.0 and XQuery 1.0 Serialization.

Stephen Buxton wrote on 2004-02-18 05:22:21 PM:
> SECTION 3: Serialization parameters
> 
> It says "undeclare-namespaces specifies whether namespaces, are..."
> The comma should be removed.

     Thank you for submitting your comment.

     In response to another comment, the description of the meaning of a 
parameter appears only in the section on the xml output method.  I removed 
the text with the typographical error you pointed out.

Thanks,

Henry
[1] 
http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/1043.html
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

SECTION 3: serialization parameters

The list of parameters appears to be alphabetized, with the 
exception of the first parameter, encoding.  Perhaps this one
should be placed in alphabetic order.  Perhaps there should be
a prefatory note that the parameters are listed in alphabetic 
order.

- Steve B.

    

Steve,

     In [1], you submitted the following comment on the Last Call Working 
Draft of XSLT 2.0 and XQuery 1.0 Serialization.

Stephen Buxton wrote on 2004-02-18 05:22:29 PM:
> SECTION 3: serialization parameters
> 
> The list of parameters appears to be alphabetized, with the 
> exception of the first parameter, encoding.  Perhaps this one
> should be placed in alphabetic order.  Perhaps there should be
> a prefatory note that the parameters are listed in alphabetic 
> order.

     I have applied the first editorial change you suggested, and placed 
all of the parameters in alphabetical order.  I did not feel it was 
necessary to include a prefatory note.  Thank you for submitting your 
comment.

Thanks,

Henry
[1] 
http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/1044.html
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

SECTION 2: Serializing arbitrary data models

The Note towards the end of this section overflows the right
margin when this specification is printed.


- Steve B.

    

Steve,

     In [1], you submitted the following comment on the Last Call Working 
Draft of XSLT 2.0 and XQuery 1.0 Serialization.

Stephen Buxton wrote on 2004-02-18 05:22:38 PM:
> SECTION 2: Serializing arbitrary data models
> 
> The Note towards the end of this section overflows the right
> margin when this specification is printed.

     I believe you were referring specifically to the XQuery expression 
that appears in the example in that note.  I have adjusted the formatting 
of the example, so that it should fit within a page of reasonable width. 
Thank you for pointing out the problem.

Thanks,

Henry
[1] 
http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/1045.html
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

SECTION 2: Serializing arbitrary data models

The introductory paragraph says that the result of each
step should be another sequence.  Step 1 says "Replace an 
empty sequence with a zero-length string."  The term 
"empty string" is a poor choice of terminology.  a 
"string" might be either a text node or an atomic value of
type xs:string.  Since text nodes 
are not allowed to have length zero, you must mean an xs:string
value of length 0.  You could save your readers the trouble
of making these deductions (by possibly missing the fact
that a text node can not be empty) by simply saying
"Replace the empty sequence by an atomic value of type
xs:string and length 0".

- Steve B.

    

SECTION 2: Serializing arbitrary data models

The use of the term "data models" in the title is incorrect.
A data model is an abstract specification of what values are
permissible within a system.  You are not talking about 
serializing arbitrary abstract specifications.
What you mean here is "serializing arbitrary sequences".
This abuse of the term "data model" is persistent throughout
the entire specification.  It would be a good idea to scan
the entire specification for "data model" and use the proper
terminology for those so-called "data models" that are 
really values.


- Steve B.

    

Steve,

     In [1], you submitted the following comment on the Last Call Working 
Draft of XSLT 2.0 and XQuery 1.0 Serialization.

Stephen Buxton wrote on 2004-02-18 05:22:56 PM:
> SECTION 2: Serializing arbitrary data models
> 
> The use of the term "data models" in the title is incorrect.
> A data model is an abstract specification of what values are
> permissible within a system.  You are not talking about 
> serializing arbitrary abstract specifications.
> What you mean here is "serializing arbitrary sequences".
> This abuse of the term "data model" is persistent throughout
> the entire specification.  It would be a good idea to scan
> the entire specification for "data model" and use the proper
> terminology for those so-called "data models" that are 
> really values.

     Thank you for pointing out this error.  The editors of the various 
XQuery and XSLT specifications decided that the appropriate term to use 
when speaking of a value is "instance of the data model", and that the 
term "data model" should be used only when speaking of that specification.

     I have applied this editorial change throughout the Serialization 
specification.

Thanks,

Henry
[1] 
http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/1047.html
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

Section 2		
Editorial	

Please rewrite "whether namespaces, are to be undeclared " as "whether
namespaces are to be undeclared ".

Michael,

     In [2], I sent the following response to one of your comments:

Henry Zongaro/Toronto/IBM wrote on 2004-06-13 02:05:48 PM:
>      In [1], you submitted the following comment on the Last Call 
> Working Draft of XSLT 2.0 and XQuery 1.0 Serialization.
> 
> Michael Rys wrote on 2004-02-26 04:23:18 PM:
> > Section 2 
> > Editorial 
> > 
> > Please rewrite "whether namespaces, are to be undeclared " as "whether
> > namespaces are to be undeclared ".

>      I have corrected the typographical error that you pointed out. 
> Thank you for submitting this comment.

     In fact, in response to another comment, the description of the 
meaning of the undeclare-namespaces parameter appears only in the section 
on the xml output method.  I removed the text with the typographical error 
you pointed out.

     My apologies for any confusion.

Thanks,

Henry
[1] 
http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/1196.html
[2] 
http://lists.w3.org/Archives/Public/public-qt-comments/2004Jun/0062.html
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

Section 2		
Editorial	

"Serialization can be regarded as involving four phases of processing,
carried out sequentially as follows:" should add normalization step that
is mentioned earlier or make it clear that normalization has already
occurred.

Michael,

     In [1], you submitted the following comment on the Last Call Working 
Draft of XSLT 2.0 and XQuery 1.0 Serialization.

Michael Rys wrote on 2004-02-26 04:23:21 PM:
> Section 2 
> Editorial 
> 
> "Serialization can be regarded as involving four phases of processing,
> carried out sequentially as follows:" should add normalization step that
> is mentioned earlier or make it clear that normalization has already
> occurred.

     I have applied an editorial change to indicate that the phases of 
serialization that this describes follow the normalization step.  Thank 
you for your comment.

Thanks,

Henry
[1] 
http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/1199.html
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

Section 4		
Editorial	

Please insert a subsection title before current 4.1 to improve structure
of section.

Section 4.2		
Editorial	

Add some more concrete examples for last paragraph. E.g, U+0007 in XML
1.0 or U+0000 in XML 1.1.

Section 4		
Editorial	

Remove note about using XSD type annotation mechanisms. If this is
added, it should be added as a separate output method (see comment
MS-SER-LC1-012).

Section 4.7		
Editorial	

Please reword "represented most accurately " as "represented accurately
".

Michael,

     In [1], you submitted the following comment on the Last Call Working 
Draft of XSLT 2.0 and XQuery 1.0 Serialization.

Michael Rys wrote on 2004-02-26 04:23:48 PM:
> Section 4.7 
> Editorial 
> 
> Please reword "represented most accurately " as "represented accurately
> ".

     I have applied the editorial change that you recommended.

Thanks,

Henry
[1] 
http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/1203.html
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com