Re: forwarded message from C. M. Sperberg-McQueen (PR#8017)

Thank you for you comments. Please see responses inline and comment on 
those as necessary

Thanx

>     This document is the XML Schema implemantaion of abstract modules
>     defined in XHTML Modularization [XHTMLMOD] and defines conformance
>     requirements as defined in Conformance Definition section of XHTML
>     Modularization [XHTMLMOD]
> 
> (Note the typographic error in the word "implementation", which also
> occurs elsewhere.  Also the missing final period.)
> 
> Perhaps the paragraph would be clearer if it read
> 
> but we are not entirely certain whether this is the same thing or not.
> 
>     This document is the XML Schema implemantaion of abstract modules
>     defined in XHTML Modularization [XHTMLMOD].  The conformance
>     requirements of this specification are the same as those defined
>     in Conformance Definition section of XHTML Modularization
>     [XHTMLMOD].
> 

To be specific this section does not exist anymore as the Schema
modularization, as a result of merging this document with second edition
of XHTML Modularization.

More generally, there were a few typographic errors and have been fixed.

> * Status of earlier comments
> 
> We are happy to see that the current draft makes better use of the
> builtin simple types than did the previous one.  We believe better use
> of the pattern facet can and should be made to capture the rules
> governing datatypes like multi-lengths or RFC 2045 encoding or media
> types.
> 
> On the other hand, we note with some disappointment that as far as we
> can tell the October draft of the document does not respond to several
> others of our comments on the previous Last-call draft
> (http://www.w3.org/XML/Group/2003/01/xmlschema-notes-on-xhtml-modularization.html)
> 
> In particular, the current draft still doesn't exploit substitution
> groups at all, 

Two of the features of XHTML Modularization are
   1. Each module is independent of the presence/absence of other
      modules.
   2. The elements (defined in the Modules) are ignorant of
      their place in the document type's content model (hence cannot
      assume substitutability)

  the substitution groups requirements are
    1. must be derived (by extension or restriction)from the a group head
       element. (making the module impl. dependent on each other).
    2. the element implicitly identifies the content models that
       element can occur in. In XHTML modularization this is an
       undesirable as the content model of an document type is defined
       Markup designer, hence use choice model groups as the alternate


>
>doesn't use XHTML for schema-internal documentation,
>

This is a set of schema's that defines XHTML and its XHTML Modules.
Using XHTML in same schema that defines the XHTML modules was considered
undesirable.

>
> and doesn't use the 'source' attribute on the xsd:documentation
> element to point to normative documentation on the definition of
> element types etc.
>

Just rechecked the schema implementations. But for 4 to 5 Schema in 
modules implementations the schema do have
    <xsd:documentation source="..."/>

The remaining 4 to 5 modules (that were missing an URI reference to the 
actual spec.) is also fixed now.

> 
> The current schema does change finalDefault from "#all" to the default
> (empty set), but it leaves blockDefault at "#all".  Why?  This seems
> to us a design error.
> 

The schema are implemented such that
    1. They allow for derivation and substitution groups
       (does not use final/finalDefault),
    2. But prohibits usage of derived elements in the instance documents
      (where the base element is expected).

There were couple of reasons why the above was considered necessary,

    1. XHTML content models are defined in abstract module definitions
      (and designed for maximum portability).  Documents written against
       XHTML must be processable by XHTML conforming user agents whether
       or not those user agents are XML Schema-aware. (hence elements
       morphing using xsi:type is not supported)

    2. Also (for derivations) the DTD impl. does not allow "xsi:type"
       so a user agent were only XML DTD aware, documents that attempted
       use this feature would not be valid.

>
> We also note that it's still deplorably difficult to find one's way
> around in the schema, even for those reasonably comfortable with
> XML Schema notation.  
>

The schema's have been rearranged slightly and the chapter with examples
updated. If there is any specific suggestions those can possibly be
incorporated.

> 
> * Schema errors
> 
> We attach two error reports showing the response of the Xeres J and
> XSV schema processors when we used them to validate a simple document
> (also attached) against your schema.  In summary:
> 
>   - There are several places where you include the same schema
>     document more than once.  While processors are not required to
>     reject this as an error, the response of Xerces J illustrates
>     that they are also not required to accept it with equanimity.
>
>     We suggest eliminating the double inclusions

This has been fixed already, considering the current state of some of
Schema processor implementations.

The schema's now work with xerces-j. Also xerces-j is not consistent on
raising such errors. There are patterns of such inclusions that xerces-j
raises error and there are others patterns in which the xerces-j accepts
such inclusions.

> 
>   - The schema document xhtml-charent-1.xsd includes several entity
>     sets for special characters.  There is nothing illegal about this
>     that our reviewers can determine, but (as the response of xsv
>     illustrates), it does seem to hit a weak spot in some XML
>     libraries' handling of UTF8 and the numeric character references.
>     Since the entities are not in fact used by the schema documents, 
>     but are intended to be available in document instances, there is
>     actually no need to include the entity sets here, and if they
>     are commented out the schema becomes more usable with xsv. 
> 

As stated it is correct the entity sets are not necessary for 
processing/validation. But from a documentation point of view, having 
them identifies what entity sets that are part of XHTML framework.

>   - Several schema documents refer to attributes in the XML namespace
>     without importing it:  import elements need to be added to
>     xhtml-attribs-1.xsd, xhtml-blkphras-1.xsd, xhtml-bdo-1.xsd,
>     xhtml-script-1.xsd, and xhtml-style-1.xsd.
> 
>     Fixed versions of these files are attached.
> 

This has been already fixed.

Specifically the solution was to import the namespace in the modules
without the schemaLocation attribute. It is the responsibility of the
driver schema to import the namespaces with the correct schemaLocation.

This was to avoid modules importing the same namespace from different
URI's, which most processors typically cannot handle (raise duplicate
definition errors) even if the contents are same. Also such a design
allows the Markup designers to reference the correct version (of the
imported schema).


>   - The schema document xhtml11-module-redefines-1.xsd includes an
>     ambiguous (and therefore non-deterministic) definition of
>     the model group head.content.  When the 'head' element contains
>     a 'title' element before any 'base' element, the definition given
>     makes it impossible to know whether an element in HeadOpts.mix
>     matches the first HeadOpts.mix (before the optional 'base' element)
>     or the second (after it).  An unambiguous form of what we believe
>     to be intended here would be:
> 
>      <xs:group name="head.content">
>        <xs:annotation><xs:documentation>
>            Redefinition by Base module
>          </xs:documentation></xs:annotation>     
>         <xs:sequence>
>            <xs:group ref="HeadOpts.mix" minOccurs="0"
> maxOccurs="unbounded"/>
>            <xs:choice>
>              <xs:sequence>
>                 <xs:element ref="title"/>
>                 <xs:group ref="HeadOpts.mix" minOccurs="0"
> maxOccurs="unbounded"/>
>                 <xs:sequence minOccurs="0">
>                   <xs:element ref="base"/>                
>                   <xs:group ref="HeadOpts.mix" minOccurs="0"
> maxOccurs="unbounded"/>
>                 </xs:sequence>
>              </xs:sequence>
>              <xs:sequence>
>                <xs:element ref="base"/>
>                <xs:group ref="HeadOpts.mix" minOccurs="0"
> maxOccurs="unbounded"/>               
>                <xs:element ref="title"/>
>                <xs:group ref="HeadOpts.mix" minOccurs="0"
> maxOccurs="unbounded"/>           
>              </xs:sequence>           
>            </xs:choice>
>          </xs:sequence>
>       </xs:group>
> 
>     The unambiguous form makes clear, however, that the redefinition
>     of 'head.content' is not a restriction of the 'head.content' in
>     the schema document being redefined: the model in
>     xhtml-struct-1.xsd does not allow any 'base' elements to occur,
>     whereas the model given in the redefinition does.
> 
>     This particular part of the schema seems to need some rethinking.
> 

The ambiguous definition problem has already been fixed.
The above redefinition of component may not work as it is not a valid
restriction.

Received on Wednesday, 21 January 2004 13:22:30 UTC