W3C home > Mailing lists > Public > www-ws-desc@w3.org > August 2005

Comments on the Common Schema Structures note

From: Roberto Chinnici <Roberto.Chinnici@Sun.COM>
Date: Mon, 01 Aug 2005 18:00:15 -0700
To: www-ws-desc@w3.org
Message-id: <42EEC59F.9040208@sun.com>

I hope I'm not interrupting everybody's hard-earned vacations.  ;-)

I'd like to forward to the group the following feedback on the
common schema structure note I received from our JAXB team.



Overall, the general direction is quite XML Schema centric.
When there is impedence mismatch between binding XML Schema to a
programming language,  the proposed solution/directions ignore the
mismatch. It would be preferable to provide a recommendation on
how to work around the issue in the short term.

Here are my comments on the document.

 From Section 2.1 Naming Types

The name of a schema type, attribute or element may be any valid XML
non-colonized name including names which may be reserved or not
directly representable in some programming languages, such as
"object", "static", "final", "class", "Customer-Profile", etc.

It is ironic that this note has a goal for an improved user
experience when using data mapping/binding tools and does not issue
a recommendation to not name schema types with names that are commonly
reserved words in programming languages.  Minimally, a *recommendation*
advising against the use of reserve words that occur across  multiple
target programming languages would be helpful if the schema has a
desire to be data binding/mapping friendly.  Otherwise, additional
effort is needed to resolve this issue.

Other naming issues include elements and type definitions being able
to have same name due to 6 distinct symbol scopes in XML Schema.
Workaround would be for schema designer to not use same names for
elements and type definitions. From JAXB 1.0 to JAXB 2.0, this issue
has been reduced significantly since only elements with anonymous
complex type definitions are mapped to a class by default.


 From Section  2.2.1 Extensible Enumerated Type.

An enumeration may made open to extension, possible in a later
version of the schema, by creating a union with its base type.

<xs:simpleType name='KnownCurrency'>
   <xs:restriction base='xs:string'>
     <xs:enumeration value='GBP'/>
     <xs:enumeration value='USD'/>
     <xs:enumeration value='CAD'/>

<xs:simpleType name='Currency'>
   <xs:union memberTypes='tns:Currency xs:string'/>

I believe there is a typo above. The memberTypes "tns:Currency"
should be "tns:KnownCurrency".

Extensible enumerated types recommendation does not bind/map well to
enumerated types defined in existing programming languages. An enum
type is typically a closed, finite set of values that can be efficiently
processed by switch/case statement. Future versions of the enum type can
add new enum constants, but this is not typically achieved via the use
of unions in programming languages.


2.3 Collection

The individual items held in a collection may appear either as XML
element or attribute values.

Comment: Section describes characteristics of various kinds of model
group of elements. Missing statement that attributes are unordered.
Also missing statement that collection is best mapped to all attributes
or all elements. I don't  imagine that a collection should be split
across element and attribute values in a single complex type definition.


2.4 Vectors

Missing  xs:list of a simple type definition.


<xs:simpleType name="xs:USStateList">
     <xs:list itemType="xs:string"/>


2.5  Maps

For a tool to be able to recognise that a repeated item a map, it
needs to be able to identify which of the repeated elements or
attributes represents the unique key.

Incomplete sentence above.  Believe something like the following was

For a tool to be able to recognize that a repeated item /can be
bound to/ a map,  the tool needs to be able to identify which
/ child element or attribute of the repeated item/ represents the
unique key.

Another obvious mapping to map would be using the element names as
the key of a map over xs:all model group.
Received on Tuesday, 2 August 2005 01:00:22 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:54:56 UTC