[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]