• From: "Christopher Loschen" <closchen@s...>
• To: <xml-dev@l...>
• Date: Fri, 20 Nov 2009 16:20:11 -0500

Thanks again for your help, Ken and Mike. It isn't necessarily what I wanted
to hear, but better to know the truth than to persist in my misunderstanding.

We built our implementation relying on this part of the JAX-RPC 1.1 spec:

***
4.2.5 Simple Types Derived By Restriction

The XML Schema specification allows the definition of new simple types
obtained by restricting an existing simple type. Restrictions on the set of
allowed values are specified using one or more of 12 predefined facets.

A simple type derived by restriction from another simple type, referred to as
its base type, is mapped to the same Java type that its base type is mapped
to. If its base type does not have a standard JAX-RPC mapping (i.e. is
unsupported), then the derived type itself is unsupported.

Several built-in types defined in the XML Schema specification are derived by
restriction from other types for which JAX-RPC provides a standard mapping.
Such types must in consequence be mapped according to the rules in the
preceding paragraphs.

Example
The built-in xsd:normalizedString type is derived by restriction from
xsd:string, hence it must be mapped to java.lang.String.
***

We read that as saying in this case, the custom type derived from xs:dateTime
needed to be mapped to the class that xs:dateTime is mapped to:
java.util.Calendar. However, there is a loss of precision there: the
restriction of the parent type is no longer enforced when you lose the mapping
to the child. I read that as saying the same thing as you're saying that the
custom type is derived from the parent rather than vice versa.

I still wonder if the problem here is in the JAX-RPC spec itself, since that
step is where we're losing the restriction to a custom type. Or do you think
I'm misunderstanding that passage as well?

Thanks again.

Best,
Chris
 

-----Original Message-----
From: G. Ken Holman [mailto:gkholman@C...] 
Sent: Friday, November 20, 2009 1:56 PM
To: xml-dev@l...
Subject: Re:  XSD Schema type derived by restriction problem

At 2009-11-20 13:39 -0500, Christopher Loschen wrote:
>Thanks very much for your reply!
>
>Yes, we do have the xs prefix mapped.

Then I find the error message wording misleading from the processor you are
using:

   " Invalid xsi:type qname: 'xs:dateTime' in element "

... I interpreted to mean that the name was syntactically invalid, not that
the type chosen by that name is invalid in the context given.

I think Mike has already explained the real problem.

When looking for chapter and verse of the W3C specifications, I find xsi:type=
documented in the context of using abstract types in the schema and needing to
specify something derived from an abstract type in the instance using
xsi:type=.  While that isn't your situation, Mike's observation that in your
note you state your type you are overriding is derived itself from dateTime
thus dateTime cannot be a derived type of it seems to hit the mark:

At 2009-11-20 13:10 -0500, Christopher Loschen wrote:
>I'm working with a schema that defines a type by restricting the simple 
>dateTime type.
>...
>we specify that this element is of xsi:type="xs:dateTime" (that is, the 
>parent type).

. . . . . . . . . . Ken


____________________________________________________________________
   

• Follow-Ups:
  • RE: XSD Schema type derived by restriction problem
    • From: "Michael Kay" <mike@s...>