[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: XSD Schema type derived by restriction problem

• From: "Michael Kay" <mike@saxonica.com>
• To: "'Christopher Loschen'" <closchen@stanfordalumni.org>,<xml-dev@l...>
• Date: Fri, 20 Nov 2009 23:57:30 -0000

I'm afraid I don't know enough about JAX-RPC to comment sensibly. However,
in general the mapping between XSD types and Java types is always going to
be rough-and-ready - there will never be an exact one-to-one correspondence
between the value spaces. So I'm not really sure what your issue is.

Personally, I think it's much better to keep the data within a single type
system if you possibly can (ie "end-to-end XML"): it avoids a lot of
messiness.

Regards,

Michael Kay
http://www.saxonica.com/
http://twitter.com/michaelhkay 


> -----Original Message-----
> From: Christopher Loschen [mailto:closchen@stanfordalumni.org] 
> Sent: 20 November 2009 21:20
> To: xml-dev@lists.xml.org
> Subject: RE:  XSD Schema type derived by restriction problem
> 
> 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@CraneSoftwrights.com]
> Sent: Friday, November 20, 2009 1:56 PM
> To: xml-dev@lists.xml.org
> 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
> 
> 
> ____________________________________________________________________
>    
> 
> 
> ______________________________________________________________
> _________
> 
> XML-DEV is a publicly archived, unmoderated list hosted by 
> OASIS to support XML implementation and development. To 
> minimize spam in the archives, you must subscribe before posting.
> 
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
> subscribe: xml-dev-subscribe@lists.xml.org List archive: 
> http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
> 

• References:
  • RE: XSD Schema type derived by restriction problem
    • From: "Christopher Loschen" <closchen@stanfordalumni.org>