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