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 http://www.w3.org/International/Group/2002/charmod-lc/#C140),
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.



>Regards,
>
>Mark
>
>________________________________________________________________
>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
>|>(http://www.w3.org/International/Group/2002/charmod-lc/#C187)
>|>
>|>[XSL] To clarify, our concern was based on first not seeing a clear
>|>definition of a private system and second, based upon what we
>|inferred
>|>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
>|strings.
>| >>>>
>|
>|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
>|subsection):
>|
>|[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
>|specification.
>|
>|
>|>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
>|>elements.
>|
>|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 06:02:45 UTC