[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: AW: AW: AW: [sdo] XML Fidelity duplicate names issues
Hi Frank. >3.c) We add a function to the XSDHelper: > XSDHelper.getProperty(Type type, String uri, String xsdName, >boolean isElement) >XSDHelper.getInstanceProperty(DataObject, String uri, String xsdName, >boolean isElement) I would support the idea to add these functions to the XSDHelper. That are not just a convenience methods. These methods can also provide a better performance than the user could achieve by iterating over the instance properties. >Sounds like you're agreeing with the original proposal (see >http://www.osoa.org/jira/browse/SDO-71). Ahh, I remember. The spec says that property names are unique. My objection was that the @-sign is not necessary unless we are changing this. I think, duplicated property names should be allowed if they come from meta-data sources where this can not be avoided. (I only know XSD). For renamed properties only unique names should be allowed. (So we had a clear usage: xsd-name with @, sdo-name without @) >The more I think about your dynamic scenario, I think that it's really a >bigger problem then just attributes/elements. For example, if there was an >extension type that introduces a duplicate of an element in the base, then >the property is supposed to become isMany=true (SDO 2.1 spec section >9.3.2). In your dynamic scenario, this is not possible either. Yes, this is ugly. >So, my inclination is to say that in the dynamic case, the behavior is >implementation dependent. I can live with that. My hope was that we achieve the broadest possible consent for solving the XML fidelity problems. Stefan. -----Ursprüngliche Nachricht----- Von: Frank Budinsky [mailto:frankb@ca.ibm.com] Gesendet: Freitag, 25. Juli 2008 17:22 An: sdo@lists.oasis-open.org Betreff: Re: AW: AW: [sdo] XML Fidelity duplicate names issues Hi Stefan, A few more comments. > 3.a) We allow Type.getProperty("@prop[namespace-uri()='http://test.org']"); Interesting idea, but I have two issues with it. 1) The getProperty() argument would now be another special XPath subset language, instead of simply "propertyName". SDO would now need to describe two different XPath subset languages - SDOPath and PropertyPath. I don't really like the extra complexity. 2) To support the attribute case, "prop" would need to be xsd name, not SDO name. I thinks its starting to get too complicated. > 3.b) We add a function to Type: > Type.getProperty(String uri, String xsdName, boolean isElement) It doesn't seem appropriate to use xsdName and isElement as the arguments for Type methods - I think 3.c) would be much more appropriate. > 3.c) We add a function to the XSDHelper: > XSDHelper.getProperty(Type type, String uri, String xsdName, boolean isElement) This isn't a bad idea, but we would probably also want (even more) another similar method: XSDHelper.getInstanceProperty(DataObject, String uri, String xsdName, boolean isElement) So we'd need to add two methods in XSDHelper. I'm not sure how much demand there is for these methods. They would simply be convenience methods. Users can always look up any property by iterating through the list themselves. > >2) We can add some wording in the spec, that says whenever there are > >duplicates, an SDOPath will match the element-backed property first, even > >if the attribute is earlier in the list. We discussed this on a previous > >call, but there seemed to be resistance to the idea. > > I like this idea. Sounds like you're agreeing with the original proposal (see http://www.osoa.org/jira/browse/SDO-71). When we discussed this a few weeks ago, people objected to the idea of bringing the concept of XML attribute/element into SDOPath. The issue of when to use SDO name vs. XML name in the algorithm was also an issue. I can't remember if there were other objections or not, but I do remember we weren't anywhere close to agreement on the approach. The more I think about your dynamic scenario, I think that it's really a bigger problem then just attributes/elements. For example, if there was an extension type that introduces a duplicate of an element in the base, then the property is supposed to become isMany=true (SDO 2.1 spec section 9.3.2). In your dynamic scenario, this is not possible either. So, my inclination is to say that in the dynamic case, the behavior is implementation dependent. An implementation may simply add the duplicate (which is hidden by the earlier property in the list), it may mangle the duplicate, it may simply fail, or who knows what. If the user wants to be sure that they can dynamically extend types with standard behavior, they need to ensure that duplicates are annotated with sdo:name. They also need to do this if they want to generate implementation-independent static SDOs - e.g., getFoo() and getFoo_attr(). Frank. "Buennig, Stefan" <stefan.buennig@sap.com> 07/25/2008 04:03 AM To <sdo@lists.oasis-open.org> cc Subject AW: AW: [sdo] XML Fidelity duplicate names issues Hi Frank, >So, my proposal is simply to use the same syntax as XPath for >this. If it is already used in Xpath, then you are right. We should do the same. >> I also would not append an alias with the '@'-sign. I'd rather see the >> '@' as part of the path-syntax than as part of the property name or >alias. > >That was my original preference as well, but we've since realized there >are many benefits of handling it with an alias name. > >1) there's no special behavior described for @prop, it's just another name >you can use. >2) the path "@attr" will always work, regardless of any renaming (explicit >or implementation mangling) that is done to the actual property name. >3) getProperty("@prop") will work. (if it's just an SDOPath character, >getProperty("@prop") won't return anything). I would prefer a single solution for the namespace conflict and the attribute/element conflict. 2) You are right, we had to define if the @ is used for sdo-name, xsd-name and/or alias. I would prefer the xsd-name because the user knows about the schema. If renaming comes into play, the new names have to be unique, so no @ sign is necessary. 3) You mean Type.getProperty()? For Types I would see also a single solution for both kinds of conflicts. My ideas to solve this: 3.a) We allow Type.getProperty("@prop[namespace-uri()='http://test.org']"); 3.b) We add a function to Type: Type.getProperty(String uri, String xsdName, boolean isElement) 3.c) We add a function to the XSDHelper: XSDHelper.getProperty(Type type, String uri, String xsdName, boolean isElement) >2) We can add some wording in the spec, that says whenever there are >duplicates, an SDOPath will match the element-backed property first, even >if the attribute is earlier in the list. We discussed this on a previous >call, but there seemed to be resistance to the idea. I like this idea. Best regards, Stefan. -----Ursprüngliche Nachricht----- Von: Frank Budinsky [mailto:frankb@ca.ibm.com] Gesendet: Donnerstag, 24. Juli 2008 17:03 An: sdo@lists.oasis-open.org Betreff: Re: AW: [sdo] XML Fidelity duplicate names issues Hi Stefan, Thanks for the feedback. > The proposal is ok, but the syntax doesn't look very easy. > I expected something that uses the hash sign # we know from Qnames. I agree the syntax could be simpler, but I think it's important to not invent our own syntax. The original goal of SDOPath was to be (mostly) a compatible subset of proper XPath. The exceptions to that rule have tended to cause more problems then they are worth (e.g., the "name.index" syntax). So, my proposal is simply to use the same syntax as XPath for this. > In addition we should define the meaning of URI for properties. Yes. Again, I think it needs to work the same as in proper XPath. I believe your proposal is the same as in XPath. > I also would not append an alias with the '@'-sign. I'd rather see the > '@' as part of the path-syntax than as part of the property name or alias. That was my original preference as well, but we've since realized there are many benefits of handling it with an alias name. 1) there's no special behavior described for @prop, it's just another name you can use. 2) the path "@attr" will always work, regardless of any renaming (explicit or implementation mangling) that is done to the actual property name. 3) getProperty("@prop") will work. (if it's just an SDOPath character, getProperty("@prop") won't return anything). > I think, we should avoid any automatic name-mangling for properties. We need to somehow make sure that the attribute property doesn't hide the later element property. In many cases the attribute will hide the element since it appears first in the instanceProperties list, so get("prop") will not bind to the element. Renaming when we can, seems like a good idea. But, the question is how can we handle your example, where automatic renaming isn't possible? 1) The simplest answer is to say that the user needs to add the sdo:name annotation to the attribute in the base class, or the element won't be available in the subtype. 2) We can add some wording in the spec, that says whenever there are duplicates, an SDOPath will match the element-backed property first, even if the attribute is earlier in the list. We discussed this on a previous call, but there seemed to be resistance to the idea. I'm open to other ideas for handling this. Thanks, Frank. "Buennig, Stefan" <stefan.buennig@sap.com> 07/24/2008 07:10 AM To <sdo@lists.oasis-open.org> cc Subject AW: [sdo] XML Fidelity duplicate names issues Hi Frank, your proposals are a good step forward for SDOs XML fidelity. Here are my comments: PROPOSAL 1. SDO-67 Handling of Namespace in SDO Path (section 2.1.4) The proposal is ok, but the syntax doesn't look very easy. I expected something that uses the hash sign # we know from Qnames. But may be that would be too difficult to parse in case of chained paths. In addition we should define the meaning of URI for properties. My proposal: If a property has to be rendered in XML with a prefix to be valid against it's schema then the URI is the URI that is represented by the prefix otherwise the URI is an empty String "". I think this would reduce confusions about the meaning of the properties URI in case of elementFormDefault and attributeFormDefault is unqualified. The same should be valid for XSDHelper.getNamespaceURI(Property) With this definition we have a well defined access to the properties of the following root-object: <ns:root xmlns:ns="http://test.org" ns:prop="attribute1" prop="attribute2"> <ns:prop>element1</ns:prop> <prop>element</prop> </ns:root> PROPOSAL 2. SDO-71 SDOPath handling of '@' character (section 2.1.1) I think, we should avoid any automatic name-mangling for properties. With different namespaces we already have conflicting property names and so the element/attribute conflict doesn't make the things worse. I also would not append an alias with the '@'-sign. I'd rather see the '@' as part of the path-syntax than as part of the property name or alias. Here is an example where name mangling would fail: First you parse this schema S1.xsd <?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace=" http://test.org"> <xs:complexType name="T1"> <xs:attribute name="prop" type="xs:string"/> </xs:complexType> </xs:schema> If I understood you right the attribute name will not be mangled because there is no conflict. Later you parse this schema S2.xsd with the same XSDHelper: <?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace=" http://test.org" xmlns:tns="http://test.org"> <xs:include schemaLocation="S1.xsd"/> <xs:complexType name="T2"> <xs:complexContent> <xs:extension base="tns:T1"> <xs:sequence> <xs:element name="prop" type="xs:string"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> </xs:schema> When you parse the second schema it is too late to rename the attribute. We have a customer who is very paranoid about such cases. Regards, Stefan. -----Ursprüngliche Nachricht----- Von: Frank Budinsky [mailto:frankb@ca.ibm.com] Gesendet: Mittwoch, 23. Juli 2008 22:11 An: sdo@lists.oasis-open.org Betreff: [sdo] XML Fidelity duplicate names issues As mentioned in the last OASIS call, I would like to submit proposals for solutions to several XML Fidelity issues, specially the issues described in section 2.1 of: http://www.oasis-open.org/committees/download.php/26722/SDO_XML_Issues.doc I would also like to propose that we publish an interim SDO 3 committee draft, which includes these and the other resolved issues so far, by the end of August. How do others feel about this date? The OASIS JIRAs corresponding to the issues in section 2.1 of the above document are: 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) 5. SDO-? (NEW) Type of merged property for duplicate elements (section 2.1.3) 6. SDO-? (NEW) isMany value of merged property for duplicate elements (section 2.1.3) The following describes the proposed resolution to each of these issues. I've also attached a test program that illustrates the expected behavior for each issue. PROPOSAL 1. SDO-67 Handling of Namespace in SDO Path (section 2.1.4) TestCase in ZIP file: DuplicateNamesTest.testPropertyURIClash() The resolution to this issue is to extend the SDO Path syntax to support the namespace-uri() function from standard 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']"); 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 "'" 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. 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. PROPOSAL 5. SDO-? (NEW) Type of merged property for duplicate elements (section 2.1.3) TestCase in ZIP file: DuplicateNamesTest.testSequenceWithDuplicates() The resolution to this issue is as described in section 2.1.3. More specifically, in section 9.3.2 of the SDO 2.1 spec change: The type of the property is SDO Object. to the following: The property's type is that of the elements, which if the schema is valid must all be the same. PROPOSAL 6. SDO-? (NEW) isMany value of merged property for duplicate elements (section 2.1.3) TestCase in ZIP file: DuplicateNamesTest.testChoiceWithDuplicates() The resolution to this issue is as described in section 2.1.3. More specifically, in section 9.3.2 of the SDO 2.1 spec change: A single property is used for all the elements with the same local name and the same targetNamespace, where isMany=true. to the following: A single property is used for all the elements with the same local name and the same targetNamespace. If the content model allows more than 1 instance of the element, then isMany=true. If, however, the elements are mutually exclusive (for example, they are single valued and on two sides of a xsd:choice group), then isMany=false. --------------------------------------------------------------------- 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]