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: Re: [sdo] SDO-148: Specify ChangeSummary serialization format forarrays and Sequences


Hi Francois,

What about an alternate representation that uses both sdo:ref and sdo:range?  This eliminates the issue you raised about specifying them both at the same time, it also shortens the representation. We could also allow the user to specify only one value in the range, this would serve as the start index, if not specified the end index is assumed to be the last item in the collection.  Then we could make the default value of the sdo:range attribute "1".

Option #1 - sdo:range alone


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

Option #2 - sdo:ref & sdo:range alone

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

    </departments>

</changeSummary>

-Blaise

Rick Barkhouse wrote:
4B68561E.7090108@oracle.com" type="cite"> Hi Francois,

One thing I wasn't clear on... is sdo:range only used when appropriate, or is it meant to be the only way that collections are represented in the change summary?  I'm wondering if you have a list like this:

...
<department>
    <employee>AAA</employee>
    <employee>BBB</employee>
    <employee>CCC</employee>
    <employee>DDD</employee>
</department>
...

If I deleted employees CCC and DDD, and added employees EEE and FFF, what would the change summary look like?  By using sdo:range alone we wouldn't be able to reconstruct the original list would we?  Or would we have a combination of sdo:ranges as well as individual elements?

- Rick

François Huaulmé wrote:
1348C4A8B6B9AF46A57B2CAA346E9C8301D00F4A@MAIL02.bedford.progress.com" type="cite">

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.

 



--
Rick Barkhouse | Software Developer, EclipseLink | 613.288.4613
Oracle Development
45 O'Connor Street, Suite 400 | Ottawa, Ontario K1P 1A4


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