W3C home > Mailing lists > Public > www-i18n-comments@w3.org > October 2002

RE: Character Model Comments Clarifications

From: Mark Scardina <mark.scardina@oracle.com>
Date: Mon, 7 Oct 2002 10:49:17 -0700
To: "'Martin Duerst'" <duerst@w3.org>, <www-i18n-comments@w3.org>
Cc: <w3c-xsl-wg@w3.org>, <w3c-i18n-ig@w3.org>
Message-ID: <005b01c26e29$dc298be0$6801a8c0@us.oracle.com>

Martin, the original comment is no longer relevant once the original
text was reviewed based upon your answer.  Please close it.



Mark V. Scardina              Group Product Mgr & XML Evangelist
CORE & XML DEVELOPMENT GROUP  E-mail: Mark.Scardina@oracle.com
Web Site: http://otn.oracle.com/tech/xml/

|-----Original Message-----
|From: Martin Duerst [mailto:duerst@w3.org] 
|Sent: Monday, October 07, 2002 2:18 AM
|To: Mark Scardina; www-i18n-comments@w3.org
|Cc: w3c-xsl-wg@w3.org; w3c-i18n-ig@w3.org
|Subject: RE: Character Model Comments Clarifications
|At 13:33 02/09/24 -0700, Mark Scardina wrote:
|>I will let the group discuss whether response to the first one is 
|>satisfactory.  As to the "one paragraph" comment, my 
|apologies as in my 
|>"cut and pasting" of the WD for our discussion, the paragraphs got 
|>lost. Thus the resulting comment.
|Hello Mark,
|Many thanks for the comment above. Unfortunately, this doesn't 
|really help us understanding your original comment. To make 
|progress on this issue, can I suggest that you, or somebody 
|else from the XSL WG, take the original comment (e.g. at 
|and exchange the sentence
|"It may be less confusing to have these
|requirements separated with a clarifying sentence, breaking 
|these out under a clarifying context."
|with something more detailed, explaining which requirements 
|(i.e. some of those cited, all of those cited,...) where to 
|break, what to clarify in particular, and so on.
|Many thanks in advance for your help.      Regards,    Martin.
|>Mark V. Scardina              Group Product Mgr & XML Evangelist
|>CORE & XML DEVELOPMENT GROUP  E-mail: Mark.Scardina@oracle.com Web 
|>Site: http://otn.oracle.com/tech/xml/
|>|-----Original Message-----
|>|From: Martin Duerst [mailto:duerst@w3.org]
|>|Sent: Monday, September 23, 2002 11:30 PM
|>|To: Mark Scardina; www-i18n-comments@w3.org
|>|Cc: w3c-xsl-wg@w3.org; w3c-i18n-ig@w3.org
|>|Subject: Re: Character Model Comments Clarifications
|>|Hello Mark, dear XSL WG members,
|>|Many thanks for your clarifications. Here are some
|>|responses and some requests for further clarification.
|>|At 14:18 02/09/10 -0700, Mark Scardina wrote:
|>|>Martin regards the issues below our responses are inline.
|>|>1) http://lists.w3.org/Archives/Member/w3c-xsl-wg/2002Aug/0044.html
|>|>[XSL] To clarify, our concern was based on first not seeing a clear 
|>|>definition of a private system and second, based upon what we
|>|>a private system to be, why should it fall under the prevue of your 
|>|>spec. It obviously could not be enforced.
|>|>2) http://lists.w3.org/Archives/Member/w3c-xsl-wg/2002Aug/0045.html
|>|>     (http://www.w3.org/International/Group/2002/charmod-lc/#C146)
|>|>[XSL] XSLT allows and needs manipulation of character
|>|sequences at any
|>|>boundaries not simply entity boundaries.  An XSLT stylesheet
|>|itself can
|>|>expose non-normalized strings in an effort to match sequences
|>|in a 1.0
|>|>document.  It is also not just about serialized XML as 
|processes can 
|>|>exchange result trees which would mean working with the DOM 
|which is 
|>|>not addressed in your spec.
|>|Many thanks for this clarification, which I think moves us forward 
|>|quite a bit. Your original comment was:
|>| >>>>
|>|"[S] Specifications of text-based languages and protocols SHOULD 
|>|define precisely the construct boundaries necessary to obtain a 
|>|complete definition of full-normalization . These definitions MUST
|>|include at least
|>|the boundaries between markup and character data as well as entity
|>|boundaries (if the language has any include mechanism) and
|>|SHOULD include
|>|any other boundary that may create denormalization when
|>|instances of the
|>|language are processed."
|>|The requirement (still in 4.4) about defining construct 
|boundaries is 
|>|very unclear when applied to a language that performs dynamic
|>|manipulation of
|>| >>>>
|>|The requirement that a language has to be clear about the boundaries 
|>|of its syntactic constructs was designed in particular so 
|that simple 
|>|applications of XSLT (where text nodes,... are treated as units and 
|>|not modified, but potentially concatenated) can produce normalized 
|>|output from normalized input easily.
|>|You are right that this conformance criterion doesn't deal with 
|>|dynamic operations. This is deal with later in the spec (same
|>|[S] Specifications of API components (functions/methods) 
|that perform 
|>|operations that may produce unnormalized text output from normalized 
|>|text input MUST define whether normalization is the responsibility
|>|of the caller
|>|or the callee. Specifications MAY make performing
|>|normalization optional
|>|for some API components; in this case the default SHOULD be that
|>|normalization is performed, and an explicit option SHOULD be
|>|used to switch
|>|normalization off. Specifications MUST NOT make the implementation of
|>|normalization optional.
|>|[S] Specifications that define a mechanism (for example an API or a 
|>|defining language) for producing a document SHOULD require that the 
|>|final output of this mechanism be normalized.
|>|These are the criteria that we wrote with e.g. the DOM or 
|the dynamic 
|>|aspects of XSLT in mind.
|>|We therefore decided to treat your comment as 'noted' (i.e. not 
|>|directly applicable), because the matter you commented on is covered 
|>|in another part of our specificiation. Please tell us, at your 
|>|earliest convenience, whether you are satisfied with this resolution 
|>|or not.
|>|If you have any comments on the criteria listed above for API 
|>|components, please raise a new comment for this part of the 
|>|>3) http://lists.w3.org/Archives/Member/w3c-xsl-wg/2002Jul/0088.html
|>|>     (http://www.w3.org/International/Group/2002/charmod-lc/#C140)
|>|>For 3), we asked for clarification on one part of your comment. 
|>|>Actually, we would like you to clarify both sentences. 
|There was some 
|>|>follow-up discussion on 3), but this didn't really clarify
|>|the comment
|>|>itself. If you think that you need to make another comment, please 
|>|>check the comments you have already made, and if you think there is 
|>|>something missing, please submit another comment asap.
|>|>[XSL] Regarding our first sentence, Section 3.5 covers a number of 
|>|>processing scenarios and conditionals in one long paragraph 
|making it 
|>|>difficult to parse and properly evaluate.  Our suggestion was
|>|to break
|>|>this up structurally with additional context so that the types of 
|>|>processes and their exceptions were better delineated.
|>|Can you please clarify 'one long paragraph'?
|>|At http://www.w3.org/International/Group/2002/charmod-lc#C140,
|>|you comment on what looks to us like 6 paragraphs, not one.
|>|>[XSL] Regarding the second sentence, Anders already responded
|>|with some
|>|>examples, but the essence is that XSL and XML for that 
|matter must be 
|>|>able to represent non-Unicode characters inside attributes 
|as well as 
|>|Can you please clarify your usage of 'non-Unicode characters'?
|>|If you refer to the use of the Private Use Area in Unicode, then 
|>|section 3.5 of the Character Model doesn't forbid the use of code 
|>|points from the PUA, although the use of private use codepoints is 
|>|discouraged (and this discouragement explained) in 3.6.3 Private use 
|>|code points.
|>|If you mean characters not represented in any way as Unicode 
|>|codepoints, then we have to admit that it is impossible for us to 
|>|address this comment, because it is very clear that neither XSL nor 
|>|XML are able to represent non-Unicode characters (irrelevant of 
|>|whether they would appear in elements or attributes).
|>|Looking forward to hear from you soon,
|>|Regards,    Martin.
Received on Monday, 7 October 2002 13:50:04 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:20:14 UTC