OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sdo message

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