XSLT 2.0 and XQuery 1.0 Serialization Last Call Issues

Last Call Comments 2004-10-18

Editor:
Henry Zongaro

Serialization Last Call issues

This document is an editor's draft and has no normative status

This document identifies the status of Last Call issues on XSLT 2.0 and XQuery 1.0 Serialization as of October 29, 2004.

The XSLT 2.0 and XQuery 1.0 Serialization has been defined jointly by the XML Query Working Group and the XSL Working Group (both part of the XML Activity).

The October 29, 2004 working draft includes a number of changes made in response to comments both received during the Last Call period that ended on Feb. 15, 2004. The working group is continuing to process these comments, and additional changes are expected.

Public comments on this document and its open issues are invited. Comments should be sent to the W3C mailing list public-qt-comments@w3.org. (archived at http://lists.w3.org/Archives/Public/public-qt-comments/) with “[Serial]” at the beginning of the subject field.

Most issues are classified as either .substantive., meaning the editor believes technical changes to the document are required to address them, or .editorial., meaning that the issue is one of specification clarity not technical correctness.

An issue transitions through several states. Issues tracking begins when an issue is .raised.. After discussion, the Working Group may have .decided. how to resolve the issue. This decision is .announced. and hopefully .acknowledged. by external commenters. For the most part, once an issue is decided, it is considered closed.

There are 110 issue(s).

5 raised (2 substantive), 0 proposed, 1 decided, 40 announced and 58 acknowledged.

Id Title Type State Resp.
+qt-2003Nov0050-01 WD-xslt-xquery-serialization-20030502 omit-xml-declaration substantive acknowledged Henry Zongaro
+qt-2003Nov0305-01 [XQuery] SAG-XQ-005 Serializing Arbitrary Sequences substantive acknowledged Henry Zongaro
+qt-2004Jan0019-04 [XSLT2.0] Specify normalization form for serialization substantive acknowledged Henry Zongaro
+qt-2004Jan0029-01 [Serial] omit-xml-declaration substantive acknowledged Henry Zongaro
+qt-2004Feb0049-01 [Serialization] IBM-SE-001: Documentization substantive acknowledged Henry Zongaro
+qt-2004Feb0053-01 [Serialization] IBM-SE-004: XML Output Method substantive acknowledged Henry Zongaro
+qt-2004Feb0055-01 [Serialization] IBM-SE-006: Schema used in round-tripping substantive acknowledged Henry Zongaro
+qt-2004Feb0057-01 [Serialization] IBM-SE-008: Serializing namespace nodes substantive acknowledged Henry Zongaro
+qt-2004Feb0058-01 [Serialization] IBM-SE-009: Discarding of type annotations substantive acknowledged Henry Zongaro
+qt-2004Feb0059-01 [Serialization] IBM-SE-010: Namespace nodes after round-trip substantive acknowledged Henry Zongaro
+qt-2004Feb0060-01 [Serialization] IBM-SE-011: Character expansion substantive acknowledged Henry Zongaro
+qt-2004Feb0061-01 [Serialization] IBM-SE-012: Version parameter substantive acknowledged Henry Zongaro
+qt-2004Feb0062-01 [Serialization] IBM-SE-013: XML v1.1 vs. Namespaces v1.1 substantive acknowledged Henry Zongaro
+qt-2004Feb0064-01 [Serialization] IBM-SE-014: Serializing the "nilled" property substantive acknowledged Henry Zongaro
+qt-2004Feb0146-01 [Serial] canonicalization substantive announced Henry Zongaro
+qt-2004Feb0188-01 Serialization (sometimes) needs to include type information substantive announced Henry Zongaro
+qt-2004Feb0261-01 [Serialization] SCHEMA-A substantive acknowledged Henry Zongaro
+qt-2004Feb0262-01 [Serialization] SCHEMA-B substantive acknowledged Henry Zongaro
+qt-2004Feb0263-01 [Serialization] SCHEMA-C substantive acknowledged Henry Zongaro
+qt-2004Feb0264-01 [Serialization] SCHEMA-D substantive announced Henry Zongaro
+qt-2004Feb0265-01 [Serialization] SCHEMA-E substantive acknowledged Henry Zongaro
+qt-2004Feb0266-01 [Serialization] SCHEMA-F substantive acknowledged Henry Zongaro
+qt-2004Feb0267-01 [Serialization] SCHEMA-G substantive raised Henry Zongaro
+qt-2004Feb0268-01 [Serialization] SCHEMA-H substantive acknowledged Henry Zongaro
+qt-2004Feb0269-01 [Serialization] SCHEMA-I substantive acknowledged Henry Zongaro
+qt-2004Feb0271-01 [Serialization] SCHEMA-K substantive acknowledged Henry Zongaro
+qt-2004Feb0272-01 [Serialization] SCHEMA-L substantive acknowledged Henry Zongaro
+qt-2004Feb0362-01 [Serial] I18N WG last call comments [4] substantive objected Henry Zongaro
+qt-2004Feb0362-02 [Serial] I18N WG last call comments [5] substantive objected Henry Zongaro
+qt-2004Feb0362-03 [Serial] I18N WG last call comments [6] substantive announced Henry Zongaro
+qt-2004Feb0362-04 [Serial] I18N WG last call comments [7] substantive announced Henry Zongaro
+qt-2004Feb0362-05 [Serial] I18N WG last call comments [8] substantive announced Henry Zongaro
+qt-2004Feb0362-06 [Serial] I18N WG last call comments [9] substantive announced Henry Zongaro
+qt-2004Feb0362-07 [Serial] I18N WG last call comments [first comment 12] substantive announced Henry Zongaro
+qt-2004Feb0362-08 [Serial] I18N WG last call comments [11] substantive announced Henry Zongaro
+qt-2004Feb0362-09 [Serial] I18N WG last call comments [Second comment 12] substantive announced Henry Zongaro
+qt-2004Feb0362-10 [Serial] I18N WG last call comments [13] substantive announced Henry Zongaro
+qt-2004Feb0362-11 [Serial] I18N WG last call comments [14] substantive announced Henry Zongaro
+qt-2004Feb0362-12 [Serial] I18N WG last call comments [15] substantive announced Henry Zongaro
+qt-2004Feb0362-13 [Serial] I18N WG last call comments [16] substantive announced Henry Zongaro
+qt-2004Feb0362-14 [Serial] I18N WG last call comments [17] substantive acknowledged Henry Zongaro
+qt-2004Feb0362-15 [Serial] I18N WG last call comments [18] substantive acknowledged Henry Zongaro
+qt-2004Feb0362-16 [Serial] I18N WG last call comments [19] substantive announced Henry Zongaro
+qt-2004Feb0362-17 [Serial] I18N WG last call comments [20] substantive objected Henry Zongaro
+qt-2004Feb0362-19 [Serial] I18N WG last call comments [22] substantive acknowledged Henry Zongaro
+qt-2004Feb0362-20 [Serial] I18N WG last call comments [23] substantive announced Henry Zongaro
+qt-2004Feb0362-21 [Serial] I18N WG last call comments [24] substantive announced Henry Zongaro
+qt-2004Feb0362-22 [Serial] I18N WG last call comments [25] substantive announced Henry Zongaro
+qt-2004Feb0362-24 [Serial] I18N WG last call comments [31] substantive raised Henry Zongaro
+qt-2004Feb0362-25 [Serial] I18N WG last call comments [32] substantive raised Henry Zongaro
+qt-2004Feb0918-01 ORA-SE-341-B: serialization of XQuery DataModel instance is inadequate substantive acknowledged Henry Zongaro
+qt-2004Feb0919-01 ORA-SE-292-B: Processing of empty sequence is roundabout and confusing substantive raised Henry Zongaro
+qt-2004Feb0921-01 ORA-SE-300-B: Implementation-defined output methods need not normalize substantive acknowledged Henry Zongaro
+qt-2004Feb0922-01 ORA-SE-302-B: Phase 1, "Markup generation", is poorly specified substantive acknowledged Henry Zongaro
+qt-2004Feb0923-01 ORA-SE-304-Q: possible parameter for how to handle elements with no children substantive acknowledged Henry Zongaro
+qt-2004Feb0924-01 ORA-SE-308-C: What circumstances are meant by "in all other circumstances"? substantive acknowledged Henry Zongaro
+qt-2004Feb0926-01 ORA-SE-312-B: Missing exception for additional whitespace added by indent parameter substantive acknowledged Henry Zongaro
+qt-2004Feb0927-01 ORA-SE-315-Q: How can character expansion create new nodes? substantive acknowledged Henry Zongaro
+qt-2004Feb0928-01 ORA-SE-326-B: XML declaration is mandatory if the version is not 1.0 substantive acknowledged Henry Zongaro
+qt-2004Feb0929-01 ORA-SE-320-B: What does it mean to say two data models (sic) are the same? substantive raised Henry Zongaro
+qt-2004Feb0930-01 ORA-SE-301-B: Indent parameter should not apply to (potentially) mixed-mode elements substantive acknowledged Henry Zongaro
+qt-2004Feb0932-01 ORA-SE-309-B: Poorly worded constraints on the output substantive acknowledged Henry Zongaro
+qt-2004Feb0936-01 ORA-SE-317-B: document-uri property cannot be serialized substantive decided Henry Zongaro
+qt-2004Feb0976-01 [Serial] IBM-SE-100: Default parameter values should account for specifics for particular output methods substantive acknowledged Henry Zongaro
+qt-2004Feb0977-01 [Serial] IBM-SE-101: Default HTML version substantive acknowledged Henry Zongaro
+qt-2004Feb0980-01 [Serial] IBM-SE-103: Treatment of whitespace in XHTML attributes substantive acknowledged Henry Zongaro
+qt-2004Feb0996-01 FW: XSLT 2.0: XML Output Method: the omit-xml-declaration Parameter substantive announced Henry Zongaro
+qt-2004Feb1040-01 ORA-SE-305-E: Phase 2 should mention generation of character references substantive acknowledged Henry Zongaro
+qt-2004Feb1042-01 ORA-SE-298-E: Please clarify that all parameters are optional substantive acknowledged Henry Zongaro
+qt-2004Feb1195-01 [Serialization] MS-SER-LC1-001 substantive acknowledged Henry Zongaro
+qt-2004Feb1197-01 [Serialization] MS-SER-LC1-002 substantive acknowledged Henry Zongaro
+qt-2004Feb1198-01 [Serialization] MS-SER-LC1-005 substantive acknowledged Henry Zongaro
+qt-2004Feb1204-01 [Serialization] MS-SER-LC1-009 substantive acknowledged Henry Zongaro
+qt-2004Feb1205-01 [Serialization] MS-SER-LC1-012 substantive acknowledged Henry Zongaro
+qt-2004May0006-01 [Serial] additional last call comment about xml:lang substantive announced Henry Zongaro
+qt-2004Feb0050-01 [Serialization] IBM-SE-002: Bugs in example editorial announced Henry Zongaro
+qt-2004Feb0052-01 [Serialization] IBM-SE-003: Undeclare-namespaces parameter editorial announced Henry Zongaro
+qt-2004Feb0054-01 [Serialization] IBM-SE-005: Definition of serialized output editorial announced Henry Zongaro
+qt-2004Feb0056-01 [Serialization] IBM-SE-007: Definition of round-tripping editorial announced Henry Zongaro
+qt-2004Feb0270-01 [Serialization] SCHEMA-J editorial announced Henry Zongaro
+qt-2004Feb0273-01 [Serialization] SCHEMA-M editorial announced Henry Zongaro
+qt-2004Feb0274-01 [Serialization] SCHEMA-N editorial raised Henry Zongaro
+qt-2004Feb0275-01 [Serialization] SCHEMA-O editorial announced Henry Zongaro
+qt-2004Feb0276-01 [Serialization] SCHEMA-P editorial announced Henry Zongaro
+qt-2004Feb0278-01 [Serialization] SCHEMA-Q editorial announced Henry Zongaro
+qt-2004Feb0362-18 [Serial] I18N WG last call comments [21] editorial announced Henry Zongaro
+qt-2004Feb0362-23 [Serial] I18N WG last call comments [26-30,33-34] editorial announced Henry Zongaro
+qt-2004Feb0920-01 ORA-SE-327-B: Surely namespace declaration is part of serializing XML version 1.0 editorial acknowledged Henry Zongaro
+qt-2004Feb0931-01 ORA-SE-306-C: Confusing definition of the "version" parameter editorial announced Henry Zongaro
+qt-2004Feb0933-01 ORA-SE-310-E: difficult sentence to parse editorial acknowledged Henry Zongaro
+qt-2004Feb0934-01 ORA-SE-303-B: undeclare-namespaces parameter is relevant to markup generation editorial acknowledged Henry Zongaro
+qt-2004Feb0935-01 ORA-SE-311-C: What is the "processor"? editorial announced Henry Zongaro
+qt-2004Feb0937-01 ORA-SE-314-B: Additional namespace nodes may be present if serialization does not undeclare namespaces editorial announced Henry Zongaro
+qt-2004Feb0978-01 [Serial] IBM-SE-102: Serialization editorial comments editorial announced Henry Zongaro
+qt-2004Feb1037-01 ORA-SE-293-E: Redundant phrase that can be deleted editorial acknowledged Henry Zongaro
+qt-2004Feb1038-01 ORA-SE-307-E: "An xml output method" is better than "the xml output method" editorial announced Henry Zongaro
+qt-2004Feb1039-01 ORA-SE-328-E: no mention of the standalone property editorial acknowledged Henry Zongaro
+qt-2004Feb1041-01 ORA-SE-296-E: Please define "serialization error" editorial announced Henry Zongaro
+qt-2004Feb1043-01 ORA-SE-299-E: misplaced comma editorial acknowledged Henry Zongaro
+qt-2004Feb1044-01 ORA-SE-297-E: Alphabetization problem editorial acknowledged Henry Zongaro
+qt-2004Feb1045-01 ORA-SE-295-E: The Note overflow the right margin when printed editorial acknowledged Henry Zongaro
+qt-2004Feb1046-01 ORA-SE-291-E: Term "empty string" is a poor choice of words editorial raised Henry Zongaro
+qt-2004Feb1047-01 ORA-SE-290-E: Title misuses the term "data models" editorial acknowledged Henry Zongaro
+qt-2004Feb1196-01 [Serialization] MS-SER-LC1-003 editorial acknowledged Henry Zongaro
+qt-2004Feb1199-01 [Serialization] MS-SER-LC1-004 editorial acknowledged Henry Zongaro
+qt-2004Feb1200-01 [Serialization] MS-SER-LC1-007 editorial announced Henry Zongaro
+qt-2004Feb1201-01 [Serialization] MS-SER-LC1-008 editorial announced Henry Zongaro
+qt-2004Feb1202-01 [Serialization] MS-SER-LC1-006 editorial raised Henry Zongaro
+qt-2004Feb1203-01 [Serialization] MS-SER-LC1-010 editorial acknowledged Henry Zongaro
+qt-2004Feb1206-01 [Serialization] MS-SER-LC1-011 editorial announced Henry Zongaro
qt-2003Nov0050-01: WD-xslt-xquery-serialization-20030502 omit-xml-declaration
[substantive, acknowledged] 2004-09-23
WD-xslt-xquery-serialization-20030502 omit-xml-declaration, David Carlisle (2003-11-12)


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
________________________________________________________________________
draft minutes for day 4, liam@w3.org (2004-01-22)







Re: WD-xslt-xquery-serialization-20030502 omit-xml-declaration [Issue qt-2003Nov0050-01], Henry Zongaro (2004-02-29)


     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.








Re: WD-xslt-xquery-serialization-20030502 omit-xml-declaration [Issue qt-2003Nov0050-01], David Carlisle (2004-02-29)


Thanks, looks good to me.

David








New response to previously decided issue on omit-xml-declaration (Serial qt-2003Nov0050-01), Henry Zongaro (2004-08-30)









Draft XML Query/XSL Joint Teleconference 209 Minutes 	2004-09-21, Pat Case (2004-09-21)









Re:  WD-xslt-xquery-serialization-20030502 omit-xml-declaration, Henry Zongaro (2004-09-21)



David,

     In [1], you submitted the following comment on the Last Call Working 
Draft of 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.
>>

     The XSL and XML Query Working Groups discussed your comment, and 
initially responded in [2], indicating that Serialization would respect 
the setting of the omit-xml-declaration whenever the encoding was UTF-8, 
UTF-16 or some "subset" encoding of those two encodings.

     However, subsequent to making that decision, the working groups 
decided that the setting of the omit-xml-declaration parameter should be 
respected always, regardless of the setting of the encoding parameter. The 
23 July working draft of Serialization [3] reflects that decision.

     Thank you once again for your comment.  May I ask you to confirm that 
the revised 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/2003Nov/0050.html
[2] 
http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/1235.html
[3] http://www.w3.org/TR/2004/WD-xslt-xquery-serialization-20040723/
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com








Re: WD-xslt-xquery-serialization-20030502 omit-xml-declaration, David Carlisle (2004-09-23)




>      Thank you once again for your comment.  May I ask you to confirm that 
> the revised response is acceptable to you?

Yes this is perfectly acceptable, thank you.

David

________________________________________________________________________
This e-mail has been scanned for all viruses by Star. 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
________________________________________________________________________












qt-2003Nov0305-01: [XQuery] SAG-XQ-005 Serializing Arbitrary Sequences


[substantive, acknowledged] 2004-03-29







[XQuery] SAG-XQ-005 Serializing Arbitrary Sequences, Kay, Michael (2003-11-27)


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

    







draft minutes for day 4, Liam Quin (2004-01-22)









Final minutes of the Mandelieu XQuery/XSLT meeting, Massimo Marchiori (2004-03-16)









Fw: [XQuery] SAG-XQ-005 Serializing Arbitrary Sequences, Henry Zongaro (2004-03-28)



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








AW: [XQuery] SAG-XQ-005 Serializing Arbitrary Sequences, Walter.Waterfeld@softwareag.com (2004-03-29)



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












qt-2004Jan0019-04: [XSLT2.0] Specify normalization form for serialization


[substantive, acknowledged] 2004-07-13







[XSLT2.0] Specify normalization form for serialization, Igor Hersht (2004-01-11)


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









draft minutes for day 4, Liam Quin (2004-01-22)









Final minutes of the Mandelieu XQuery/XSLT meeting, Massimo Marchiori (2004-03-16)









Re: [XSLT2.0], Henry Zongaro (2004-03-28)



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








Re: [XSLT2.0], Henry Zongaro (2004-07-13)



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












qt-2004Jan0029-01: [Serial] omit-xml-declaration


[substantive, acknowledged] 2004-09-01







[Serial] omit-xml-declaration, David Carlisle  (2004-01-13)




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
________________________________________________________________________

    







Duplicate issue (Serial qt-2004Jan0029-01), Henry Zongaro (2004-08-30)









Re: [Serial] omit-xml-declaration (qt-2004Jan0029-01), Henry Zongaro (2004-09-01)



David,

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

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

     The XSL and XQuery Working Groups actually logged your comment twice, 
in both [1] and [2].  We would like to close the issue raised in [1] as a 
duplicate of the issue raised in [2].  I trust this will be acceptable. 
Our apologies for any confusion.

Thanks,

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








Re: [Serial] omit-xml-declaration (qt-2004Jan0029-01), David Carlisle (2004-09-01)





> We would like to close the issue raised in [1] as a 
> duplicate of the issue raised in [2].  I trust this will be acceptable. 

Yes, That's fine:-)

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
________________________________________________________________________












qt-2004Feb0049-01: [Serialization] IBM-SE-001: Documentization


[substantive, acknowledged] 2004-04-05







[Serialization] IBM-SE-001: Documentization, XML Query  (2004-02-02)


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

    







Final minutes of the Mandelieu XQuery/XSLT meeting, Massimo Marchiori (2004-03-16)









Fw: [Serialization] IBM-SE-001: Documentization, Henry Zongaro (2004-03-28)



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








Re: Fw: [Serialization] IBM-SE-001: Documentization, Don Chamberlin (2004-04-05)


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












qt-2004Feb0053-01: [Serialization] IBM-SE-004: XML Output Method


[substantive, acknowledged] 2004-06-07







[Serialization] IBM-SE-004: XML Output Method, XML Query  (2004-02-02)


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

    







RE: [Serialization] IBM-SE-004: XML Output Method, Michael Kay (2004-02-03)


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








[VER 2] XML Query/XSL Joint Teleconference 189 Minutes 2004-06-01, Paul Cotton (2004-06-07)









Re: [Serialization] IBM-SE-004: XML Output Method, Henry Zongaro (2004-06-07)



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








Re: [Serialization] IBM-SE-004: XML Output Method, Henry Zongaro (2004-06-07)













qt-2004Feb0055-01: [Serialization] IBM-SE-006: Schema used in round-tripping


[substantive, acknowledged] 2004-09-01







[Serialization] IBM-SE-006: Schema used in round-tripping, XML Query  (2004-02-02)


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

    







Re: [Serialization] IBM-SE-006: Schema used in round-tripping, Don Chamberlin (2004-02-06)


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








Revised Minutes of XML Query/XSL Joint Teleconference 176 - 6 April 2004, Henry Zongaro (2004-04-06)









complete notes (but still raw) for minutes of QT ftf in San Jose 2004-04, C. M. Sperberg-McQueen (2004-04-27)









Serialization and round-tripping, Henry Zongaro (2004-06-12)









Draft minutes Query/XSLT Cambridge days 1-4, massimo@w3.org (2004-06-24)









Final minutes of the Redmond 2004 face to face, Massimo Marchiori (2004-09-06)









Re: [Serialization] IBM-SE-006: Schema used in round-tripping, Henry Zongaro (2004-09-01)



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

     Thank you for your comment.

     The XSL and XML Query Working Groups discussed your comment and 
decided that the "round-tripping" description in Serialization was not 
intended to be part of the definition of validation, but only to define 
the requirements on the form of a serialized instance of the data model. 
The issue will be closed without any change to Serialization.

     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/0055.html
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com








Re: [Serialization] IBM-SE-006: Schema used in round-tripping, Henry Zongaro (2004-09-01)













qt-2004Feb0057-01: [Serialization] IBM-SE-008: Serializing namespace nodes


[substantive, acknowledged] 2004-04-28







[Serialization] IBM-SE-008: Serializing namespace nodes, XML Query  (2004-02-02)


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

    







RE: [Serialization] IBM-SE-008: Serializing namespace nodes, Michael Kay (2004-02-03)


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 








complete notes (but still raw) for minutes of QT ftf in San Jose 2004-04, C. M. Sperberg-McQueen (2004-04-27)









Re: [Serialization] IBM-SE-008: Serializing namespace nodes, Henry Zongaro (2004-04-28)



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








Re: [Serialization] IBM-SE-008: Serializing namespace nodes, Henry Zongaro (2004-04-28)













qt-2004Feb0058-01: [Serialization] IBM-SE-009: Discarding of type annotations


[substantive, acknowledged] 2004-04-13







[Serialization] IBM-SE-009: Discarding of type annotations, XML Query  (2004-02-02)


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

    







RE: [Serialization] IBM-SE-009: Discarding of type annotations, Michael Kay (2004-02-03)


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








Minutes of XML Query/XSL Joint Teleconference 175 - 6 April 2004, Henry Zongaro (2004-04-06)









Re: [Serialization] IBM-SE-009: Discarding of type annotations, Henry Zongaro (2004-04-13)



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








Re: [Serialization] IBM-SE-009: Discarding of type annotations, Henry Zongaro (2004-04-13)













qt-2004Feb0059-01: [Serialization] IBM-SE-010: Namespace nodes after round-trip


[substantive, acknowledged] 2004-07-13







[Serialization] IBM-SE-010: Namespace nodes after round-trip, XML Query  (2004-02-02)


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

    







Minutes of XML Query/XSL Joint Teleconference 175 - 6 April 2004, Henry Zongaro (2004-04-06)









Re: [Serialization] IBM-SE-010: Namespace nodes after round-trip, Henry Zongaro (2004-07-13)



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








Re: [Serialization] IBM-SE-010: Namespace nodes after round-trip, Henry Zongaro (2004-07-13)













qt-2004Feb0060-01: [Serialization] IBM-SE-011: Character expansion


[substantive, acknowledged] 2004-04-13







[Serialization] IBM-SE-011: Character expansion, XML Query  (2004-02-02)


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

    







Minutes of XML Query/XSL Joint Teleconference 175 - 6 April 2004, Henry Zongaro (2004-04-06)









Re: [Serialization] IBM-SE-011: Character expansion, Henry Zongaro (2004-04-13)



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








Re: [Serialization] IBM-SE-011: Character expansion, Henry Zongaro (2004-04-13)













qt-2004Feb0061-01: [Serialization] IBM-SE-012: Version parameter


[substantive, acknowledged] 2004-07-13







[Serialization] IBM-SE-012: Version parameter, XML Query  (2004-02-02)


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

    







RE: [Serialization] IBM-SE-012: Version parameter, Michael Kay (2004-02-03)


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








Draft minutes Query/XSLT Cambridge days 1-4, massimo@w3.org (2004-06-24)









[public-qt-comments] <none>, Henry Zongaro (2004-07-13)


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








[public-qt-comments] <none>, Henry Zongaro (2004-07-13)













qt-2004Feb0062-01: [Serialization] IBM-SE-013: XML v1.1 vs. Namespaces v1.1


[substantive, acknowledged] 2004-10-08







[Serialization] IBM-SE-013: XML v1.1 vs. Namespaces v1.1, XML Query  (2004-02-02)


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

    







complete notes (but still raw) for minutes of QT ftf in San Jose 2004-04, C. M. Sperberg-McQueen (2004-04-27)









Re: [Serialization] IBM-SE-013: XML v1.1 vs. Namespaces v1.1 (qt-2004Feb0062-01), Henry Zongaro (2004-10-08)



Hi, 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 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?
>>

     Thank you for this comment.  The XSL and XML Query Working Groups 
discussed your comment, and decided that all NCNames must conform to the 
version of Namespaces in XML specified by the version parameter; if 
NCNames do not conform to the appropriate version of the Namespaces 
recommendation, a serialization error results.

     Similarly, if the instance of the data model contains any characters 
that are not permitted by the particular version of XML specified by the 
version parameter, a serialization error results.  For instance, if the 
version parameter has the value 1.0, and a text node contains one of the 
non-whitespace control characters in the range #x1 to #x1F, a 
serialization error results, because those characters were not permitted 
in XML 1.0 documents; if the version parameter has the value 1.1, and a 
comment node contains one of the control characters in the range #x7F to 
#x9f, other than NEL, a serialization error results, because those 
characters are also permitted to appear as character references in XML 1.1 
documents.

     Finally, the description of the version parameter should indicate 
that it controls the version of both XML and Namespaces in XML to which 
the serialized result should conform.  No independent parameter specifying 
the version of Namespaces in XML is required.

     I will modify the Serialization specification to reflect these 
decisions.

     As you were present when these decisions were made, I will assume the 
response is acceptable to you.

Thanks,

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








Re: [Serialization] IBM-SE-013: XML v1.1 vs. Namespaces v1.1 (qt-2004Feb0062-01), Henry Zongaro (2004-10-08)













qt-2004Feb0064-01: [Serialization] IBM-SE-014: Serializing the "nilled" property


[substantive, acknowledged] 2004-04-13







[Serialization] IBM-SE-014: Serializing the "nilled" property, XML Query  (2004-02-02)


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

    







Minutes of XML Query/XSL Joint Teleconference 175 - 6 April 2004, Henry Zongaro (2004-04-06)









Re: [Serialization] IBM-SE-014: Serializing the "nilled" property, Henry Zongaro (2004-04-13)



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








Re: [Serialization] IBM-SE-014: Serializing the "nilled" property, Henry Zongaro (2004-04-13)













qt-2004Feb0146-01: [Serial] canonicalization


[substantive, announced] 2004-04-28







[Serial] canonicalization, Elliotte Rusty Harold  (2004-02-07)



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

    







complete notes (but still raw) for minutes of QT ftf in San Jose 2004-04, C. M. Sperberg-McQueen (2004-04-27)









Re: [Serial] canonicalization, Henry Zongaro (2004-04-28)



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












qt-2004Feb0188-01: Serialization (sometimes) needs to include type information


[substantive, announced] 2004-07-13







Serialization (sometimes) needs to include type information, Antoine Mensch (2004-02-11)


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.







Draft minutes Query/XSLT Cambridge days 1-4, massimo@w3.org (2004-06-24)









Re: Serialization (sometimes) needs to include type information, Henry Zongaro (2004-07-13)



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












qt-2004Feb0261-01: [Serialization] SCHEMA-A


[substantive, acknowledged] 2004-05-21







[Serialization] SCHEMA-A, Mary Holstege  (2004-02-12)




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

    







RE: [Serialization] SCHEMA-A, Michael Kay (2004-02-13)


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)








Final minutes of the Mandelieu XQuery/XSLT meeting, Massimo Marchiori (2004-03-16)









Re: [Serialization] SCHEMA-A, Henry Zongaro (2004-03-28)



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








Re: [Serialization] SCHEMA-A, Mary Holstege (2004-05-21)




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












qt-2004Feb0262-01: [Serialization] SCHEMA-B


[substantive, acknowledged] 2004-05-21







[Serialization] SCHEMA-B, Mary Holstege  (2004-02-12)




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

    







complete notes (but still raw) for minutes of QT ftf in San Jose 2004-04, C. M. Sperberg-McQueen (2004-04-27)









Re: [S