Response to your XML Schema Issue LC-170

Dear Murray:

The W3C XML Schema Working Group has spent the last several months
working through the comments received from the public on the last-call
draft of the XML Schema specification.  We thank you for the comments
you made on our specification during our last-call comment period, and
want to make sure you know that all comments received during the
last-call comment period have been recorded in our last-call issues
list (http://www.w3.org/2000/05/12-xmlschema-lcissues).

Among other issues, you raised the point registered as issue LC-170,
which suggests that XML Schema should drop the include facility. 
(This was raised in subsection 4.1. and part of subsection 2.2. of 
your review document [1].  (Your original comments are 
attached at the end of this mail.) 

There were two separate issues raised in your comments. The first part
questions the need for the <include> construct. This is motivated by
the fact that its functionality, in part, may be reproduced by
other generic include mechanisms such as Xinclude and entities.  
The second part asks how one can construct a schema that uses 
definitions and declarations from several namespaces.

The schema spec [2] provides two constructs for combining schema 
documents. One is the <include> consctuct that allows you to 
combine several schema documents of the same target namespace 
(or no target namespace), therby creating a schema with its 
components sharing the same target namespace (Structures 6.2.[2#1]).
The other is the <import> construct that allows you to combine 
several schema documents of different target namespaces together, 
therby creating a schema with its components belonging to several 
target namespaces (Structures 6.2.[2#2]).  Thus, the solution to the 
second part of your questions, namely a schema consisting 
of several namespaces, is provided by the <import> construct.

Now we turn to the first question of the <include> construct.
Although the features of the <include> construct and of XInclude are
quite overlapping, there are some signifincant differences. XInclude
is a generic low level document merging mechanism at the info-set 
level.  Whereas the <include> feature of XML Schema is an 
application-specific document merging mechanism at the schema 
info-set level.  For example, XML Schema's <include> treats the 
'schema-element scoped' schema defaults  (i.e., xxxDefault attributes
in element <schema>) locally to each schema element. Another one 
is the interpretation of attribute values of type QName.  They are 
treated in the included document as QNames in the original context
and the integrity of referencing after inclusion is preserved.  

All these require semantic understanding of XML Schema and can not 
be easily duplicated by some generic inclusion mechanism.  
Furthermore, it has also been suggested that some schema specific new 
features could be integrated later into XML Schema via this <include> 
hook if desired.  From these, one can say that XML Schema's <include> 
mechansim is a cleaner (and more controlled in XML Schema specific ways) 
inclusion mechanism than others that do arbitrary logical or physical 
inclusion by generic means. 

Therefore, the WG has decided to keep the current <include> mechanism. 
I hope the above explanation has clarified the motivation behind the 
current <include> construct.  

It would be helpful to us to know whether you are satisfied with the
decision taken by the WG on this issue, or wish your dissent from the
WG's decision to be recorded for consideration by the Director of
the W3C.

Best regards,
Aki Yoshida
Member W3C XML Schema WG

SAP
---

[1] http://www.doctypes.org/spec/schema-review-1.html
[2] http://www.w3.org/TR/xmlschema-1/
[2#1] http://www.w3.org/TR/xmlschema-1/#compound-schema
[2#2] http://www.w3.org/TR/xmlschema-1/#composition-schemaImport

---  original input from [1]
>4.1 A Schema in Multiple Documents 
>I don't see the need for yet another inclusion mechanism, given XInclude,
>XLink and entities. At very least, XInclude seems to mimic <include>
>sufficiently and without the potential processing order mismatch of XLink
>and entities. Can't we just use XInclude? 
>It also states "nesting is legal only if all the included parts of the
>schema are declared with the same target namespace." In a scenario where I
>was mixing XHTML + XLink + SVG + MathML, how could this suffice? XHTML 2.0,
>SVG and MathML include XLink, and I'm at loss to understand how one could
>mix all four given this restriction. 
>
--- original input from [1]
>2.2 XML schema Abstract Data Model
>
>The NOTE regarding no requirement on schemas sharing a target namespace is a
>bit troubling. One of the difficulties I've had is how XML Schemas are used
>to create schemas containing multiple namespaces, indeed this has been
>pointed out as a "failure" in DTDs, and part of the rationale for the XML
>Schema activity. If at the abstract level schemas may contain multiple
>target namespaces, but in actual XML Representation they may not, how can
>one implement a multiple target namespace representation? If this is
>possible, why doesn't this NOTE refer to how this is accomplished? What am I
>missing here? 
>---

Received on Wednesday, 4 October 2000 12:06:24 UTC