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