[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
RE: [xml-dev] XSD Schema type derived by restriction problem
- From: "Michael Kay" <mike@saxonica.com>
- To: "'Christopher Loschen'" <closchen@stanfordalumni.org>,<xml-dev@lists.xml.org>
- 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: [xml-dev] 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: [xml-dev] 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
>
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]