Hi Frank,
SDO’s metamodel is based on XSD, and in XSD it is at least
syntactically possible to specify a default value that does not fit to the
type. But there’s no reason why SDO can’t do better here. I
don’t think it’s such a big can of worms to add a new “defaultValue”
property to Type, and then to say that if the property does not define a
default value, the default value of a property is the default value of the
type. The only thing is we’d need to define a new “sdo:defaultValue”
annotation, so that we can round trip from SDO to XML Schema.
Is there now agreement on which proposal we will go with, and on
how it should be written up? I think the main disadvantage of the proposal is
that it leaks around various corners of the spec. For instance, we now
have to say that when the user tries to define a type with sdo:Integer,
sdo:IntObject will be used instead. This affects both the API and schema.
Are there any volunteers to write it up? Maybe we can split it up, where
one takes the Java spec, and someone else takes the core spec. If splitting
up, I’ll take the Java spec…
Best Regards
Ron
Von: Frank Budinsky
[mailto:frankb@ca.ibm.com]
Gesendet: Donnerstag, 26. August 2010 19:40
An: Barack, Ron
Cc: sdo@lists.oasis-open.org
Betreff: Re: AW: [sdo] Oracle Proposal: SDO 99 - ISSUE 99: Error in
allocating SDO Type for elements with nillable=true
Hi Ron,
I guess you're right that returning null from get(oddProperty) would be a
breaking change.
That said, I think SDO has a fundamental bug if the default default value of a
property (i.e., the default value of a type) is a value that is not in the value
set of the type. For example, I think it would be ridiculous to say that a type
that is defined to be one of the values 1, 2, or 3 has a default value of 0.
It's like saying the default value of boolean is "hello" :-) The spec
refers to default value of null as "no default", so making it null at
least makes sense at the metadata level.
You are right that (current) code that is calling get(the123Prop) would not be
expecting to ever get a value of null, but I think they would be equally
surprised to get a value of 0. They really need to check isSet(), before
calling get(), to ensure that what they get back is meaningful.
This really is a can of worms. This default value problem is really a new
issue, different from the nillable issue.
Frank.
"Barack, Ron" ---08/26/2010 12:44:06 PM---Hi
Guys, I'm missing something here: is having getInteger(oddProperty) return null
breaking change
From:
|
"Barack, Ron"
<ron.barack@sap.com>
|
To:
|
Frank Budinsky/Toronto/IBM@IBMCA, Blaise
Doughan <blaise.doughan@oracle.com>
|
Cc:
|
"sdo@lists.oasis-open.org"
<sdo@lists.oasis-open.org>
|
Date:
|
08/26/2010 12:44 PM
|
Subject:
|
AW: [sdo] Oracle Proposal: SDO 99 - ISSUE 99:
Error in allocating SDO Type for elements with nillable=true
|
Hi Guys,
I’m
missing something here: is having getInteger(oddProperty) return null breaking
change? I mean, you can argue that the default value should be on type rather
than property, but that’s really not the issue here. Current code that
deals with user-defined simple types deriving from xs:integer will not expect
to get nulls.
I don’t
know why “it makes no sense to
force a default value on a restricted type“. It seems rather like you are argueing that SDO is
missing the default default value on (user-defined) types. To my mind, the
concept is already there, but the proposal hangs together much better if this
concept was built out in our metadata. It would be cool to say
“odd” as a default value of 1, wherever it is used. Seems a little
late to be playing with the metamodel, tho. In any case, removing the second
part of the proposal doesn’t do away with the concept of types having a
default default value, or the problem that they may or may not fit. It makes
the situation worse in that it allows null to be the default default values in
cases where we know null does not fit.
Do you guys
agree that the section on schema-SDO mapping is not the place to handle this?
After all, you could get the same conflict through the api, declaring the
property with sdo:integer and then the property with nullable. In fact, right
now, you could even define a nullable property with type sdo:integer: we
don’t say that the property’s types should be automatically
adjusted. I would suggest that in the schema sdo table we have a simple
mapping, but refer the user to section 5.2.2. In this section, we all have to
describe how a conflict between a nullable property and a non-nullable type
(we’d have to somehow define this) is handled. And then, in the Java
spec, we define which SDO types this affects.
Best Regards,
Ron
Von: Frank Budinsky [mailto:frankb@ca.ibm.com]
Gesendet: Donnerstag, 26. August 2010 17:38
An: Blaise Doughan
Cc: sdo@lists.oasis-open.org
Betreff: Re: [sdo] Oracle Proposal: SDO 99 - ISSUE 99: Error in allocating
SDO Type for elements with nillable=true
Good point Blaise. In retrospect, using a
primitive base type is a bad idea, period.
I think I'm warming up to your proposal, but let's just go with Proposal 1
then. Forget about Proposal 2, since it makes no sense to force a default value
on a restricted type, which may or may not even be in the value set of the
type.
Frank.
Blaise Doughan ---08/26/2010 11:18:52
AM---If the base type was SDO Int the default value would still be 0 :).
-Blaise
From:
|
Blaise Doughan <blaise.doughan@oracle.com>
|
To:
|
Frank Budinsky/Toronto/IBM@IBMCA
|
Cc:
|
"sdo@lists.oasis-open.org" <sdo@lists.oasis-open.org>
|
Date:
|
08/26/2010 11:18 AM
|
Subject:
|
Re: [sdo] Oracle Proposal: SDO 99 - ISSUE 99: Error in allocating SDO Type
for elements with nillable=true
|
If the base type was SDO Int the default value would still be 0 :).
-Blaise
Frank Budinsky wrote:
One
other thing with this part:
Proposal 2 -
Set the default default value for properties corresponding to extended
primitive types to the base primitive types default value
What would happen if the base type's default value is not in the value set of
the restricted subtype. For example, a default value of 0 for type OddInt would
be "odd" :-)
Frank.
Frank Budinsky---08/26/2010 10:47:23
AM---Hi Blaise, Your proposal is clean and does work nicely, but it has one
serious
Hi Blaise,
Your proposal is clean and does work nicely, but it has one serious
disadvantage IMO.
From what I've seen, user defined simple types seem to be rarely (almost never)
nillable. The reason, I presume, is because the purpose of the subtype is to
specify a restricted subset of the values allows by the type. It seems to be
uncommon to combine such a restriction of the value set with an extension of
the value set to allow null.
If this is the case, your proposal is penalizing all restricted type users
(i.e., forcing them to work with Object instead of the simpler primitive type)
just to accommodate a very rare use case.
Frank.
Blaise Doughan ---08/26/2010 10:18:20
AM---Hello All, Below is a more detailed description of the Oracle proposal for
SDO 99.
Hello All,
Below is a more detailed description of the Oracle proposal for SDO 99.
Section 7.4.2 of the Core Spec regarding nillable simple elements
"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."
Current Issue - What to do with derived simple types?
If oddInt extends
xsd:int currently
Section 7.3.2 of the Core Spec regarding extended simple types
Simple Type with
name
<simpleType
name=[NAME]>
<restriction base=[BASE]/>
</simpleType>
corresponds to:
Type name=[NAME]
base=[BASE]
dataType=true
uri=[URI]
Meaning that our
"oddInt" type will have the super type of Int. THIS is where I think
the spec is wrong. Instead of extending Int, it should extend IntObject since
this type may be used by a nillable element.
Proposal 1 - Change Section 7.3.2
base="[BASE]"
if base is capable or represented null, other wise the base corresponds to the
corresponding object type
Proposal 2 -
Set the default default value for properties corresponding to extended
primitive types to the base primitive types default value
Consequences
With the above
proposals the impact on the user should be minimal:
·
The user would see a different super type
on their extended simple type
· Null
would become a valid value on that property, but user would still have to
explicitly set a null value.
Advantages
·
There is only one SDO type that
corresponds to an extended simple type in an XML schema:
·
Useful if you want to regenerate the XML
Schema from the types
· Useful
if you want to have an editor or validator associated with that type
· Having
one type requires less memory than having multiple copies of that type
·
Simpler to implement (logic is restricted
to type definition, and only when an extended simple type is encountered).
· Simpler
to write the description in the specification
-Blaise