Re: AW: AW: [sdo] Update of remaining XML Fidelity duplicate namesissues

Hi Blaise,
 
I'm not sure I follow your logic for option 1.   Are you saying that if we allow the "namespace-uri()" notation, that it will then be required to address any element, whether a conflict is there or not?  Why couldn't we just say that if namespace-uri() is not specified, we return the first element whose local name matches.  It might not be so helpful when there are duplicates, but at least it provides reasonable and backwards compatible behavior when there are no duplicate names.
 
@Frank:  suppose the order of the 2 "bar" elements were reverse.  How would you then address the second element?
 
Regarding the Property.getURI() API, can you give a use-case why this is necessary?  Also, do you think Property is the right place for the method, or do you think it belongs to XSDHelper (eg, XSDHelper.getURI(Property p))?  The question basically boils down to, is this another of the wierd use-cases we are forced to handle because we want better XML fidelity, or is this a reasonable piece of metadata, that could be valid for other sources of metadata, such as RDB schemas, or interface introspection...  If it's valid for other sources of metadata, then we should definitely add not only Property.getURI(), but we should also add the field to {commonj.sdo}Property, right?
 
Thanks for your efforts,
Ron

________________________________

Von: Blaise Doughan [mailto:]
Gesendet: Mo 11.08.2008 17:50
An: 
Betreff: Re: AW: [sdo] Update of remaining XML Fidelity duplicate names issues



Hi Frank,

For SDO-67, I am not against a namespace aware API.  In fact one is
necessary for properly querying open content properties (which have a
namespace URI).  We can either use the one you proposed based on XPath,
or the one I proposed based on the javax.xml.xpath APIs for handling XPaths.

The aspect of the proposal I object to is the use of namespace URIs to
differentiate a Types declared properties.   The declared properties of
a type are not namespace aware (there is no Property.getURI() method),
so how could this be used as a differentiator?  As I see it we have the
following options:

1.  Make declared properties namespace aware.  This would mean the
following calls would be valid (based on your example schema fragment):
    dataObject.get("bar[namespace-uri()='http://the-tns2-namespace' <http://the-tns2-namespace'/> ]");
   
dataObject.get("bar[namespace-uri()='http://the-target-namespace' <http://the-target-namespace'/> ]"); 
// Assuming that elementFormDefault="qualified"
    Property property =
dataObject.getType().getProperty("bar[namespace-uri()='http://the-tns2-namespace' <http://the-tns2-namespace'/> ]");
    property.getURI();  // NEW METHOD - would return
"http://the-tns2-namespace <http://the-tns2-namespace/> "
    dataObject.get("bar");  // Would return null as there is no property
with name="bar" and uri=null.

2.  Keep declared properties namespace unaware.  This would mean that
one of the properties would require an annotation to change the name.


-Blaise

Barack, Ron wrote: