Fwd: I18N Last call comments on Schema Part 1

Forwarded on request of C. M. Sperberg-McQueen3

>Date: Tue, 30 May 2000 18:11:01 +0900
>From: "Martin J. Duerst" <duerst@w3.org>
>Subject: I18N Last call comments on Schema Part 1
>
>Dear Schema WG,
>
>[This mail is crossposted to the I18N IG to allow for further discussion.
>Please feel free to forward these comments to another list, including
>a public list, but please make sure that you don't reveal the mail
>addresses of the various groups.]
>
>This are the last call comments on XML Schema Part 1: Structures
>from the I18N WG/IG.
>
>The comments are numbered by [n], but their order does not
>reflect their importance.
>
>
>[1] The spec repeatedly contains language such as
>     "the string composed of the [character code] of each of the
>      element information item's character information item [children]
>      in order"
>     This is overly complex and confusing. First, a string is composed
>     of characters, not of character codes (which are numbers). This has
>     to be corrected. Second, the phrase is used so often and the concept
>     behind it so obvious that it would help a lot to define a term for
>     it once.
>     [Similar phrases are also found in Part 2, this comment should also
>      be refelected there; it is made here only once for both parts.]
>
>[2] Section 3.12 says: 'In the case of {user information}, indication
>     may be given as to the identity of the (human) language used in
>     the contents, using the xml:lang attribute.'
>     Please change 'may' to 'should'. Also see points [3], [4], [5].
>
>[3] Please indicate how annotations in multiple languages are done.
>     Being able to make annotations in multiple languages in a
>     clearly defined and interoperable way is important.
>
>[4] Section 5.9, in point 2, says that the value of xml:lang must
>     conform to the req's set out in XML 1.0. There are two problems
>     here:
>     - The exact details of the requirements in XML 1.0 are being
>       dealt with as errata (see also point [31] of our comments to
>       Part 2).
>     - There should be no need to spell this out; this should be
>       clear by the fact that XML Schemas is about XML.
>
>[5] It should be made clear that <documentation> can contain
>     additional markup. As neither <annotation> nor <documentation>
>     is defined in App. A, this isn't clear.
>
>[6] It should be clear that for all references of URIs/URI References,
>     this is to be understood as including the provisions of relevant
>     section of the W3C Character Model (http://www.w3.org/TR/charmod/#URIs).
>     Please see point [30] of our comments to Part 2.
>
>[7] In http://lists.w3.org/Archives/Member/w3c-xml-schema-wg/1999Nov/0007.html
>     we have made a detailed request to make sure that XML Schemas can
>     address the problems of i18n-related markup. This detailed request
>     was listed as issue 209 but summarily abandoned.
>     http://www.w3.org/XML/Group/xmlschema-current/issues.html#easyAddIns
>     We have not received any response that would allow us to determine
>     that these issues are addressed satisfactorily in the current spec.
>     We herewith resubmit the abovementioned mail as part of this last
>     call comment, and request the XML Schema WG to provide a detailled
>     answer as part of the resolution process so that we can decide whether
>     our requirements are met. Apart from this general answer with followup,
>     we mention a few specific points below [8].
>
>[8] The mail mentioned in [7] mentions addition of elements and attributes
>     in general, but one particular and particularly frequent case is the
>     addition of child elements to elements that do not have any child
>     elements defined yet. In the current draft, such elements can be
>     defined in two ways, either as 'mixed' without any elements specified
>     or as 'string'.
>     [There may be a third one, 'textOnly', as guessable
>      from 4.3.3. However, the spec seems not consistent on this. For example,
>      there is:
>      {base type definition}
>          The type definition resolved to by the value of the base 
> [attribute],
>          if present, otherwise the simple ur-type definition if the content
>          [attribute] is textOnly, otherwise the complex ur-type definition.
>      but earlear, there is only one ur-type, so this is confusing.]
>
>     In order to make extensions easy, the 'mixed' type without child elements
>     and the string type (as long as not restricted by a facet, and see point
>     [9]) should be merged. In terms of functionality, this should not
>     provide any problems at all, because it is just a question of deferring
>     decisions until they really are necessary.
>
>     It may be claimed that instead of merging 'mixed' and 'string' as above,
>     it would suffice to always use 'mixed' in cases further addition of
>     elements is desired. However, we feel that this is not sufficient,
>     'string' is too easy to use and will be used in too many instances.
>
>[9] As explained in item [35]/[36] of our comments to part 2, it will often
>     be necessary to include character repertoire constraints in XML Schema.
>     Such constraints should also be applicable to character children even
>     if an element also has element children. This can easily be done by
>     allowing a pattern facet even on complex types provided that this
>     pattern facet only consists of a character class expression.
>     This does not pose any problems with respect to the interleaving
>     order of characters conforming to the pattern and elements conforming
>     to the content model.
>
>[10] The verbal complexity of the XML Schema specs, in particular part 1,
>     is extremely high. We have serious doubts regarding understandability
>     by non-native speakers as well as translatability. We ask the XML
>     Schema WG and the editors to undertake every effort to use clear and
>     simple language.
>
>
>Regards,   Martin.

Received on Wednesday, 31 May 2000 01:53:51 UTC