[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]