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: RE: [sdo] XML Fidelity issue: xsi:nil with attributes


Hi Guys,

I think something like "system properties" might be a better name than 
"technical properties". XML has 4 intrinsic system/technical properties, 
namely the 4 attributes in the xsi namespace: xsi:type, xsi:nil, 
xsi:schemaLocation, and xsi:noNamespaceSchemaLocation. These 4 are 
built-in attributes that all XML processors allow. I think we need to say 
that those 4 are system properties by default. If users want to define 
additional ones, they can do it with Ron's proposed sdo annotation (but 
note that they can result in invalid XML serializations).

I'm not really crazy about adding a new API for this to SDO. Where would 
getTechnicalProperties() go? DataObject, DataHelper, or somewhere else? I 
wonder if we could require technical/system properties to map to XML 
attributes? If so, maybe we could access them using a solution we might 
come up with for SDO-132?

Frank




"James Hart" <James.Hart@roguewave.com> 
06/19/2008 09:23 AM

To
"Barack, Ron" <ron.barack@sap.com>, Frank Budinsky/Toronto/IBM@IBMCA, 
<sdo@lists.oasis-open.org>
cc

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






I really like this more generalized approach with "Option 2".

It would also be nice if there was an additional API similar to 
getInstanceProperties() that would be PropertyList 
getTechnicalProperties().  In the long run it would even be nicer if there 
becomes a getTechnicalProperties(Namespace) api.  That way a user of the 
technical properties wouldn't have to getProperty(TProp) on everything it 
may know about, but instead get a list, loop through them and see if it 
recognizes any of them.

  One benefit comes if there is a larger overhead in multiple calls to 
getProperty() than a single getTechnicalProperties() call. Another benefit 
is if a DAS may recognize 100 technical properties but likely there will 
only be one or two ever set on any type or data object it will save a 
large amount of time to get a list and check if it recognizes those.

Thanks,
  James

-----Original Message-----
From: Barack, Ron [mailto:ron.barack@sap.com] 
Sent: Thursday, June 19, 2008 4:25 AM
To: Frank Budinsky; sdo@lists.oasis-open.org
Subject: AW: [sdo] XML Fidelity issue: xsi:nil with attributes

Hi,
 
I would like to propose generalizing Option 2 below as follows.  We define 
an open content property
{commonj.sdo}technicalProperty with type "boolean".

When an open content property is annotated with technicalProperty="true", 
then the property may be set on any object, regardless of whether the 
object's type is open or not.  This is the behavior described under 
"Option 2", except now it is not based on a pre-defined set of properties 
hardcoded into SDO, but rather on the "technicalProperty" mechanism.

Technical properties DO NOT appear in an object's instance properties. 
Instance properties are typically business relevant, technical properties 
are not.  Technical properties can only be retrieved or set through the 
DataObject.get(Property) or the DataObject.set(Property, Object) APIs.

We must further define the open content property 
{http://www.w3.org/2001/XMLSchema-instance}nil"; and declare it to have 
technicalProperty="true".

Best Regards,
Ron

-----Ursprüngliche Nachricht-----
Von: Frank Budinsky [mailto:frankb@ca.ibm.com] 
Gesendet: Montag, 16. Juni 2008 21:02
An: sdo@lists.oasis-open.org
Betreff: RE: [sdo] XML Fidelity issue: xsi:nil with attributes

Hi James,

If I understand you, you're suggesting 1) a generic mechanism for adding 
meta information to meta information, and 2) a separate API for accessing 
instances of this meta information.

For 1), I think the instanceProperty support we added to Type and Property 

is mostly what we need (except, I suppose, it's missing a set() API if the 

types are defined with XSD).

For 2), I'm not sure I see the value of adding the complexity of a 
separate API for this. Simply using DataObject.get/set() seems like a very 

clean and simple approach to me.

Frank.




"James Hart" <James.Hart@roguewave.com> 
06/11/2008 10:15 AM

To
"Barack, Ron" <ron.barack@sap.com>, <sdo@lists.oasis-open.org>
cc

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






I like option two, but can we make it more generic?  Could we just have a 
method on Type and Property such as 
set/getMetaProperty<val_type>(property, xmlnamespace, name, value).  This 
would be an instance property but only accessable through this API and 
only should be used for auxiliary information that is critical to the data 

itself.

In this way we could say something like any meta property can be added to 
any kind of property.  By best practice it would only store meta 
information that would only be important to a DAS or a user that expects 
auxiliary information from a DAS. We could even expand that and say that 
certain projects would use these meta data to hold their own custom states 

and this is also how the projections can "share" information with other 
projections. 

So in terms of the nil property now when the XSDHelper reads in an xsd it 
could do:
 Type<bool>.addMetaProperty(nillableElementProperty, xsdnamespace, 
"nillable", true); 

And when the XSDHelper reads in a file where something is set, when it is 
creating the DataObject it could do something like:
DataObject.<bool>setMetaProperty("thiselementwasnill", xsdnamespace, 
"nill", true);

So now if the user wants to tell the XMLDas to marshall out something as 
nill they would:
DataObject.<bool>setMetaProperty("thiselementwasnill", xsdnamespace, 
"nill", true);

And then the XMLHelper on read just simply would check to see if the 
"nillable" meta information is on the type and if it is check to see if 
the xsd:nill meta information is set to true on the actual property where 
the elements dataObjectType is located.

Now the user can use introspection on the meta properties to get meta 
information that was XML or any other medium specific meta information. 
But I think the really cool thing about this is that any kind of DAS can 
add any kind of information and now interop with compatible meta 
information from other DAS's. 

So I guess the solution I am proposing is a more robust system that allows 

for meta information that isn't XML centric but generic enough to hold any 

kind of meta information.  One might argue since you can put instance 
properties on types that this already a way to provide meta information. 
However, there is no real way currently to provide instanced meta 
information on properties on a DataObject that has no relation to the 
stored information.
 
Of course this is all just very preliminary in of an idea and maybe there 
are still use cases it doesn't cover well, but if this system was in place 

for 2.1 I think I could of implemented an XSDHelper in such a way it would 

of provided all the meta information needed so XMLHelper could of 
inspected a type created by the XSDHelper and generated a valid XML 
instance document, which is valuable because we have ran into a couple of 
customer use cases for that.

Thanks,
  James



-----Original Message-----
From: Barack, Ron [mailto:ron.barack@sap.com] 
Sent: Wednesday, June 11, 2008 6:47 AM
To: sdo@lists.oasis-open.org
Subject: AW: [sdo] XML Fidelity issue: xsi:nil with attributes

Hi SDO-ers,

I want to bring up some additional options for dealing with xsi:nil. 

OPTION 1:

This is more or less motivated by how JAXB deals with xsi:nil.  JAXB 
defines JAXBElement, which more or less corresponds to the elements in our 

own beloved Sequence.  JAXBElement has a property "isNil", by extension, 
we could add an "isNil(int index)" to Sequence, plus a corresponding 
setter.

The implication would be that types that have elements with 
xsi:nillable="true" would be sequenced.  Since there are costs associated 
with sequenced types, we might make to make this rule more precise.  We 
could say, that nillable implies sequenced only if the element's type does 

not extend a simple type.

OPTION 2:

We define a set of global properties that can be set on objects whether or 

not object.getType().isOpen() is true.  Among these global properties 
would be "xsi:nil" and maybe others, like "xml:lang".  So, to set an 
object to nill, you'd have to look up the global property (using 
TypeHelper or XSDHelper):

                 Property nilProperty = 
XSDHelper.INSTANCE.getGlobalProperty(
                                            "
http://www.w3.org/2001/XMLSchema-instance","nil",false);
      dataObject.set(nilProperty,true); 

It's not easy, but doesn't have to be easy, since I consider this pretty 
much a corner case.  The next question is whether or not such properties 
should appear in the instance properties of an object.  My first 
impression is that they should not, they are not business properties but 
only relevant to XML serialization.  But maybe someone can convince me 
that they are business relevant.

It would be the user's responsibility to set this only where the object is 

used as the value of a nillable property.

I like the second proposal, I think we are introducing something that can 
also be used to solve other problems.  My reservation is that we are 
effectively making everything "half-open"... But isn't that the way XML 
is?


Ron
-----Ursprüngliche Nachricht-----
Von: Frank Budinsky [mailto:frankb@ca.ibm.com] 
Gesendet: Montag, 9. Juni 2008 22:56
An: sdo@lists.oasis-open.org
Betreff: Re: WG: [sdo] XML Fidelity issue: xsi:nil with attributes

Hi Guys,

There are no restrictions on xsd:nillable. Any element declaration can 
have "nillable=true". It can have simple or complex type. So Ron is right 
that Blaise's option 2 is ruled out.

My feeling is the getValue()/setValue() approach that Ron is suggesting is 


a very XML-specific concept, since it's still only used for XML purposes: 
1) complexTypes with simpleContent and 2) for xsi:nil. If that's true, 
then it really doesn't seem right to add it to the DataObject interface.

Yes, the project(Node.class) I'm suggesting would be providing a "live" 
Node-view of the DataObject. I don't really think it's that hard. It's 
very similar to the Sequence-view - just a slightly different "standard" 
API. I'd like to discuss it in this weeks call, if we can spend a little 
bit of time on it.

Thanks,
Frank.




"Barack, Ron" <ron.barack@sap.com> 
06/09/2008 08:48 AM

To
<sdo@lists.oasis-open.org>
cc

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






Hi Blaise, Everyone
 
Looking at the example in section 2.7, we see IntegerRange is simply a 
complex type, not a complex type that extends a simple type.  Therefore, 
AFAICS, it has no value property. 
 
We couldn't find any limitations on which elements can be marked 
"nillable".  But we are not the XSD experts, perhaps someone in the group 
can identify what (if any) restrictions exist.  In any case, I assume 
Frank's example to be valid.  In this case, option 2 falls out, and we 
have no way to express both that the "min" is set and that the value of 
the property is nil.  I think we need some API changes.
 
My gut feeling, however, is that Blaise is on the right track, in 
considering nillable and simple content together.  The current way of 
handling complex types that extend simple context, through the 
introduction of an artificial "value" property, is problematic because it 
leads to name conflicts.  We already have this on our list of issues to be 


addressed in 3.0.  Perhaps we can address these issues together.  One idea 


would be to create a DataObject.getValue() and a 
DataObject.setValue(Object x).   We could define this value as follows
   a) if DataObject.getType() extends simple content, the value is the 
value of the simple context.
   b) if the DataObject.getType() does not extend simple content, then 
unless the user does something, the DataObject.getValue() returns the 
DataObject.
   c) the user may call DataObject.setValue(null):  this sets xsi:nil to 
true when serialized to XML.
   d) unless the type extends simple context, it is an error to set the 
"value" of a data object to anything other value (eg, to another data 
object).
 
If we want to seperate the issues, then it seems odd to have 
XMLHelper.isNil take a DataObject as a parameter.  Whether something is 
nil seems not to be a character of the DataObject, but rather of the the 
property where the data object is set.  That is, we can take an object 
that is used as the value of a non-nillable property, and set it as the 
value of a property that is nillable.  Or the other way around.  This sort 


of leads to the XMLHelper.isNil(DataObject, Property) approach, with 
corresponding setter and getter. I don't see the use case as being so 
important that we need to add the additional convenience methods.
 
The suggesting to "project" to a DOM tree is interesting.  I'm wondering 
how it differs from simply XMLHelper.save'ing to a DOMResult.  Frank, are 
you imagining that the resulting DOM tree will be "live", that is, that 
changes to the DOM tree will be tracked, and immediately visible in the 
original SDO object?  This seems very ambitious!
 
Best Regards,
Ron
 

Von: Blaise Doughan [mailto:blaise.doughan@oracle.com] 
Gesendet: Freitag, 6. Juni 2008 22:25
An: Frank Budinsky
Cc: James Hart; sdo@lists.oasis-open.org
Betreff: Re: [sdo] XML Fidelity issue: xsi:nil with attributes

Hi Frank,

For the following example from your doc (section 2.7), I think there are 
two options: 

<query>
  <intRange min="1" xsi:nil="true"/>
</query>

Option #1 - The property called "intRange" of type "IntegerRange" is set 
and null. This option will not round trip, since the "min" property is 
lost.
Option #2 - The property called "intRange" is set to an instance of 
"IntegerRange" and the "min" property is set to "1" and the "value" 
property is set to null.  This option will round trip.

Then the problem is with the following use case?  Both of the options 
below would marshal to the same XML document, but we would need to choose 
one for the unmarshal operation.

<query>
  <intRange xsi:nil="true"/>
</query>

Option #1 - The property called "intRange" of type "IntegerRange" is set 
and null.
Option #2 - The property called "intRange" is set to an instance of 
"IntegerRange" and the "min" property is unset, and value property is set 
to null.  This option will round trip.

---

I do not believe there is a need for the get/setNil operations.

---

I see where you are going with the project to Node.class concept.  Our 
EclipseLink implementation is built on top of our object-to-XML mapping 
(MOXy) technology (which also supports JAXB).  We would offer the 
corresponding functionality to our users through our implementation of the 


JAXB Binder (which was designed for just this purpose).  The advantage of 
the JAXB Binder approach is that it provides a specific scope in which the 


objects and the DOM are linked.  If I use marshaller a new DOM is produced 


for each marshal operation, but binder will return the one linked to my 
object.

-Blaise


Frank Budinsky wrote: 
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 




---------------------------------------------------------------------
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 

 


---------------------------------------------------------------------
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 


---------------------------------------------------------------------
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 


---------------------------------------------------------------------
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 




---------------------------------------------------------------------
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 


---------------------------------------------------------------------
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 


---------------------------------------------------------------------
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 





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