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: SDO-148: Specify ChangeSummary serialization format for arrays and Sequences


Hi everyone,

 

I won’t be able to attend today’s meeting. But I worked on SDO-148 this week (“Specify ChangeSummary serialization format for arrays and Sequences”). I’ve some questions and an early proposal I’d like to share with you.

1.       The sdo:ref attribute accepts both IDREFs and XPath values. But are IDREFs acceptable for sdo:range as value? We believe sdo:range should only have XPath values.

2.       Are sdo:range and sdo:ref mutually exclusive? If the XML format has both attribute on the same element, how an implementation should behave? We thought of 2 possibilities:

a.       Ignore the sdo:ref declaration. In that case only the value in sdo:range is interpreted, sdo:ref value is ignored.

b.      Throw an exception to the SDO user indicating that the XML format isn’t correct.

3.       Should we allow/support sdo:ranges on all XML change summary elements? In this example the following XML fragment summarizes 4 departments that share the same employees:

 

<changeSummary create="#/company:company[1]/departments[1]/employees[3]" delete="#/changeSummary/departments[1]/employees[3]">

<departments sdo:range="#/company:company[1]/departments[1] #/company:company[1]/departments[4]">

<employees sdo:range="#/company:company[1]/departments[1]/employees[1] #/company:company[1]/departments[1]/employees[4]"/>

</departments>

</changeSummary>

 

In this case an SDO implementation would have to ensure all elements reachable from a “department” remain the same. We think this as a potential performance issue for an implementation. We would then propose that an implementation should support deserialization but isn’t required to produce this format.

 

Here are the changes I propose to the specification:

 

Add a paragraph to the core spec, section 10.2 after first paragraph. 

When serializing list of consecutive references to DataObjects as a value of an sdo:range attribute an SDO implementation MUST use IDREFs when IDs are available, and XPath expressions otherwise (See question 1) [COR1002xxxx]. The sdo:range attribute value MUST contain a reference to the range start and a reference to the range end separated with a white space character.  [COR1002xxxx]. The following examples are equivalent:

 

<changeSummary create="#/company:company[1]/departments[1]/employees[3]" delete="#/changeSummary/departments[1]/employees[3]">

<departments sdo:ref="#/company:company[1]/departments[1]">

<employees sdo:ref="#/company:company[1]/departments[1]/employees[1]"/>

<employees sdo:ref="#/company:company[1]/departments[1]/employees[2]"/>

<employees sdo:ref="#/company:company[1]/departments[1]/employees[3]"/>

<employees sdo:ref="#/company:company[1]/departments[1]/employees[4]"/>

</departments>

</changeSummary>

 

<changeSummary create="#/company:company[1]/departments[1]/employees[3]" delete="#/changeSummary/departments[1]/employees[3]">

<departments sdo:ref="#/company:company[1]/departments[1]">

<employees sdo:range="#/company:company[1]/departments[1]/employees[1] #/company:company[1]/departments[1]/employees[4]"/>

</departments>

</changeSummary>

 

Add the sdo:range (here in bold) attribute in second paragraph of section 10.2

XPath expressions are distinguishable from ID references in that they start with a „# character. Key properties, other than those identified using the schema ID type, are not used as values of sdo:ref, sdo:range, or as elements of the created or deleted lists.

 

Add a sentence (here in bold) in first paragraph in section 10.4

If the property's type is not a dataType, an SDO implementation MUST render unaltered elements using the sdo:ref attribute to indicate the corresponding object in the final document or the sdo:range attribute to indicate a range of corresponding objects in the final document. [COR10040003]

 

 

Thanks,

 

cid:3297350850_825347

François Huaulmé


O. +33 (0)1 46 14 13 08 | E. francois.huaulme@datadirect.com  | F. +33 (0) 1 46 14 13 01

DataDirect Technologies | 21 rue des Trois-Fontanot | 92000 | Nanterre | France
www.datadirect.com


This electronic message contains information from DataDirect Technologies Ltd. which may be privileged or confidential. The information is intended to be
for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the numbers or address above) immediately.

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]