[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: AW: [sdo] Issue 118 - Proposal for review
I agree with you Ron. I was only answering Blaise's questions to help him
understand how an implementation (presumably Oracle's) "might" implement
type-specific wrappers. Our (IBM's) implementation is also not using
type-specific wrapper classes and as I said in my last reply to Blaise,
the user shouldn't need to know or care about the type of the actual
wrapper class or classes. All that matters, as far as the spec is
concerned, is that this works:
DataObject intWrapperDO = dataFactory.create("commonj.sdo", "Int");
intWrapperDO.setInt("value", 7);
xmlHelper.save(intWrapperDO, "urn:example", "root", System.out);
The implementation, knowing it's a wapper, would serialize it correctly:
<root xmlns="urn:example">7</root>
The rest is implementation-dependent.
Frank.
"Barack, Ron" <ron.barack@sap.com>
09/08/2008 05:02 PM
To
"Blaise Doughan" <blaise.doughan@oracle.com>, <sdo@lists.oasis-open.org>
cc
Subject
AW: [sdo] Issue 118 - Proposal for review
Hi Everyone,
Sorry, when writing the agenda I somehow oversaw Frank's email describing
his proposal.
I'm a little confused by the notion of the XSD generation of wrapper
types, and by the creation of wrapper types through the API, as in the
code samples below. This is *much* more detailed that the original
propsal.
We were thinking of implementing this with a single Wrapper type, and
creating "value" properties... having the infrastructure create an
arbitrary number of wrapper types (one for each simple type in SDO, and
one for each simple type in the user's context) just sound like a mess to
me. Other implementations might decide differently. I liked the original
proposal, as it allowed for both approaches. In both approaches
Wrapper.isInstance(someObject) returns the same value. And
someObject.get("value") returns the simple value. I don't see a use case
for creating wrapper types in a portable way through an API. And I sure
don't see a use-case for generating XSD that includes wrapper types. Are
these directions where others want to go?
Best Regards,
Ron
________________________________
Von: Blaise Doughan [mailto:blaise.doughan@oracle.com]
Gesendet: Mo 08.09.2008 21:28
An: sdo@lists.oasis-open.org
Betreff: Re: [sdo] Issue 118 - Proposal for review
Hi Frank,
In order to support the proposed solution for SDO-118, we (Oracle) would
also require wording in the spec that indicates the XSD generation from
wrapper types is special, and is not required to look like the following:
<xsd:complexType name="VendorIntWrapper">
<xsd:complexContent>
<xsd:extension base="sdo:DataTypeWrapper">
<xsd:sequence>
<xsd:element name="value" type="xsd:int"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
-Blaise
Frank Budinsky wrote:
> Hi Blaise,
>
> Yes, that's right. Wrapper types are really implementation dependent and
> special. An XML serializer needs to provide special handling for wrapper
> types.
>
> Also, user's shouldn't be working with wrapper types directly anyway.
The
> user would do this instead:
>
> DataObject intWrapperDO = dataFactory.create("commonj.sdo", "Int");
> intWrapperDO.setInt("value", 7);
> xmlHelper.save(intWrapperDO, "urn:example", "root", System.out);
>
> The implementation, knowing it's a wapper, would serialize it correctly:
>
> <root xmlns="urn:example">7</root>
>
> Frank.
>
>
>
>
> Blaise Doughan <blaise.doughan@oracle.com>
> 09/08/2008 01:50 PM
>
> To
> sdo@lists.oasis-open.org
> cc
>
> Subject
> Re: [sdo] Issue 118 - Proposal for review
>
>
>
>
>
>
> Hi Frank,
>
> That schema fragment does not match my expectations for wrapper types.
>
> For the following code fragment:
> DataObject intWrapperDO = dataFactory.create("vendor.package",
> "VendorIntWrapper");
> intWrapperDO.setInt(7);
> xmlHelper.save(intWrapperDO, "urn:example", "root", System.out);
>
> I would expect the above to return:
> <root xmlns="urn:example">7</root>
>
> And not:
> <root xmlns="urn:example">
> <value>7</value>
> </root>
>
> -Blaise
>
>
> Frank Budinsky wrote:
> VendorIntWrapper is implementation specific, so I can't say exactly what
> it looks like. It could look something like this:
>
> <xsd:complexType name="VendorIntWrapper">
> <xsd:complexContent>
> <xsd:extension base="sdo:DataTypeWrapper">
> <xsd:sequence>
> <xsd:element name="value" type="xsd:int"/>
> </xsd:sequence>
> </xsd:extension>
> </xsd:complexContent>
> </xsd:complexType>
>
> Frank.
>
>
>
>
>
> Blaise Doughan <blaise.doughan@oracle.com>
> 09/08/2008 11:01 AM
>
> To
> sdo@lists.oasis-open.org
> cc
>
> Subject
> Re: [sdo] Issue 118 - Proposal for review
>
>
>
>
>
>
> Hi Frank,
>
> Can you provide the expected schema resulting from the following call
> (assuming VendorIntWrapper extends DataTypeWrapper):
>
> list.add(typeHelper.getType("commonj.sdo", "DataTypeWrapper"));
> list.add(typeHelper.getType("vendor.package", "VendorIntWrapper"));
> xsdHelper.define(list);
>
> -Blaise
>
>
> Frank Budinsky wrote:
> Here is the proposal that that we discussed in today's TC call:
>
> 1. Add the following abstract type to sdoModel.xsd:
>
> <xsd:complexType name="DataTypeWrapper" abstract="true"/>
>
> 2. Users can use this type to determine when a DataObject is a wrapper:
>
> DataObject someObject = ...
> Type dataTypeWrapperType = typeHelper.getType("commonj.sdo",
> "DataTypeWrapper");
> if (dataTypeWrapperType.isInstance(someObject)) ... // "someObject" is
a
>
>
> wrapper
>
> The actual type of a wrapper object is implementation dependent, but it
> will always extend from {commonj.sdo}DataTypeWrapper.
>
> Wrapper types are the special implementation-dependant types used to
hold
> a simpleType value for an XMLDocument rootObject or for the value of an
> anyType property. Formally defined complexTypes that extend simpleType
are
>
>
> not considered wrapper types (i.e., they will not extend
DataTypeWrapper),
>
>
> even though they also have a "value" property.
>
> Frank.
>
>
>
>
> Frank Budinsky/Toronto/IBM@IBMCA
> 08/20/2008 03:51 PM
>
> To
> sdo@lists.oasis-open.org
> cc
>
> Subject
> Re: Fw: [sdo] Issue 118 - Creating wrapper objects for simple types
>
>
>
>
>
>
> Hi Blaise,
>
> The two cases that I remember were:
>
> 1) reading an anyType property, which maps to sdo:DataObject, but it may
> be just a DataType value.
> 2) the root element of an XMLDocument, which is always returned as a
> DataObject, even if the actual document simply had a simple DataType at
> the root.
>
> Frank.
>
>
>
>
> Blaise Doughan <blaise.doughan@oracle.com>
> 08/20/2008 03:24 PM
>
> To
> sdo@lists.oasis-open.org
> cc
>
> Subject
> Re: Fw: [sdo] Issue 118 - Creating wrapper objects for simple types
>
>
>
>
>
>
> Hi Frank,
>
> For what use case does the user need to know if the type is a data type
> wrapper?
>
> -Blaise
>
> Frank Budinsky wrote:
>
> Unless somebody can think of a better approach, I'd like to suggest that
>
>
>
>
> we also vote on this in next weeks call.
>
> Thanks,
> Frank
>
> ----- Forwarded by Frank Budinsky/Toronto/IBM on 08/20/2008 03:15 PM
>
> -----
>
> Frank Budinsky/Toronto/IBM
> 08/18/2008 05:19 PM
>
> To
> sdo@lists.oasis-open.org
> cc
>
> Subject
> [sdo] Issue 118 - Creating wrapper objects for simple types
>
>
>
>
>
> If I'm not mistaken, SDO 118 has already been resolved in JSR235. We've
> agreed that DataFactory.create(someSimpleType) must return a wrapper.
>
> What's still missing, is a way for clients to know if a type is a
>
> wrapper.
>
> Proposal: Type.isDataTypeWrapper(). This would return true for any type
> that has the special "value" property (including formally defined types
>
> in
>
> an XSD).
>
> Please let me know if you have any comments or better alternatives?
>
> Thanks,
> Frank.
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail. Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail. Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail. Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail. Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail. Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail. Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]