[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: AW: Core Spec Review
|
More comments, continued from yesterday: Section 4.10: I’m don’t think the example really adds anything here, and would
prefer to remove it. I believe the second to last paragraph contains an implicit compliance
point that we need to make explicit. That is, the earlier properties MUST hide
the later ones. This might be a good place to bring up the “xml” SDOPath
scheme, eg, to handle the case where attribute names conflict with element
names. This obviously relates to the duplication of “Name” is section 4.5, about
which both Rick and Bryan have commented. I believe, however, that the duplication,
and requirement to raise an exception is simply an editing mistake I made when
I was applying the resolution about NCNames (SDO-173). We had wordsmithed the
Type.name property, and then said “the same constaints apply to Property.name.
So I simply cut-and-pasted the text, changing “Type” to “Property”. Section 4.11 The term “current state” does not occur in the rest of the
document, why do we spend a chapter describing it. Section 4.3.3 – Title should be “Sequences and DataObjects” Sections 4.4 and 4.5 generally: I believe that these sections
should really be folded into Chapter 5. Section 4.5.4 – Read only Properties: we say that attempts to
set a read-only property “results in an error”. This seems to imply a compliance
point, that I’m relatively certain not everyone wants. Or do we? In any case,
we either need a compliance point or to re-word. Best Regards, Ron Von: Barack, Ron
[mailto:ron.barack@sap.com] Hi Everyone, I’d like to add some changes here: First, I think we should agree on when and whether “Type”,
“Property” should be capitalized. For instance, in the phrase “the type
of a DataObject”, should “type” be capitalized or not? We are also not
consistent in our use of many-valued and multi-valued. Is there a
difference here? Section 2.2 The text is talking about what SDO is trying to achieve, not
laying out any requirements in the 2119 sense. We should change
“Requirements” here to “Goals”. Section 2.2, point 2 talks mostly about generating static SDOs,
which we’ve taken out of the spec. I’d like to re-word it to focus on the
use case for static SDO’s, and about the possibility of deriving metadata from
them. 1.
Support for Static Data API. In cases where metadata is known at development time (for example,
the XML Schema definition or the SQL relational schema is known), SDO supports
the use of interfaces as a means of accessing Data Objects. A static API is
usually easier to program against, since they allow the compiler to check type
safety and the IDE’s to offer code completion. When static data APIs are
used, the dynamic data APIs are still available. In languages such as Java, the
static can also be used to as a source of SDO metadata (see item 6, below). While code-generation rules for
static data APIs are outside the scope of this core SDO specification, it is
the intent that SDO supports code-generated approaches for Data Objects.
Possible source from which static SDOs could be generated include: -
Popular XML schema languages. -
Relational database schemas
with queries known at the time of code generation. -
Web services, when the message
is specified by an XML schema. -
JCA connectors. -
JMS message formats. -
UML models Just before section 4.1 starts, there’s a description of
the get<T> methods. I think this text can be removed, since
the get<T> terminology is better described in section 4.1.3, on type
conversion. The last sentence here is also an implicit compliance point,
which I’d like to take out. Property values in SDO may be any of the
following: ·
Boolean ·
Byte ·
Char ·
Double ·
Float ·
Integer ·
Long ·
Short ·
Bytes ·
DataObject ·
Date ·
String ·
Lists of any of the above Individual language specifications might add
additional types to this list. See section 4.1.3 for details on the type safe
access of property values.. Note that unless
an SDO API explicitly states that null is a legal value for a parameter,
passing null is not allowed. The last sentence in section 4.1 Which SDO APIs are used will vary based on
the needs of the application. For example, if XML is part of an
application, then the XMLHelper is valuable, but otherwise might never be used. Is pretty much obvious, and doesn’t really fit in a section called
“DataObject”. We should either remove it or move it someplace else. Section 4.1.1: Basic. A
DataObject is similar to a class with a set of defined Properties. Section 4.1.3: There’s a section of the 2.1.1 spec that is missing here, and
I’m not sure why. I think maybe the text got lost when applying some
other changes. Here is the missing text: In addition to
these conversions, if a get<T>() method is invoked on a many-valued property, then
if the value is a List of length 1, then the item in the list is returned (possibly after
conversion); if the length is 0, null is returned, except when the instanceClass
of the property is a primitive Java class, as described in section Determining whether a Property is Set. If a set<T> method is invoked on a many-valued property, then
the value is wrapped into a List of length 1 and then this List is set. Note that when
calling the primitive DataObject.set() methods, no automatic conversion is performed. In
this case, type conversion can be explicitly performed by calling DataHelper.convert()
before calling the set() method. For example: dataObject.set(property,
dataHelper.convert(property, value)); I’d like to move the first paragraph tot he next section, which
focuses on multivalued properties. Section 4.1.4: The statement The getList(property) accessor is
especially convenient for many-valued properties. If property.many is true then
set(property, value) and setList(property, value) require that “value” be a
Collection and List respectively, as defined for the implementation language. Doesn’t really say anything except what types Java
expects. I think we should replace this sentence with the missing
paragraph from 4.1.3 (see previous change). … more to come… Ron Von: Rick Barkhouse
[mailto:rick.barkhouse@oracle.com] Hi Ron, -- |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]