OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sdo message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: AW: [sdo] Oracle Proposal: SDO 99 - Volunteers for writing it up?


Hi Everyone,

 

I’m trying to have SDO implementations as the only compliance targets, that means,  we shouldn’t say what the language bindings MUST do.  That means, I would either leave the first point out or reword it.  Why not just leave it out, and reword the new text in the second point as

 

If a language binding's mapping for TYPE is not capable of representing null values, the property type MUST be set to the alternative type, specified in the language specific SDO specification, that is capable of representing null.  For example, in Java IntObject will be used instead of Int.

 

I would also say that we should have a type=[TYPE] line in the right-hand box.  Otherwise, the normal case, where the type does allow null values, would be unspecified.  Qualified by the above statement, I think we can make the statement, now.

 

I don’t think the 4th point really works, it seems to say that all types derived from IntObject have a default default value of “0”, but my understanding was that the value “0” should only be used if the type was defined using schema, and the schema type used as the base type normally maps to a primitive. 

 

OTHER CHANGES TO THE SPEC:

 

Isn’t the java spec wrong when it says, in the beginning of section 6.1 that the DataObject.get(property) method MUST return an instance of the Java type in the right hand column. [JAV06010001]

and then goes on to list primitive types in the right hand column?  As Frank pointed out, get() returns an java.lang.Object.  

 

in the 3rd paragraph of 7.2.1 we give a list of cases where the instance class has to be int.   This needs to be java.lang.Integer.

 

Section 7.3 of the Java spec already gives implementations the right to use either Int or IntObject when generating SDO types from xs:int.  Doesn’t the whole issue go away if we just say that IntObject must be used?  Of course, a lot of code would break around here, but it isn’t really a breaking change, since we a just closing a loophole, and any code relying on one behavior or the other is using implementation specific behavior. 

And of course, the statement conflicts with other statements in the spec, like, for instance, section 7.2.1, as I just said, so I’m not sure if the backwards compatibility argument really holds.

 

In any case, I think we need to say in this something somewhere about the special behavior when defining simple types from XSD. 

 

When generating SDO types from XSD type whose base type corresponds to an SDO type with a primitive instanceClass, a Java implementation MUST use the corresponding wrapper type, as defined in  6.1: SDO Data Types, as the SDO base type. [JAV07030001].  When XSD types that correspond to SDO types a primitive instanceClass are used in other situation, for instance, when defining the type of a element or attribute, a Java Implementation of SDO MAY use either the SDO Type defined in [sdo] or the corresponding wrapper type. [JAV07030002] The choice is made at the discretion of the implementation. The actual Type selected is set in property.type, enabling reflective access to the information.

 

Section 4.5.5 in the core spec, second paragraph, should be

Calling get() on a property that is not nullable might still return a null value if the default value of the property is null and it is currently unset.  Calling unset is the preferred way to return properties to their default value.  Calling set(null) on a non-nullable property will produce implementation dependent results. 

 

OTHER COMMENTS

I’ll go along with it, but I have to say I really don’t like the solution, which seems to be very wide ranging for what most agree is practically a corner case.   

 

Best Regards,

Ron

 

 

Von: Frank Budinsky [mailto:frankb@ca.ibm.com]
Gesendet: Mittwoch, 1. September 2010 21:52
An: Barack,
Ron
Cc: sdo@lists.oasis-open.org
Betreff: Re: [sdo] Oracle Proposal: SDO 99 - Volunteers for writing it up?

 

Here is my attempt at an official proposal:

1) Add the following after the table in section 7.5 of the core spec (around line 2211):


In certain language bindings, the SDO type corresponding to some XSD Simple Types might not be capable of representing null values. For example, in the Java binding, the SDO Type Int (corresponding to xsd:int) is represented by the primitive Java type int.class. For such types, the language binding MUST provide an additional type mapping which is capable of representing null. For example, the Java binding maps xsd:int to SDO Types Int (the defined core mapping) and also IntObject (Java binding only). IntObject is represented by the Java class Integer.class, which can be set to null.



2) Change the table entry for "Element with nillable" in section 7.4.2 of the core spec to this:

Element with nillable

<element name=[NAME]

nillable="true" type=[TYPE]/>

Property name=[NAME]

nullable=true

In an XML document, xsi:nil="true" corresponds to a null value for this property.

If a language binding's mapping for TYPE is not capable of representing null values, the property type MUST be set to an alternative type, which is capable of representing null (see section 7.5) For example, in Java IntObject will be used instead of Int.


3) Add the following after the Simple Type table in section 7.3.2 of the core spec (around line 2167):

If a language binding's mapping for BASE is not capable of representing null values, the base type MUST be set to an alternative type, which is capable of representing null (see section 7.5) For example, in Java IntObject will be used instead of Int.


4) Change the second paragaph of section 2.1.1 of the java spec (around line 74) as follows:


When get(property) is called on an unset single valued property for which the default value is null (there is no default value) and the instanceClass (see section 2.4.1) of the property is a Java object, a Java Implemenation of SDO MUST return null. [JAV02010101] When the instanceClass is a primitive Java type (e.g., int, boolean, float) or the property type is a user defined simple type whose base type is a wrapper type in table 6.1.2 (e.g., IntObject) corresponding to a primitive type (e.g. Int), then a Java Implementation of SDO MUST return the corresponding default value: [JAV02010102]


· “false” if the primitive type is “boolean”
· “0” if the primitive type is “byte”, “char”, double”, “float”, “int”, “short”, “long”


The first 3 changes cover Blaise's proposal #1. Even though it's a breaking change, I would be happy leaving it at that. The 4th change is for Blaise's proposal #2. I think it's not as clean and in fact a little kludgy.

Thanks,
Frank.

Inactive hide details for "Barack, Ron" ---08/27/2010 03:45:03 AM---Hi Frank, SDO's metamodel is based on XSD, and in XSD it is"Barack, Ron" ---08/27/2010 03:45:03 AM---Hi Frank, SDO's metamodel is based on XSD, and in XSD it is at least syntactically possible to speci


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/27/2010 03:45 AM


Subject:


[sdo] Oracle Proposal: SDO 99 - Volunteers for writing it up?





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.


Inactive hide details for "Barack, Ron" ---08/26/2010 12:44:06 PM---Hi Guys, I'm missing something here: is having getInteger(o"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.

Inactive hide details for Blaise Doughan ---08/26/2010 11:18:52 AM---If the base type was SDO Int the default value would stillBlaise 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.


Inactive hide details for Frank Budinsky---08/26/2010 10:47:23 AM---Hi Blaise, Your proposal is clean and does work nicely, butFrank Budinsky---08/26/2010 10:47:23 AM---Hi Blaise, Your proposal is clean and does work nicely, but it has one serious


From:


Frank Budinsky/Toronto/IBM@IBMCA


To:


Blaise Doughan
<blaise.doughan@oracle.com>


Cc:


"sdo@lists.oasis-open.org" <sdo@lists.oasis-open.org>


Date:


08/26/2010 10:47 AM


Subject:


Re: [sdo] Oracle Proposal: SDO 99 - ISSUE 99: Error in allocating SDO Type for elements with nillable=true







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.


Inactive hide details for Blaise Doughan ---08/26/2010 10:18:20 AM---Hello All, Below is a more detailed description of the OraBlaise Doughan ---08/26/2010 10:18:20 AM---Hello All, Below is a more detailed description of the Oracle proposal for SDO 99.


From:


Blaise Doughan
<blaise.doughan@oracle.com>


To:


"sdo@lists.oasis-open.org" <sdo@lists.oasis-open.org>


Date:


08/26/2010 10:18 AM


Subject:


[sdo] Oracle Proposal: SDO 99 - ISSUE 99: Error in allocating SDO Type for elements with nillable=true







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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]