RE: [sdo] XML Fidelity issue: xsi:nil with attributes

[Frank Budinsky <frankb@ca.ibm.com>]

Hi James,

Thanks for the quick response. I'm not sure I understand this part:

> When we marshal out then it is a simple matter of checking if the
> property isSet() and isNullable() to know if we need to print out
> xsi:nil="true".

In addition to knowing that the property isSet and isNullable, you need to 
know if the value is nil ... right? The case where the value is acutally 
set to null is easy, but the case that I'm looking for a solution to is 
that the value is an object where only attribute properties are set, while 
the element content should be xsi:nil. I think this may be an XML-only 
concept.

The more I think about this, I'm starting to wonder if this is too 
XML-specific to add to SDO? If we introduce an isNil method, like I 
suggested, that only covers the read case. We would then want to start 
thinking about adding some kind of setNil() method as well, e.g., 
xmlHelper.setNil(myDO, "someProperty", true);

So, I'm starting to wonder if an Option 4 that allows XML users to fall 
back to something like DOM and then just use it to look for the xsi:nil 
attribute, would be a better approach.

For other reasons, I have been thinking about suggesting we add a new 
method to DataObject that allows one to project a DataObject to other 
interfaces:

    <T> T project(Class<T> targetClass);

I had been thinking that such a method could be used to project to a 
Sequence "view" of the DataObject (and we could deprecate the getSequence 
method):

    Sequence sequence = myDO.project(Sequence.class);

or it could be used to project to a static interface (instead of just 
casting - this would allow implementation to use a different instance for 
the static object):

    Company company = myDO.project(Company.class);

and now, I think this could be the way we allow XML users to work with 
advanced XML features:

    Node node = myDO.project(Node.class);

What do others think about this suggestion and this issue in general?

Thanks,
Frank.





"James Hart" <James.Hart@Roguewave.Com> 
06/04/2008 10:57 AM

To
Frank Budinsky/Toronto/IBM@IBMCA, <sdo@lists.oasis-open.org>
cc

Subject
RE: [sdo] XML Fidelity issue: xsi:nil with attributes






Our implementation has custom support for this already.  I'll describe
what we do that seems to work well.

In our SDO implementation on our PropertyImpl we support a isNullable
state which defaults to false. It also contains a isNullable() method
that returns this state.  The state can only be set during construction,
but it defaults to false.  On our Impl's for DataFactory and TypeManager
all of our addProperty* methods have an additional method which includes
a isNullable parameter so it can be told to create a nullable property.

Our XSDHelper when constructing types simply creates the property using
the TypeImpl API for addProperty that also exposes the isNullable
parameter.

When we marshal out then it is a simple matter of checking if the
property isSet() and isNullable() to know if we need to print out
xsi:nil="true".  Otherwise we can print out whatever the default value
is.

I'd like to point out it doesn't matter in this case if the Property is
has a type of DataObject or DataObjectType so it is more generic than
the concept of xml's attributes, we just needed this concept to support
these kind of xml documents.

Saying that I don't think we need a special isNil() method, that would
just be icing ;)

I do think that the concept of data being "nill" or nullable for other
data sets than xml is viable.  For example, a DB has nullable columns
and have defaults vs. columns that have defaults and are not nullable
much in the same fashion of nillable attributes in schema.  So I would
prefer the benefits of making the concept nillable part of SDO's
properties and not something that is only DAS dependant.
 
 I can also say option #2 works well because that is essentially what we
do and it allows us to support these concepts in both our XSDHelper
XMLHelper XMLDas and DBDas.  The biggest drawback is that it increases
the size of the in memory for every single property which is a concern
when having to support very large data sets, but I think that currently
is an issue with all of the state information and could be trivialized
and a responsibility  to solve as an implementation issue and not
something that the spec has to solve.

 Thanks,
   James



-----Original Message-----
From: Frank Budinsky [mailto:frankb@ca.ibm.com] 
Sent: Tuesday, June 03, 2008 7:18 PM
To: sdo@lists.oasis-open.org
Subject: [sdo] XML Fidelity issue: xsi:nil with attributes

Hi Guys,

I'd like to start discussing some of the XML fidelity issues. The first 
one, hopefully easy, is to come up with a way to handle nillable
elements 
with attributes. The problem is described in section 2.7 in this doc:

http://www.oasis-open.org/apps/org/workgroup/sdo/download.php/26722/SDO_
XML_Issues.doc

Here is my first thoughts on possible solutions:

Option 1: Add a helper method (to XMLHelper or maybe DataHelper if we 
think this may not be an XML-only issue) to determine if a value is nil:

boolean isNil(Object value);

This method would return true if value == null or if value is a
DataObject 
with an xsi:nil tag. Users could use it something like this:

if (xmlHelper.isNil(myDO.get("someValue"))) {
    // someValue is nil
}

Option 2: We could have a method that takes a DataObject and a property 
path as arguments to determine if a property is nil without actually 
getting the value:

boolean isNil(DataObject object, String path);

if (xmlHelper.isNil(myDO, "someValue")) {
    // someValue is nil
}

If we go with this approach we would probably want 3 methods:

boolean isNil(DataObject object, String path);
boolean isNil(DataObject object, Property property);
boolean isNil(DataObject object, int index);

Option 3: Add the methods to DataObject:

boolean isNil(String path);
boolean isNil(Property property);
boolean isNil(int index);

if (myDO.isNil("someValue")) {
    // someValue is nil
}

This is nice and clean but would only make sense if we can think of
other 
data domains (other than XML) where the concept of nil (different from 
null) applies.

Please let me know what you guys think about these suggestions, or if
you 
have any other ideas.

Thanks,
Frank.

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in
OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php