[sdo] [SDO-83]: Clarification of special "value" property and howto avoid name clashes

[Radu Preotiuc-Pietro <radup@bea.com>]

Andy Grove [03/Jan/07 03:21 PM] 
This issue was originally discussed in more detail:




During review of the 2.1 specification, Rogue Wave have identified a
usability issue with getting text content from documents that have no
SDO types or XSD defined.

Take this XML fragment:

<foo>bar</bar>

According to SDO 2.01, foo maps to an open content sequenced DataObject
of type commonj.sdo#DataObject. SDO 2.01 also provided a special "text"
property so the user could access the text content using the following
code:

String text = foo.getString( "text.0" );

SDO 2.1 has dropped the "text" property so now the only way to access
the text content is as follows:

String text = (String) foo.getSequence().getValue(0);

We feel that this is not very intuitive for the end user and we are
considering implementing support for the xpath text function so the user
can use the following syntax:

String text = foo.getString( "text()" );

This has an advantage over the original text property since the name
"text()" cannot conflict with attribute or element names and the syntax
is already familiar for users who have xpath experience.

We will likely implement this in a custom xpath scheme e.g.:

String text = foo.getString( "rwsf:text()" );

However, we feel that this convenience method would benefit the SDO
specification and would like to see this added to 2.1 if possible.



Ron Barack [25/Oct/06 12:11 PM] 
Hi Andy,

This is the reason why implementation should interpret

<foo>bar</foo>

by creating an open-content property with uri=null, name="foo" and
type={commonj.sdo}string. Then do.get("foo") returns the string "bar".
We also have consistent handling for when an "xsi:type" is given, that
is, the above is interpreted exactly like

<foo xsi:type="xsd:string">bar</foo>

which I believe is what users would expect.

The 2.1 spec does allow implementation to also create the property foo
to be a more general type, for instance, a open, mixed type. I always
had in mind that even in this case, the string "bar" would be the value
of the "value" property, exactly how we handle values that have the xsd
type "xsd:anyType". But you're right, the spec currently allows for both
interpretations.

I'm not entirely sure that this is a problem: we allow the implementions
freedom here, and put the onus on the applications, to introspect the
properties. They probably have to do this anyway in UC's where no schema
or metadata is available.

But I think we now have something to discuss in Thursday's call. 


Andy Grove [25/Oct/06 12:56 PM] 
Thanks Ron. I've just read section 9.10 bullet 6 again and I can see
that where an element contains simple text content then we can map the
element to a String property. That simplies text access in most common
use cases.

However, if the element is complex (perhaps has attributes too) then you
mention a special "value" property. This isn't mentioned in section 10.4
so it might be worth adding a reference there as well. I'm concerned
this may have some of the same problems as the original "text" property.
For example, consider this XHTML fragment:

<select name="product">
<option value="1">Toaster</option>
<option value="2">Kettle</option>
</select>

I would expect select.getString( "option.0/value" ) to return "1" but
how would I access the text content other than using the Sequence API?

Thanks.


Ron Barack [25/Oct/06 03:23 PM] 
Hi Andy,

I was referring to the logic for anyType "wrapper" objects, per section
9.9, point 4. I think we definitely need to reference to this part of
the spec here. The idea is that you create a data object with a single
property (in our implementation, it's open content, although that's not
specified). The property has name "value" and whatever type you want to
give it, in our case, string.

The XML you supply causes problems even when we do have an XML schema:
ComplexTypes that extend simple types make the simple content available
as a property named value, regardless of whether or not the complex type
defines another property named "value". So the resulting object will
have two properties, both named "value". One will have XmlElement true,
the other false. I'm actually not sure which of the two properties we
make available over the get("value") but the other will only be
available over get(1). It's all a good reason to use "sdo:name", but
then maybe you don't have control over the XSD.

The problem of handling such cases when no XSD is present is not
described in the algorithm in section 9.9, which we will have to change.
But I think it's appropriate to handle it consistently with how we
handle complexTypes that extends simpleTypes, as described above. That
is, with 2 properties both named "value". Or do you think that would be
to confusing?



Andy Grove [02/Nov/06 09:43 AM] 
I wasn't on last weeks call when this issue was discussed but as I
understand it there are a few possible solutions:

1. Allow a type conversion from DataObject to String e.g. in the above
example select.getString( "option.0/value" ) would return the attribute
value and select.getString( "option.0" ) would return the text content
of the element.

2. Use the open content "value" property. Can this be put in a special
namespace e.g. commonj.sdo/xml to avoid the conflict with the "value"
attribute? This is in conflict with section 3.6 of the Java spec. which
states that the Property name must be unique amongst all properties on
the DataObject and it is not clear which property
do.getProperty( "value" ) would return. Do we need to provide a new
version of getProperty() that takes a URI and a name?

3. If there is a clash with a "value" attribute or element then the user
will just have to use the Sequence API to get the text.

I think we have already identified some spec updates:

Section 9.9 should be updated to cover the case where no XSD is present
Section 10.4 should mention the special "value" property and special
"wrapper" objects (section 9.9, point 4)


Ron Barack [02/Nov/06 10:58 AM] 
Regarding option 2: the problem with the value property is that we need
to know what xsi:type the user gave the content: the simple conent is
not always a string, it can be a URI, an int, whatever. We have to make
this information available to the clients using the API. The only way to
make this information available AFAIK is through property.getType().

This means that we can't use a global property for the value property:
what Type would we give the value of the property? Therefore, I think
option 2 is not implementable: In the schema-less case, we need to stick
with open content in namespace null.

I need to correct some incorrect info I gave in an earlier comment: when
you have an XSD defining a complex type with simple content, that is,
extending a simple type, the spec says the SDO equivalent is a Type (may
be open or closed) that declares the property "value", where the type of
"value" is the type of the simple content. That means, taking the XSD
implied by the XML you give above, we have a Type with two declared
properties, both named "value". One's a element, the other's a value. 


Frank Budinsky [09/Nov/06 10:58 PM] 
In today's call we decided to resolve SDO-144 by deferring to SDO 3 the
possibility of adding automatic Object <--> DataObject conversion
support. To resolve this issue, however, I believe we need to at least
allow an implementation to provide this conversion if it wants to, so I
added the following in section 3.1.3:

"An SDO implementation may, but is not required to, support conversion
between DataObject and DataType values. For example, getDataObject() on
String-type property may return a wrapper DataObject for the string
value, and getString() on a DataObject property may do the reverse. The
exact behavior of this conversion, if supported, is implementation
dependent."

Regarding the behavior of wrapper objects and "value" properties, I am
not in favor of adding any additional clarification at this point,
because I believe their are too many subtleties. Please open an SDO 3
JIRA for specific clarifications we need to consider in 3.0.




Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.