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: Oracle Proposal: SDO 99 - ISSUE 99: Error in allocating SDO Typefor 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]