[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 Radu,
I have a slightly different perspective on this. I think it will be too
complex if we try to come up with all kinds of rules and restrictions
about how and where you can use hidden/system properties. To me, system
properties are no different than any other property on a data object other
than they are not filtered out of the getInstanceProperties() list,
because they are not part of the user's business model. Otherwise, they
behave like any other property, e.g., in CopyHelper, EqualityHelper, etc.
Some of these system properties, like xsi:type, clearly have validity
constraints which imply that calling set() on them may have undesirable
effects, but that's sometimes the case with user properties as well.
Calling get(xsiTypeProperty) would clearly be a useful thing for users
that want high XML Fidelity.
> Are there any situations when the value of the xsi:type
> "system property" and the value of DataObject.getType()
> will be different?
They will usually be different because get(xsiTypeProperty) will usually
be null/unset.
Frank.
"Radu Preotiuc-Pietro" <radu.preotiuc-pietro@oracle.com>
06/23/2008 07:59 PM
Please respond to
"radu.preotiuc-pietro@oracle.com" <radu.preotiuc-pietro@oracle.com>
To
"sdo@lists.oasis-open.org" <sdo@lists.oasis-open.org>
cc
Subject
RE: [sdo] XML Fidelity issue: xsi:nil with attributes
Hi Frank, Blaise,
Same goes for xsi:type. Normally, I have a DataObject and I have its type
(DataObject.getType()). Are there any situations when the value of the
xsi:type "system property" and the value of DataObject.getType() will be
different? What happens if we set the value of the system property to some
different type? Is this somehow related to "wrapper" types and xs:anyType?
Just like my previous post, I can see a lot of complexity being
introduced, and it's not clear that we have enough benefits to justify it.
I don't fully disagree with the idea of "hidden/system properties", but it
would seem wise for now to restrict the set of what can be a "hidden
property" to some well-defined cases.
Radu
> -----Original Message-----
> From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> Sent: Monday, June 23, 2008 3:14 PM
> To: sdo@lists.oasis-open.org
> Subject: Re: [sdo] XML Fidelity issue: xsi:nil with attributes
>
> Hi Blaise,
>
> You're right that they don't need to be technical properties,
> since we already have an API for accessing them. I just
> thought that since they are "hidden" attributes (properties)
> that may appear on a DataObject, one would also reasonably
> expect them to be exposed as technical properties on the
> DataObject that contains them.
>
> Frank.
>
> Blaise Doughan <blaise.doughan@oracle.com> wrote on
> 06/23/2008 05:14:30
> PM:
>
> > Hi Frank,
> >
> > xsi:schemaLocation & xsi:noNamespaceSchemaLocation are currently
> > tracked
>
> > by commonj.sdo.helper.XMLDocument, why would these need to be
> > technical properties?
> >
> > -Blaise
> >
> > Frank Budinsky wrote:
> > > 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.p
> > > hp
>
> > >
> > >
> > >
> > >
> > >
> --------------------------------------------------------------------
> > > - 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.p
> > > hp
>
> > >
> > >
> > >
> > >
> > >
> --------------------------------------------------------------------
> > > - 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.p
> > > hp
>
> > >
> > >
> > >
> --------------------------------------------------------------------
> > > - 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.p
> > > hp
>
> > >
> > >
> > >
> --------------------------------------------------------------------
> > > - 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.p
> > > hp
>
> > >
> > >
> > >
> > >
> > >
> --------------------------------------------------------------------
> > > - 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.p
> > > hp
>
> > >
> > >
> > >
> --------------------------------------------------------------------
> > > - 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.p
> > > hp
>
> > >
> > >
> > >
> --------------------------------------------------------------------
> > > - 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.p
> > > hp
>
> > >
> > >
> > >
> > >
> > >
> --------------------------------------------------------------------
> > > - 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.p
> > > hp
>
> > >
> > >
> >
> >
> ---------------------------------------------------------------------
> > 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]