[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: AW: AW: AW: [sdo] Update of remaining XML Fidelity duplicatenames issues
Frank, Are you envisioning sdo names including the ":" and "[" characters? In Proposal 2 you have introduced an sdoName non-terminal: sdoName ::= '@'? NCName What would this become? Wouldn't that make our SDO Path grammar context-sensitive? Radu > -----Original Message----- > From: Frank Budinsky [mailto:frankb@ca.ibm.com] > Sent: Monday, August 11, 2008 3:49 PM > To: sdo@lists.oasis-open.org > Subject: Re: AW: AW: AW: [sdo] Update of remaining XML > Fidelity duplicate names issues > > Hi Ron, Blaise, > > I agree with Ron that it's important that get("bar") continue > to return the first bar. > > I think the following suggestion of Blaise's might be a breakthrough: > > > Another possible interpretation of the proposal is that asking the > > names > of each > > of the properties would return "bar" and "bar[namespace-uri()=' > http://the-tns2-namespace']". > > At first glance it seems quite strange to think of a property > name like > this: "bar[namespace-uri()='http://the-tns2-namespace']". But > it's strange for a good reason: XPath compatibility. Here's a > slight refinement that I think may work really well: > > The two properties names are: > > 1) bar > 2) bar (or maybe an implementation dependent mangled name) > > The two properties have the following aliasNames: > > 1a) bar[namespace-uri()='http://the-target-namespace'] if the > element form is qualified > 1b) bar[namespace-uri()=''] if the element form is unqualified > 2) bar[namespace-uri()='http://the-tns2-namespace'] > > This way, we can access the first bar using get("bar") and > either property using the standard XPath namespace-uri() syntax. > > Thoughts? > > Frank > > > > > "Barack, Ron" <ron.barack@sap.com> > 08/11/2008 05:47 PM > > To > "Blaise Doughan" <blaise.doughan@oracle.com>, > <sdo@lists.oasis-open.org> cc > > Subject > AW: AW: AW: [sdo] Update of remaining XML Fidelity duplicate > names issues > > > > > > > Hi Blaise, > > But we're starting from an XSD that defines two declared > properties, that are differenciated exactly by their > namespace uri. If we SHOULD NOT use the namespace uri to > differenciate them, what SHOULD we use? > > I'd be really against any proposal that required the > namespace-uri() to be specified even if there are no > duplicate properties. This would be a breaking change for > every <element ref="> property, and be adding a lot of > complexity to handle something that is a relative corner case. > > Let me see if I understand the use case for the getURI() > method - you have the property in your hand, must you want to > find out how to address it using SDOPath. Is that right? > > I'm not so clear whether you are arguing for the getURI() > method or against the proposal in general. Let me ask you > this way, if we added the > getURI() method, would Frank's proposal be acceptable to you? > > Ron > > > Von: Blaise Doughan [mailto:blaise.doughan@oracle.com] > Gesendet: Montag, 11. August 2008 22:21 > An: sdo@lists.oasis-open.org > Betreff: Re: AW: AW: [sdo] Update of remaining XML Fidelity > duplicate names issues > > Hi Ron, > > The basic point I'm trying to make is that a types's declared > properties are not namespace aware, so a namespace uri SHOULD > NOT be used to differentiate the properties. > > In my interpretation of the proposal asking each of the > properties for its name would return "bar". My concern is > that there is currently no means available to someone using > SDO metadata to indicate that the String supplied to the get > method should be namespace qualified (they need to have > knowledge of the XML schema). This is the reason I suggested > having the getURI() method. > > Another possible interpretation of the proposal is that > asking the names of each of the properties would return "bar" > and "bar[namespace-uri()=' > http://the-tns2-namespace']". This eliminates the above > concern, but we could also apply other name mangling > algorithms which would be more compatible with code generation. > > -Blaise > > Barack, Ron wrote: > 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:blaise.doughan@oracle.com] > Gesendet: Mo 11.08.2008 17:50 > An: sdo@lists.oasis-open.org > 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: > > Hi Frank > > I like these proposals. Two comments, additions. > > First, I would like to go through the document and take out all text > stating that name conflicts must be resolved by annotating > with sdo:name. > We are now allowing duplicate SDO names, and specifying the behavior. > > Second, when dealing with name conflicts, I would rather > avoid explicitly > requiring name mangling. I would rather say that the e.g., attribute > names must never hide element names. This is the behavior that is > interesting for the user. Name mangling is an implementation > detail in > order to achieve this. Your wording for proposal 3 is > actually already > what I have in mind, and I would like similar wording in proposal 2. > > > Ron > > -----Ursprüngliche Nachricht----- > Von: Frank Budinsky [mailto:frankb@ca.ibm.com] > Gesendet: Freitag, 8. August 2008 22:02 > An: sdo@lists.oasis-open.org > Betreff: [sdo] Update of remaining XML Fidelity duplicate names issues > > Hi Guys, > > I've updated the 4 remaining unresolved duplicate name proposals, to > reflect the discussions/feedback so far. > > The remaining issues are (see also section 2.1 in > http://www.oasis-open.org/committees/download.php/26722/SDO_XM > L_Issues.doc > ): > > 1. SDO-67 Handling of Namespace in SDO Path (section 2.1.4) > 2. SDO-71 SDOPath handling of '@' character (section 2.1.1) > 3. SDO-82 Name conflicts with anonymous XSD types (section 2.1.2) > 4. SDO-83 Clarification of special "value" property and how > to avoid name > clashes (section 2.1.5) > > I'd like to further discuss and hopefully vote on these > proposals during > next weeks TC call. > > Thanks, > Frank > > > PROPOSAL 1. SDO-67 Handling of Namespace in SDO Path (section 2.1.4) > > The resolution to this issue is to extend the SDO Path syntax > to support > the namespace-uri() function from standard XPath. Although > the syntax is > somewhat ugly, it's important to not invent our own syntax, > but instead > conform to the original goal of SDOPath which was to be (mostly) a > compatible subset of proper XPath. > > Given the following schema: > > <xsd:complexType name="TwoBars"> > <xsd:sequence> > <xsd:element name="bar" type="xsd:string"/> > <xsd:element ref="tns2:bar"/> > </xsd:sequence> > </xsd:complexType> > > An SDO user can then retrieve the second "bar" property as follows: > > dataObject.get("bar[namespace-uri()='http://the-tns2-namespace' > <http://the-tns2-namespace'/> ]"); > > As in previous versions of SDO: > > dataObject.get("bar"); > > would continue to return the first "bar". > > The specific change to the SDO 2.1 spec is in section 12, change: > > step ::= '@'? property > | property '[' index_from_1 ']' > | property '.' index_from_0 > | reference '[' attribute '=' value ']' > | ".." > > to the following: > > step ::= '@'? property > | property '[' index_from_1 ']' > | property '.' index_from_0 > | property '[' namespace-uri() '=' uri ']' > | reference '[' attribute '=' value ']' > | ".." > > uri ::= '"' anyURI "'" > | "'" anyURI "'" > > > In addition to the above resolution, Stefan has proposed adding the > following methods to XSDHelper: > > XSDHelper.getProperty(Type type, String uri, String xsdName, boolean > isElement) > XSDHelper.getInstanceProperty(DataObject, String uri, String xsdName, > boolean isElement) > > These methods provide a non-SDOPath alternative for handling > this issue as > well as SDO-71. I'm also OK with adding these methods. > > > PROPOSAL 2. SDO-71 SDOPath handling of '@' character (section 2.1.1) > > TestCase in ZIP file: DuplicateNamesTest.testAttributeElementClash() > > The resolution to this issue is to require implementations to > automatically mangle the name of attributes that conflict > with an element > in a type, and to also specify that XSD attributes will map > to properties > that have @name as an aliasName. > > Given the following schema: > > <xsd:complexType name="TwoFoos"> > <xsd:sequence> > <xsd:element name="foo" type="xsd:string"/> > </xsd:sequence> > <xsd:attribute name="foo" type="xsd:int"/> > </xsd:complexType> > > This will produce an SDO Type named "TwoFoos" with two properties: > > 1. name="foo", type=String > 2. name="some_mangled_name", type=Int, aliasName="@foo" > > An SDO user can then retrieve the foo element as follows: > > dataObject.get("foo"); > > And the foo attribute like this: > > dataObject.get("@foo"); > > Although this solution is not 100% backwards compatible > (i.e., it does not > allow an XML element to be accessed using the "@name" syntax), it is > backwards compatible for all practical purposes, since it's highly > unlikely that there are any existing SDO users that rely on > the ability to > use the @ syntax to retrieve element properties. > > Note 1: with this proposal, an attribute-backed property that appears > after an element-backed property in the getProperties() list does not > necessarily conflict, since the spec already says that in the case of > duplicates the first property will hide the others. Since the > goal of this > resolution is to ensure that the element-backed property will > always take > precedence we could allow an implementation to choose not to actually > mangle the attribute-backed property name in this case, as long as it > still sets the aliasName as specified above. > > Note 2: with this solution SDO Path works with SDO names. The > attribute/element aspects only impact the mapping from XSD to SDO. > > The specific changes to the SDO 2.1 spec for this issue are: > > 1) In section 9.3 change: > > If elements and attributes within a complexType, and its base > types, have > the same local name then unique names must be assigned by sdo:name. > > to the following: > > If elements and attributes within a complexType, and its base > types, have > the same local name and unique names are not assigned by > sdo:name, then an > implementation will automatically rename the attribute > property (i.e., the > one for which XSDHelper.isAttribute returns true) to an > implementation-dependent mangled name. > > (NOTE, do we want to open another issue to consider standardizing the > mangled name used for conflicting attributes? Personally, I > think that if > users care, they should use sdo:name annotations.) > > 2) In section 9.3.1, first row of the table (i.e., "Attribute" row), > change: > > Property name=[NAME] > type=[TYPE] > > to the following: > > Property name=[NAME] > type=[TYPE] > aliasName=@[NAME] > > 3) In section 12, change: > > step ::= '@'? property > | property '[' index_from_1 ']' > | property '.' index_from_0 > | reference '[' attribute '=' value ']' > | ".." > property ::= NCName ;; may be simple or complex type > attribute ::= NCName ;; must be simple type > reference :: NCName ;; must be DataObject type > > to the following: > > step ::= property > | property '[' index_from_1 ']' > | property '.' index_from_0 > | reference '[' attribute '=' value ']' > | ".." > property ::= sdoName ;; may be simple or complex type > attribute ::= sdoName ;; must be simple type > reference ::= sdoName ;; must be DataObject type > sdoName ::= '@'? NCName > > Also in section 12, change: > > The presence or absence of the @ sign in a path has no > meaning. Properties > are always matched by name independent of their XML representation. > > to the following: > > Unlike standard XPath, the @ sign is not required for accessing > attribute-backed properties. It can be used to access > properties that have > an aliasName that includes the @ sign, typically XML attributes - see > section 9.3.1. > > > PROPOSAL 3. SDO-82 Name conflicts with anonymous XSD types > (section 2.1.2) > > TestCase in ZIP file: DuplicateNamesTest.testAnonymousTypeClash() > > This issues has already been partially resolved in SDO 2.1.1 > (JSR 235). In > JSR 235 it was agreed that anonymous types in locally defined > elements are > automatically mangled so as not to conflict with global types. For > example: > > <xsd:complexType name="personRoot"> > <xsd:sequence> > <xsd:element name="person"> > <xsd:complexType> > <xsd:sequence> > <xsd:element name="identifier" > type="xsd:string"/> > </xsd:sequence> > </xsd:complexType> > </xsd:element> > </xsd:sequence> > </xsd:complexType> > > Unlike SDO 2.1, in SDO 2.1.1 the anonymous type declared > under the local > "person" element will not conflict with a global type > "person" such as: > > <xsd:complexType name="person"> > <xsd:sequence> > <xsd:element name="firstName" type="xsd:string"/> > <xsd:element name="lastName" type="xsd:string"/> > </xsd:sequence> > </xsd:complexType> > > However, in JSR 235 it was not required that an > implementation also mangle > the name of an anonymous type under a global element: > > <xsd:element name="person"> > <xsd:complexType> > <xsd:sequence> > <xsd:element name="name" type="xsd:string"/> > </xsd:sequence> > </xsd:complexType> > </xsd:element> > > The proposed resolution to this issue is to take the extra step to say > that the name of this anonymous type must also be mangled. This is > required in order for SDO to guarantee that: > > typeHelper.getType(NS_DUPLICATES, "person"); > > will always return a real globally defined complexType, as above. > > The specific change to the SDO spec for this issue is: > > 1) the changes to reflect the resolution of the issue in JSR 235 > 2) State clearly that anonymous types (under local or global > elements/attributes) will never be given name that hides a globally > defined type with the same name. > > > PROPOSAL 4. SDO-83 Clarification of special "value" property > and how to > avoid name clashes (section 2.1.5) > > TestCase in ZIP file: DuplicateNamesTest.testValuePropertyClash() > > Since only attributes named "value" can conflict with the > special "value" > property, the solution to Proposal 2 (SDO-71) will also solve > this issue, > as long as the special "value" property is treated like an > element-type > property. This will be the case, given the proposed wording > for SDO-71, > that is, it uses XSDHelper.isAttribute() as its test. > Therefore, since the > special "value" property is not an attribute, it will be > treated like an > element. > > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to 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. Follow this link to 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. Follow this link to 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. Follow this link to 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]