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