Hi Blaise, Frank,
Three voices, three opinions is about what I expected. I
think I’ll go ahead and add a fourth. First, some comments on your
ideas:
@Blaise: I think the solution of making the instanceClass
of all derived types Object types is certainly technically sound. My
guess is that we are all storing values in Objects anyway. But I’m
concerned about backwards compatibility. And I don’t think this is
what users will expect.
@Frank: I think the difference in our perspectives boils
down to the fact that I think it’s a problem for the instanceClass of a
property to be different from the instanceClass of that property’s
type. Property’s don’t have instanceClasses, Type’s
do. It’s a pretty big change to suggest otherwise. Even
if the static SDO issue falls away because we don’t generate the
interfaces ourselves, there are certainly may other places where we assume that
a property’s instanceClass is exactly what you’d expect from
inspecting the type.
So, now on to another idea:
If we assume that for most applications, the correct
representation of the DATA is more important than correct representation of the
METADATA, then it is more important that get(pMstNillable) return null than it
is that pMstNillable==pMst. If we want everything to be consistent , then
that means that pMstNillable has to be or derive from IntObject. In
order to round trip our metadata, we can add in that the xmlType of the
property should be MySimpleType.
The spec currently says that pMstNillable.getType==MySimpleType.
I think the only real problem with this is that we lose the facets or
other metadata that is associated with the type. I think one possible
solution to this would be to define an anonymous type that copies everything
from MySimpleType other than its name and instanceClass. What’s
good about this solution is that the nill values are represented AND the property’s
values are consistent with the property’s metadata. And o it does not
lose any metadata, as long as the user gets the type from property.getType and
does not try to look it up over its name (which is already broken in 2.1.1).
Best Regards,
Ron
Von: Frank Budinsky
[mailto:frankb@ca.ibm.com]
Gesendet: Mittwoch, 18. August 2010 22:54
An: sdo@lists.oasis-open.org
Betreff: Re: [sdo] AW: ISSUE 99: Error in allocating SDO Type for
elements with nillable=true
I think MySimpleType having instanceClass
int.class is fine. We just need to say that the instanceClass of a nillable
property which is of a type that has a Java primitive instanceClass (e.g.,
int.class) will effectively be promoted to the Object version of the type's
instanceClass (e.g., Integer.class) since null is also a valid value for the
property. Effectively, this is just saying that the instnaceClass of a nillable
property may not be exactly the same as the instanceClass of the property's
type. Although the rule to figure it out is trivial, we could add a
Property.getInstanceClass() method that returns it.
The value space of the pMstNillable property is the MySimpleType type's value
space (i.e., MIIN_INTEGER to MAX_INTEGER) :
1.
pMst unset
myObject.get(pMst)
== 0
2.
pMst set to 10
myObject.get(pMst)
== 10
3.
pMst set to nil
myObject.get(pMst)
== 0 (or error since this is invalid data)
The value space of the pMstNillable property is the MySimpleType type's value
space (i.e., MIIN_INTEGER to MAX_INTEGER) plus null (because it's a valid value
for a nullable property).
1.
pMstNillable unset
myObject.get(pMstNillable)
== 0
2.
pMstNillable set to 10
myObject.get(pMstNillabe)
== 10
3.
pMstNillable set to nil
myObject.get(pMstNillable)
== null
Frank.
Blaise Doughan ---08/18/2010 04:11:08 PM---If the instance
class for MySimpleType is *int.class* then I would expect:
myObject.get(Integer.cl
From:
|
Blaise Doughan
<blaise.doughan@oracle.com>
|
To:
|
"sdo@lists.oasis-open.org"
<sdo@lists.oasis-open.org>
|
Date:
|
08/18/2010 04:11 PM
|
Subject:
|
Re: [sdo] AW: ISSUE 99: Error in allocating
SDO Type for elements with nillable=true
|
If the instance class for MySimpleType is int.class
then I would expect: myObject.get(Integer.class, pMstNillable) == 0
If the instance class for MySimpleType is java.lang.Integer.class then I would
expect: myObject.get(Integer.class, pMstNillable) == null
The problem is we don't know what instance class to set on MySimpleType because
we don't know it will be used by a nillable property. We could I guess in this
situation always give these derived simple types the Object version of the
instance class?
-Blaise
Frank Budinsky wrote:
Hi
Ron,
Maybe I'm missing something, but the answers to me are straightforward.
Q1: What is the value of pMstNillable.getType()?
A1-1: pMst.getType(), that is
pMstNillable.getType().getName().equals(“MySimpleType”);
Q2: Assuming “A1-1”, what should myObject.get(pMstNillable) return?
A2-2: null – this gives the detail about nil value, but I think users
will still be surprised, since the value is inconsistent with the
property’s metadata.
Why do you think this is inconsistent with the property's metadata? The
property is "nillable", so a return value of null seems perfectly
reasonable.
Q3: Assuming “A1-1”, what should myObject.get(Integer.class,
pMstNillable) return?
A3-2: null – this is what users would expect. It would mean the
implementation must remember the xsi:nill=”true” in addition to the
integer value.
Remember what integer value? There is no integer value. The value is
"nil". An instance can only have a value or nil, not both.
The only thing I think is special about nillable properties is that they need
to return the Object version of primitive types in static SDO:
public int getMst() { ... }
public Integer getMst_nillable() { ... }
instead of the primitive instanceClass of the type, which won't allow null as a
return value:
public int getMst_nillable() { ... }
Since the DataObject.get() methods always return Object types, there's no
problem with them.
Thanks,
Frank.
"Barack, Ron" ---08/18/2010
09:33:49 AM---Hi Everyone, Based on yesterday's discussion, let me offer an
example as a basis for discussion. Fo
Hi Everyone,
Based on yesterday’s discussion, let me offer an example as a basis for
discussion. For clarity, I’m leaving out all namespace stuff
We start with a schema that defines a simple type:
<xs:simpleType name=”MySimpleType”
base=”xs:integer”>
<xs:minInclusive value=”5”/>
</xs:simpleType>
Let’s assume the schema defining this type is read in and that SDO has
created the type. Sometime later, we read in another schema that uses the type
in an element property… I’m imagining it in a second schema, if the
use is in the same schema, we could potentially decide when defining the type
that it’s instance class should be Integer and not “int”, but
if the usage is in a second schema, then clearly we can no longer modify the
existing type definition. So, let’s imagine a second schema
<xs:element name=”MyDoc” type=”MyComplexType”>
<xs:complexType name=”MyComplexType”>
<xs:sequence>
<xs:element name=”mst” type=”MySimpleType”/>
<xs:element name=”mst_nillable” xs:nillable=”true”
type=”MySimpleType”/>
<xs:element name=”i” type=”xs:integer”/>
<xs:element name=”i_nillable” xs:nillable=”true”
type=”xs:integer”/>
</xs:sequence>
</xs:complexType>
Here’s an instance document:
<MyDoc>
<mst>7</mst>
<mst_nillable xsi:nil=”true”/>
<i>21</i>
<i_nillable xsi:nil=”true”/>
</MyDoc>
Let’s imagine some code using these files:
DataObject myObject = xmlHelper.load(…).getRootObject();
Type complexType = myObject.getType();
Property pMst = complexType.getProperty(“mst”);
Property pMstNillable = complexType.getProperty(“mst_nillable”);
Property pI = complexType.getProperty(“i”);
Property pINillable = complexType.getProperty(“i_nillable”);
So, I guess the first question is:
Q1: What is the value of pMstNillable.getType()?
A1-1: pMst.getType(), that is
pMstNillable.getType().getName().equals(“MySimpleType”);
I think this is what users would expect.
A1-2: sdo:IntObject, that is pINillable.getType().
This is what the spec currently says. But of course, we are losing
information…in this case, the restriction. Not to mention that theres a
round-tripping problem.
I guess A1-1 is preferable, but it creates problems when dealing with nils.
This brings us to our second question:
Q2: Assuming “A1-1”, what should myObject.get(pMstNillable) return?
A2-1: 0 – this would mean ignoring the nillable attribute.
A2-2: null – this gives the detail about nil value, but I think users
will still be surprised, since the value is inconsistent with the
property’s metadata.
A2-3: A wrapper data object, and we could add some means of inspecting it for
“isNull”… this is the pattern we use when dealing with
dataTypes that need to be handled like objects.
Q2: Assuming “A1-1”, what should myObject.get(Integer.class,
pMstNillable) return?
A2-1: Integer.valueOf(0) – this would mean ignoring the nillable
attribute.
A2-2: null – this is what users would expect. It would mean the
implementation must remember the xsi:nill=”true” in addition to the
integer value.
BTW, sorry if there are errors in the schema or java code…this is only
meant to be the basis for discussion, and I think the intent is clear.
My own current thinking is that the first answers to each question is the best
choice. But maybe there are other solutions.
OK… let the discussion begin!
Ron
_____________________________________________
Von: Barack, Ron
Gesendet: Dienstag, 17. August 2010 16:31
An: sdo@lists.oasis-open.org
Betreff:
ISSUE 99: Error in allocating SDO Type for elements with nillable=true
Hi everyone.
The problem description is here: http://www.osoa.org/jira/browse/SDO-99
In the current WD, the problem is in the table in section 7.4.2, in the block
“Element with nillable”. There are a lot of editorial issues with
this text, for instance, the reference to Java types does not really belong in
the core spec. but more substantively: the issue boils down to the problem that
“xsi:nillable” is on properties, but “sdo:nullable” is
on types. If you have a type that is defined as being an unboxed primitive
value, we can’t simply change the type’s definition because
it’s used in a nillable property. (I hope we all agree here).
In my opinion there are 4 possibilities.
1.
We
ignore the xsi:nillable
2. We
use a SDO primitive object type (IntObject), and use the type referenced in the
XSD as the XmlType only.
3. We
use wrapper objects.
4. We
defer the issue
I prefer option 3 and volunteer to write it up, if we get approval for the
approach on today’s call.
Ron