Hi Yaron,
Welcome back on Issue 157 ... :-) ... have been waiting for you ... :-)
See more inline ...
Yaron Y. Goland wrote:
I had a few
questions:
A) There is no specification for how namespace declarations from the
source are merged with the destination in the case that the destination
is an EII or AII. What rules are expected?
[AYIU]
Yes, that needs some more work. I am trying to find a clear and elegant
way to describe the NS declaration. The best case scenario is to refer
to other spec. And, instead of saying how to preserve/merge NS
declaration, we would state the post condition of preserve/merge.
As Charlton stated it, this is not the full proposal yet. More work is
needed.
B) Shouldn't
the reference to string() be struck and a pure infoset definition be
used instead? E.g. "take all TII's in document order and concatenate
them". That way we can stay away from any language specific issues like
string() and xpath.
[AYIU]
Note the mentioning of "string()" are under the cover of XPath 1.0
binding. If other expression language is used, other conversion
mechanism can be used (not this string()). This allows more flexibility
per expression language and data model (e.g. XPath 2.0 data model).
(This flexibility is suggested by Danny.)
Personally, I don't particularly oppose your pure-infoset approach
here. But, I do have a small preference over per-expression language
flexibility. ... Thoughts?
C) For an
AII/TII to EII copy why are the attributes on the EII stripped before
the copy is performed?
[AYIU]
Actually, if you read the section "Replace-Content" again, the text
said, "remove all [children] properties (if any)", [children] do not
include attributes.
D) You
define a TII as zero or more CIIs but that violates the requirement
that the source and destination expressions produce a single
information item since 'nothing' can't be an information item.
[AYIU]
I guess that is a case which worths more explanation. This is the gap
between XML Infoset defintion and most expression language Data Model.
(namely, String in XPath 1.0, XPath2.0/XQuery1.0, and etc).
W3C's XML Infoset is mainly designed to provide a set of terminologies
with clear definition to be used in other spec. It is not designed as a
comprehensive data model.
Quoted from the spec: "Its purpose is to provide a consistent set of
definitions for use
in other specifications that need to refer to the information in a
well-formed
XML document ... It does not attempt to be exhaustive; the primary
criterion for inclusion of an information item or property has been
that of expected usefulness in future specifications."
Two clear important cases that does not have direct mapping from/to XML
Infoset are:
- a String abstraction: i.e. a sequence of CharIIs. That is why we
create this TII term back in Issue 103.
- an Empty String: Given this TII / String abstraction, one
important case to address is: Empty String, which is commonly
used in XPath, XQuery or most of programming languages
It is very clear that:
- XPath expression can produce an empty string (e.g. <from>
'' </from>)
- during <assign>/<copy>, we need the concept of empty
string to do perform certain kind of data manipulation. See example
below:
Say, we want to copy the name-string under "p:customerName" element in
From-Data to the name attribute of "q:customerProfile" in To-Data. Of
course, one important case to handle is when the customerName is an
empty string. We surely want to allow that copy to happen.
From-Data:
<p:root>
<p:customerName />
</p:root>
To-Data-Before:
<q:customerProfile name="John Dole" />
To-Data-After:
<q:customerProfile name="" />
With the replacement-table, the following <assign>/<copy>
should be able to do the work.
--------------------------
<assign>
<copy>
<from>$pVar/p:customerName</from>
<to>$qVar/@name</to>
</copy>
</assign>
--------------------------
In short, the TII with zero CII is exactly the bridge for the gap
between XML infoset and this commonly-used in data models (i.e. empty
string). Since we define TII that way, we don't violate the "single
information item" requirement.
Thanks!
Regards,
Alex Yiu
Yaron
Alex Yiu wrote:
Hi all,
Upon the discussion of July 12 conf call, I have updated and simplified
the replacement table from the version that we sent out during the last
F2F.
Please see the attached HTML file.
Thanks!
Regards,
Alex Yiu
Charlton Barreto wrote:
At the July 12 call we:
1) d iscussed the validity and usefulness of the EII for simple-type
semantics, given concerns over handling of attributes between cases. A
compromise of merging the EII for complex-type semantics and EII for
simple-type semantics was discussed, and deemed acceptable to the group
given a decision of whether we should always allow coercion of an
element to text/TII, or always fault in this case. This decision was
further discussed and polled, and it was agreed that we would give
ourselves until July 22nd to converge on it via email. Barring that, we
would hold an Issue 157 conference call on July 26 (08.00 PDT). In any
case we will bring this issue to the TC on the July 27th conference
call.
2) discussed concerns over expression language independence. It was
generally agreed that we protect such independence with Alex's Issue
157 proposal.
3) questioned if we used a variable typed as XSD complex type, whether
it would apply to the EII for complex-type or EII for simple-type
semantics (as opposed to AII or TII). It was agreed that, as complex
type will always be an element, and the content either complex or
simple, it would apply to these semantics. 4) questioned that, given
the lack of schema awareness, whether there was any way to distinguish
between null and empty string, because of the lack of schema awareness?
It was agreed that we don't distinguish between these two cases, as the
runtime is not schema aware (if we'd want to distinguish it, we'd need
to use XPath 2.0 instead of 1.0).
As a result of 1), the existing proposal was amended to accomodate
recommendations from others in the Issue 157 group:
* The first and second rows of the copy/replace semantics table
(from the Palo Alto F2F) would be merged into one row for EII
* EII-to-AII and EII-to-TII copy would be defined as copying the
string-value of EII, instead of fault (except in the case of
xsi:nil="true")
* When xsi:nil="true" on an element, an EII-to-AII or EII-to-TII
copy would trigger a selectionFailure
------------------------------------------------------------------------
Issue 157 - Discussion - Replacement Table
Last modified: July 18, 2005 - 6 pm PDT
Per conf call discussion on July 12, here is refined and consolided
version of the Replacement Table evolved from the F2F discussion.
Refinement and Consolidation of Replacement Table for
<bpel:copy>
Replacement Table:
Src\Target
EII
AII
TII
EII
RE
RC
RC
AII
RC
RC
RC
TII
RC
RC
RC
Definition
* RE (Replace-Element-properties): Remove all [children] and
[attributes] properties of the destination EII and add all
[children] and [attributes] properties of the source EII to the
desitnation EII
o If replaceElementName attribute at <bpel:copy> is set
to
"yes", an extra replacement step will be performed to
replace the target element-name with the source
element-name. (i.e. [namespace name] and [local name]
properties).
(Note: for this "replaceElementName", please see the syntax
example below. This attribute is optional. The default will
be "no" - not replacing target element name. This attribute
is added to support XSD's subsitutionGroup pattern.)
* RC (Replace-Content):
o How to obtain the source content
+ The source (from-spec) MUST yield one and only one
node. Otherwise, selectionFailure fault MUST be
thrown. (That is, "selectionFailure" checking from
BPEL 1.1 is retained.)
+ After the node is yielded from the source, the
"string()" function will be applied to the node to
obtain its string-value as the source content, if the
default XPath 1.0 binding is used in the from-spec.
If
the other expression language is used, a function
other than "string()" may be applied to the node to
obtain the source content
o How to replace:
+ If the destination is an EII, remove all [children]
properties (if any) and add the source content TII
as
the child of the EII.
+ If the destination is an AII, replace the value of
AII
will be replaced by the TII from the source.
+ If the destination is a TII, replace the TII in the
destination with the TII from the source.
*Foot-note to the "Replacement-Table"*:
* Note: the above table does not describe the
message-variable-to-message-variable copy.
* Information items referenced by the to-spec MUST be a Lvalue. (As
stated in Issue 103)
* In XPath 1.0 data model, only Text Node can constitute a LValue
of
TII.
*Clarified Definition of TII: *
TII is a sequence of zero or more CII. When it is mapped to XPath 1.0
model, it is a generalization of String-Value (which has zero or more
characters) and Text Node (which has one or more characters). RValue of
a TII can be mapped to a String-Value or a Text Node in XPath 1.0,
while LValue of a TII can be only mapped to a Text node.
Syntax Example of <copy> with "replaceElementName" attribute:
---------------------------
<assign>
<copy replaceElementName="yes|no">
<from> ... </from>
<to> ... </to>
</copy>
</assign>
---------------------------
------------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. You may a link to this group and 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. You may a link to this group and all your TCs in
OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
|