[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: AW: [sdo] XML Fidelity issue: xsi:nil with attributes
Hi Ron, I really like OPTION 2. It's very simple and a clean reuse of an existing API. I don't think properties in the xsi namespace (e.g., xsi:nil or xsi:type) should appear in getInstanceProperties() - they are not business relevant, and should therefore be filtered out. Users can figure out if xsi:nil is set by simply calling isSet(xsiNilProperty). If we decide to provide a more advanced XML view of the dataobject (e.g., Node.class), then users can also see what advanced instance properties are set using it. But that's a separate issue. Frank "Barack, Ron" <ron.barack@sap.com> 06/11/2008 08:47 AM To <sdo@lists.oasis-open.org> cc 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]