[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [sdo] XML Fidelity issue: xsi:nil with attributes
James, you said: "They should be ignored in the normal flow of things". So if I run CopyHelper.copy() on a DataObject that has an xs:nil attribute on it, you would expect that the copy will not have the xsi:nil on it? Same goes for EqualityHelper, it would seem that xsi:nil needs to participate in these operations.
But if we want to generalize this to implementation-defined "system properties", then it is not at all clear what operation should they participate/not participate in. CopyHelper/EqualityHelper are examples, but also XML serialization: should they be serialized or not? I think we may be adding a lot of unjustified complexity here.
Radu
> -----Original Message-----
> From: James Hart [mailto:James.Hart@roguewave.com]
> Sent: Monday, June 23, 2008 3:07 PM
> To: Frank Budinsky; sdo@lists.oasis-open.org
> Subject: RE: [sdo] XML Fidelity issue: xsi:nil with attributes
>
> Could we add a new signature for getInstanceProperties such
> as getInstanceProperties(bool getTechnical) instead?
>
> Thanks,
> James
>
>
> -----Original Message-----
> From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> Sent: Monday, June 23, 2008 4:04 PM
> To: sdo@lists.oasis-open.org
> Subject: RE: [sdo] XML Fidelity issue: xsi:nil with attributes
>
> Hi James,
>
> To me, "meta" implies a change in the description level -
> that is, meta-data describes data, meta-meta-data, describes
> meta-data, and so on.
> So the name
> "meta property" would imply that it is describing a property,
> as opposed to being a special "hidden" property.
>
> Technical property, on the other hand, is not a terrible
> name, but IMO not really very obvious what it is. I'm not
> sure if "system" is really much better, but I think it may be
> a little better.
>
> I'd rather not add a new method to DataObject (it has more
> than enough already), if we can avoid it.
>
> Thanks,
> Frank.
>
>
> "James Hart" <James.Hart@roguewave.com> wrote on 06/23/2008
> 05:15:29 PM:
>
> > I am not sure why "meta properties" didn't catch on. I
> don't really
> > care what it is called and I don't think this should ever
> be confused
> > with anything XMLcentric, it is and SDO thing that
> XML/XSDDas/Helper
> > would simply be utilizing.
> >
> > getTechnical(Meta|System)Properties would be on the same objects as
> > getInstanceProperties is, so DataObject and Type, is
> > getInstanceProperties on anything else? The proposal is that these
> > Meta Properties are simply instance properties where
> > is(Meta|Technical|Whatever) property of the instance
> property is true
> > and these type of instance properties can be added at
> anytime even on
> > closed types and data objects. They should be ignored in
> the normal
> > flow of things that is why they wouldn't be part of the
> > getInstanceProperties list.
> >
> > I wouldn't want to tie these to anything xmlcentric such as the xml
> > attribute solution. Simply making them special kinds of instance
> > properties makes it very robust and general for any
> mechanism to take
> > advantage of. If it is decided to make xmlcentric than
> going back to
> > a isNill/setNill api would be as desirable to me (as in not very
> > desirable).
> >
> >
> > Thanks,
> > James
> >
> > -----Original Message-----
> > From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> > Sent: Monday, June 23, 2008 2:54 PM
> > To: sdo@lists.oasis-open.org
> > 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/SD
> > O_
> > 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
> >
> >
> >
> >
> >
> ---------------------------------------------------------------------
> > 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_workgr
> oups.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]