Input from Digitect B.V. Netherlands to the W3C XML Schema version 1.1 Development

L.S.,

In our professional practice we make use of the W3C XML Schema standard on 
a daily basis. Our approach focusses on specifying the functinality of an 
electronic interface first (using UML modelling techniques) and then 
deriving the technical specifications (in either XML, flat file or Edifact 
standard) from it.

We have implemented this approach in our Message Development Tool, named 
EC-Design, which has been used extensively for over ten years to create 
consistent sets of EDI messages. In the last two years we have added 
functionality to generate W3C XML Schema's from our functional 
specifications and have used this functionality extensively in our 
consulting practice.

During this proces, we have come across the following questions/remarks 
with regard to the W3C XML Schema version 1.0. So, we are now happy that we 
can put these questions/remarks into the XML Schema version 1.1 development 
proces.

1.    Support for codelists
When modelling the data requirements for electronic messages, it is 
possible to specify that a datatype has several codelists.  It is possible 
that different codelists related to the same datatype, contain equal codes 
with different meanings.  The technical standard used to exchange these 
message should therefore support this.  Normally this is done by 
identifying a codelist with a codelist identification that has been 
assigned to it by a controlling agency.  If the codes in a message instance 
are exchanged including the codelist identification and the controling 
agency identification it is clear for the receiving application which code 
it is and which meaning it has (you have a clear and unique reference to a 
code in a codelist).

As far as we know, this is not supported in the current version of W3C Schema.

2.    Support for codelist subsets
It seems to be good practice to split a Schema specification into a part 
containing all type definitions and a part containing the hierarchical 
structure definition of an electronic message.  The part containing the 
hierarchical structure definition refers to the Type definitions from the 
other part.  In this way of course you can reuse typedefinitions many times.
For instance when a type is defined with one or multiple codelists attached 
to it, different elements may refer to this type in their definition. But 
for each different element using this type, you actually want to state a 
subset of codes from the codelist which are applicable for this element, 
without needing to redefine the type completely or needing to introduce a 
separate new type. In this way different elements make use of one type 
definition, but within this type definition make use of different code subsets.

3.    Use of 'restriction' suggests subsetting a previously defined type, 
but actually implies completely redefining a type.
We feel a need for truely subsetting a type definition.

4.    The use of simpleType and complexType in combination with 
simpleContent and complexContent is unclear (to us)
 From the XML Schema specification we understand that simpleContent is used 
when the base type is a simpleType, and complexContent is used when the 
base type is a complexType. However it is also stated that a simpleType may 
only contain a value, where a complexType may contain attributes and 
elements. So we wonder, does this mean that when we for example define a 
complexType 'TpMessageType' by extending a simpleType 'xsd:string' with 
attributes, should it then look like this?

  <xsd:complexType name="TpMessageType">
   <xsd:simpleContent>
    <xsd:extension base="xsd:string">
     <xsd:attribute name="crCodeAgency" type="cdt:CodeAgency"/>
     <xsd:attribute name="crDomain" type="cdt:Domain" use="required"/>
     <xsd:attribute name="crCodeList" type="cdt:CodeList" use="required"/>
     <xsd:attribute name="crLanguage" type="cdt:Language" use="optional"/>
     <xsd:attribute name="crCodeValue" type="cdt:CodeValue" use="required"/>
    </xsd:extension>
   </xsd:simpleContent>
  </xsd:complexType>

or should it be <xsd:complexContent> in this example?

5.    Status of an element should be defined independently of 
minOccurs/maxOccurs
Currently the way to specify an optional element is by stating that the 
minOccurs for this element is 0. We believe that the status of an element 
(optional, required, dependent) should be expressed independently from 
minOccurs and maxOccurs, thus making it possible to define an optional 
element which has (when it does occur) a minOccurs of 3 (appears at least 3 
times). Also it makes it possible to identify dependent elements (which are 
dependent of a certain rule). Note that this also asks for another 
enhancement of XML Schema: to specify dependencies (rules) between 
elements/attributes defined in the schema.

6.   Does totalDigits specify the number of digits inclusive or exclusive 
the decimal separator and/or the sign (positive/negative)?
We feel from the specs that totalDigits specifies the number of digits 
exclusive the decimal separator and/or the sign, but we are not sure about 
this.
What if the 'fixed' attribute is set to true for totalDigits? Does this 
mean that leading or trailing zero's are accepted?


Finally a question: is it possible to get a link to the EC-Design message 
development tool on the W3C site in the tools section?
<http://www.ec-design.nl>www.ec-design.nl
Develop and design a completely consistent set of functional messages for 
application integration from a purely functional point of view based on a 
single relational datamodel. Derive 100% correct W3C XML Schema's from 
functional messages without any knowledge of XML or XML Schema. Map to 
other technical exchange standards: Edifact and inhouse/flatfile. Generate 
initialisation and configuration files for operational translator software.


Kind regards, and looking forward to your reaction,

Digitect  B.V.
Frans van Basten, Paul Vriend

mail: 
<mailto:Frans.van.Basten@digitect.nl>Frans.van.Basten@digitect.nl 
<mailto:Paul.Vriend@digitect.nl>Paul.Vriend@digitect.nl
www: <http://www.digitect.nl>www.digitect.nl    www.ec-design.nl
-----------------



XML Schema 1.1
You can help

The XML Schema WG is currently working to develop a set of requirements for 
XML Schema 1.1, which is intended to be mostly compatible with XML Schema 
1.0 and to have approximately the same scope, but also to fix bugs and make 
whatever improvements we can, consistent with the constraints on scope and 
compatibility.

If you have suggestions for specific requirements for XML Schema 1.1 (or 
for later versions), please send us mail using the 
<mailto:www-xml-schema-comments@w3.org>public comment list. Please note 
that the comments list is not only public-write but also public-read; don't 
say things you don't want seen in public.

Thanks!