[Home] [By Thread] [By Date] [Recent Entries]
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@s...] > Sent: 20 November 2009 21:20 > To: xml-dev@l... > 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@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 > > > ____________________________________________________________________ > > > > ______________________________________________________________ > _________ > > 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@l... > subscribe: xml-dev-subscribe@l... 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] |

Cart



