Hi Frank, Blaise,
The idea of using default value in the definition of the
behavior is very good. It maintains the difference between Int (default default
value 0) and IntObject (default default value null) without bringing up
instanceClass, finessing the language specific stuff nicely. And
when the property definition gives another default value, then only xs:nillable
properties can really be set to null, since otherwise we would change from null
to default if there’s a round trip to XML.
Now I’m a little worried about the definition of nullable
in section 4.5.5. This little box we are editing is the only
thing that says how anything about setting property.isNullable, tho of course
the attribute can also be set over the API. As Frank points out, section
4.5.5 currently says that setting non-nullable properties to null results in
undefined behavior, in other words, we are saying it is a bad practice. Presumably,
the proper way to accomplish something similar would be to call unset. The
nice part of this rule is that the mapping between SDO and XML is clear:
set to null means present in XML with xsi:nil=”true”, whereas unset
means absent from the XML. At least in our implementation, if a property
is not nillable then setting it to null is the same as unsetting it. Because
for most java programmers, and certainly for anyone using static SDOs , calling
unset is pretty unnatural. The spec specifically allows our behavior, so I
don’t really have a problem. In 2119 terms, we have a MAY throw an
exception or MAY do an unset. I’m wondering if we want to get rid
of one of the MAYs, and replace the other with a MUST. That is, does
anyone throw an exception in this case, or do we all do an unset?
I feel pretty strongly that we have to say something about the
type of properties with xs:nillable=”true”. Metadata is one
of SDO’s selling point, and saying that the only thing users can know
about a nullable property is that it’s nullable seems hard. Perhaps
a middle ground is to say that standard types (like Int) MUST be changed to the
corresponding Object types (like IntObject), since this is the 2.1.1 behavior,
and anyway, we don’t lose any information by doing it. But that
User-Defined Types (like MySimpleType, below) do not change. This is
clearly something that’s broken in 2.1.1, so I can’t believe there
will be any compability issues.
Best Regards,
Ron
Von: Frank Budinsky [mailto:frankb@ca.ibm.com]
Gesendet: Freitag, 20. August 2010 16:44
An: Barack, Ron
Cc: sdo@lists.oasis-open.org
Betreff: Re: [sdo] ISSUE 99: Error in allocating SDO Type for elements with
nillable=true
Hi Ron,
First, for the second sentence I think it would need to be:
A (Java) Implementation of SDO MUST return NULL as the property
value for nillable properties having the xsi:nil=true attribute (and no other attributes), regardless of
whether the instanceClass
of the SDO type corresponding to the type used in the schema normally supports null values.
Even then, I wonder what this
is really needed for. Why is it so important to dwell on the
type/instanceClass? I think the spec is absolutely clear when a null value can
be expected, and it has nothing to do with the type and whether or not the type
is assignable from Object.class.
Setting the value of a property to null may or
may not be allowed for a given property.
For example, a property that does not map to a
nillable XML element or that maps to a
non-nullable RDB column, cannot be set to null.
A property that can be set to null is
called a nullable property.
Calling get() on a property that is not nullable
may still return a null value, if the default
value of the property is null and it is
currently unset. Calling set(null) on a non-nullable
property will produce implementation dependent
results. It may throw an exception or,
alternatively, it may cause the property to
become unset.
From this very clear text, I'd say this is the test for expectedNull:
Boolean
expectNull = pMstNillable.isNullable() || pMstNillable.getDefault() == null);
Notice that it has nothing to do with pMstNillable.getType(). In fact, the test
that you provided:
Boolean expectNull
= pMstNillable.getType().getInstanceClass().isAssignableFrom(Object.class);
is actually incorrect, according to the spec. It would incorrectly return true
for a property that is not nullable and its default value is something other
than null.
Your suggestion to change the spec to this;
Property name=[NAME]
type=[TYPE]
nullable=true
would break implementations that have two SDO types corresponding to the simple
primitive types (e.g., XXX and XXXObject), and switch to the Object version in
the nillable case. Personally, I think that's a bad legacy approach which was
devised before we had the concept of Nullable, but changing it would be a
breaking spec change.
Maybe the answer is simply to remove the (what I consider to be)
confusing/ambiguous text but otherwise leave the table alone --- i.e., simply
show that nillable maps to nullable:
Property name=[NAME]
nullable=true
Thanks,
Frank.
"Barack, Ron" ---08/20/2010 06:51:13 AM---Hi
Frank, I think you understand what I was proposing.
From:
|
"Barack, Ron"
<ron.barack@sap.com>
|
To:
|
Frank Budinsky/Toronto/IBM@IBMCA,
"sdo@lists.oasis-open.org" <sdo@lists.oasis-open.org>
|
Date:
|
08/20/2010 06:51 AM
|
Subject:
|
[sdo] ISSUE 99: Error in allocating SDO Type
for elements with nillable=true
|
Hi Frank,
I think you
understand what I was proposing.
Let’s look
at the text as it currently stands
If
the type of the element has Simple Content without attributes, a Java Type with
an Object instance class is assigned. For example, IntObject instead of Int.
In an XML document,
xsi:nil="true" corresponds to a null value for this property.
I think we agree
that the second sentence means:
A (Java) Implementation of SDO MUST return NULL as the property
value for nillable properties having the xsi:nil=true attribute, regardless of
whether the type used in the schema normally supports null values.
The disagreement
is about the first sentence. I think you are correct is assuming “Java
Type” should be “SDO Type”. I don’t believe that this
mistake is so big that we can ignore the sentence entirely. And the example
makes it perfectly clear that that the type of the property should have an
instanceClass of IntObject and not int. Also, in the area above the text, where
the translation of the XML is given, the Property’s definition does not
contain a “type=[TYPE] like the other boxes do. The text is clearly
trying to explain how the property’s type should be calculated. Given
that, I would consider an implementation that says
pMstNillable.getType()==MySimpleType to be broken *according to 2.1.1*.
At least in my opinion. But let’s consider how things should be in 3.0
First of all, I
think the behavior you want do define shouldn’t be defined in the chapter
on the SDO-XSD mapping, but rather in the section (4.5.5) on Nullable
properties…the user has no standard way of seeing if xs:nillable is true
in the schema, but can easily check Property.isNullable(). The main use-case
(that I can think of) where this would be relevant is where the user is
inspecting the metadata, to determine if a null value is possible. Currently,
this determination can be made based on Property.getType().getInstanceClass()
alone, eg,
Boolean
expectNull =
pMstNillable.getType().getInstanceClass().isAssignableFrom(Object.class);
I think you want
to change this so that the user needs to check not only the instanceClass, but
also Propery.isNullable():
Boolean
expectNull =
pMstNillable.getType().getInstanceClass().isAssignableFrom(Object.class) ||
pMstNillable.isNullable();
I think this
makes both Tuscany and your new implementation legal. I also think this is
technically OK, even sensible, but I’m worried that it is this a breaking
change. If every agrees that this should be the behavior, then I don’t
think it will be hard to come up with appropriate wording in 4.5.5, and in the
corresponding Java section. Then, the XSD-SDO mapping that we started with
becomes simply
Property name=[NAME]
type=[TYPE]
nullable=true
without any text
at all!
Have I correctly
summarized the behavior you want to define? Like I said before, I need to think
about whether this is a breaking change or not. Blaise, what do you think?
Have a nice
weekend,
Ron
Von: Frank Budinsky [mailto:frankb@ca.ibm.com]
Gesendet: Freitag, 20. August 2010 00:03
An: sdo@lists.oasis-open.org
Betreff: RE: AW: AW: [sdo] AW: ISSUE 99: Error in allocating SDO Type for
elements with nillable=true
Hi Ron,
Sorry, I did mean for my previous reply to go to the list.
In Tuscany we created an "Object" version of every user defined
simple type which had a base class with a primitive instanceClass (just in case
it's ever used with a nillable property). We would generate two SDO types from
the XSD type: MySimpleType (instanceClass int) and MySimpleTypeObject
(instanceClass Integer). Notice that's exactly the same pattern that was used
with the built-in types (e.g., Int and IntObject). This is no coincidence,
since a predecessor version of Tuscany was the primary implementation with
which the SDO 1 specification was defined.
I think something like this is essentially what you're proposing (only not
naming the Object version XXXObject, but rather making the Object types
anonymous.
In another newer SDO implementation, we've handled this the way I've proposed
below, simply by using the type itself, but allowing null to be returned as an
"extended value", because the property is nillable. Because of the
ambiguity in the spec, we concluded that this is really not noncompliant with
the spec. IMO, the spec is only saying that the returned value's Java Type must
be an Object type. Since get(primitiveTypeProperty) always returns the
corresponding Object type anyway (e.g., Integer, since it can't return int)
we're OK to also return null. Like I said in my earlier reply, the distinction
between primitive and Object values really only comes into play in static SDO.
This approach seems to be simpler than the Tuscany approach and works quite
reasonably as far as I can tell. Can you explain an example of where this
approach would really cause a problem?
That said, your point that I am saying the spec is currently ambiguous/broken
but I'd like to leave it that way, is a good one. I'm certainly being a little
irresponsible. However, if we do fix this in a way that will make the approach
I've described noncompliant, I'd want to be convinced that there is really
something wrong with our approach (i.e., it is really broken/bad) because if we
change it, we would be in a position where our implementation will not be
backward compatible if we want to be SDO 3 compliant. I rather not be in a
position where backwards compatibility becomes an obstacle for moving to our
implementation to SDO 3, if we can avoid it.
Thanks,
Frank.
"Barack, Ron" ---08/19/2010
05:09:26 PM---Hi Frank, You sent this to me, did you mean to send it to the SDO
list?
From:
|
"Barack, Ron" <ron.barack@sap.com>
|
To:
|
Frank Budinsky/Toronto/IBM@IBMCA
|
Date:
|
08/19/2010 05:09 PM
|
Subject:
|
RE: AW: AW: [sdo] AW: ISSUE 99: Error in allocating SDO Type for elements
with nillable=true
|
Hi Frank,
You sent this to me, did you mean to send it to the SDO list?
An old fashioned argument, just like the good old 2.1 days!
My opinion is that the spec is clear on the point that
pMstNillable.getType().getInstanceClass() is (MUST BE) the instanceClass of
IntObject. And, today at least, I think that’s pretty reasonable.
Assuming I’m the one trying to get the spec to 2119 compliant, I’d
probably have to put in a compliance point there. That doesn’t mean I
won’t accept a resolution that loosens up the definition of compliant
behavior, it just means that if we defer this, and you are unhappy with the
defined behavior, we will just wind up discussing the same issue later.
Let’s get it over with now. You even point out that you don’t know
what the statement means, but then you go on to say you think the statement
should be left as it is. Personally, I don’t even know if the statement
belongs in Core or in Java. Let’s work out some wording here that
everyone can be happy with.
I agree with Blaise that we are breaking SDO if we allow a property with
instanceClass int, or deriving from Integer (as opposed to IntObject) to have
null values. I think this use case is important, but not important enough to
warrant such a fundament change to the relationship between data and metadata.
Therefore, it seems pretty clear that pMstNillable.getType() cannot be
MySimpleType. I think the spec should say so. We can maybe then get out of the
issue about saying anything else about the type, leaving implementations free
to use IntObject, an anonymous type, or anything else. I think the xmlType of
the property should be the URI of MySimpleType.
In my reading of the spec, this is just adding the stuff about the XMLType.
Would you go with me so far?
Ron
From:
Frank Budinsky [mailto:frankb@ca.ibm.com]
Sent: Donnerstag, 19. August 2010 16:14
To: Barack, Ron
Subject: Re: AW: AW: [sdo] AW: ISSUE 99: Error in allocating SDO Type for
elements with nillable=true
Hi Ron,
The 2.1.1 spec does not say this:
"the property MUST be created with IntObject"
Mapping a property to IntObject instead of Int is simply an example of how to
handle a nillable property of type xsd:int. All the spec really says about
nillable elements is:
If the type of the element has Simple Content without attributes, a Java Type
with an Object instance class is assigned.
I'm not even sure what a "Java Type" with an Object instance class
means. Notice it doesn't say an "SDO Type" with an Object instance
class. So that's the first ambiguous statement.
Let's assume that it really meant to say "SDO Type", then what is
supposed to happen if the specified type, e.g., MySimpleType, doesn't have an
Object instance class? The spec is very clear that unless sdoj:instanceClass is
specified, the instanceClass of a type is the instanceClass of its base type,
so I'd say you're example is an unsupported (error) case in the spec, since the
type being requested cannot be used with a nillable property, because it's
corresponding Java Type does not have an Object instance class.
On the other hand let's assume that all this means is that somehow, an
implementation should figure out a way to arrange for the "Java Type"
being used for the property, to be one with an Object instance class. With that
reading of the ambiguous statement, all 3 of the our approaches (yours,
Blaise's, and mine) would work.
Since it's been this way since SDO 1, I don't see any urgent need to try to fix
it now. I'm happy to continue to leave the handling of this as implementation
dependent.
Thanks,
Frank
"Barack, Ron" ---08/19/2010
09:11:15 AM---Hi Frank, In this case, deferring doesn't mean leaving things
open, it means to keep the 2.1.1 behav
From:
|
"Barack, Ron" <ron.barack@sap.com>
|
To:
|
Frank Budinsky/Toronto/IBM@IBMCA
|
Cc:
|
"sdo@lists.oasis-open.org" <sdo@lists.oasis-open.org>
|
Date:
|
08/19/2010 09:11 AM
|
Subject:
|
AW: AW: [sdo] AW: ISSUE 99: Error in allocating SDO Type for elements with
nillable=true
|
Hi Frank,
In this case, deferring doesn’t mean leaving things open, it means to
keep the 2.1.1 behavior, i.e., the property MUST be created with IntObject,
get(mstProperty) MUST return an Integer, never an int. And when you generate
XSD from the MyComplexType, the <element> MUST have
type=”xs:Integer”. Are you OK with this behavior, or can we do
better? I agree we should change as little as possible, but I think we can at
least say, starting with the 2.1.1 baseline, that the property should have the
xmlType of MySimpleType, so that at least we do a better job of round tripping
without breaking anything.
It seems a short step to create an anonymous type, which I think would really
be a fix for the issue.
Ron
Von:
Frank Budinsky [mailto:frankb@ca.ibm.com]
Gesendet: Donnerstag, 19. August 2010 14:38
An: Barack, Ron
Cc: sdo@lists.oasis-open.org
Betreff: Re: AW: [sdo] AW: ISSUE 99: Error in allocating SDO Type for
elements with nillable=true
Hi Guys,
I don't think this issue is urgent and, from this note chain, we can conclude
that this is not an issue for which we are close to consensus. I think we
should defer it.
Thanks,
Frank.
"Barack, Ron" ---08/19/2010
06:50:09 AM---Hi Blaise, Frank, Three voices, three opinions is about what I
expected. I think I'll go ahead and
From:
|
"Barack, Ron" <ron.barack@sap.com>
|
To:
|
Frank Budinsky/Toronto/IBM@IBMCA, "sdo@lists.oasis-open.org"
<sdo@lists.oasis-open.org>
|
Date:
|
08/19/2010 06:50 AM
|
Subject:
|
AW: [sdo] AW: ISSUE 99: Error in allocating SDO Type for elements with
nillable=true
|
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