[Bug 3969] Assertions: problems with basic concepts

http://www.w3.org/Bugs/Public/show_bug.cgi?id=3969


sandygao@ca.ibm.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sandygao@ca.ibm.com




------- Comment #1 from sandygao@ca.ibm.com  2006-11-24 18:33 -------
> 1) Report AND Assert

I thought the WG explicitly decided to have both elements, but when I went back
and check meeting minutes [1], I didn't find that resolution. (Or one can
assume that the adoption of the proposal in Aug. [2] implicitly made that
decision.)

[1] (member-only) http://www.w3.org/XML/Group/2006/04/xml-schema-ftf-minutes
[2] (member-only) http://www.w3.org/XML/Group/2006/08/xml-schema-ftf-minutes

> 2) Why should assert and report be elements? ... a single
> attribute (e.g., test) ... most appropriately in the
> complexType element itself.

That would only allow one assertion per each complex type.

> 3) ... it is a strong deviation with the past. Do we all like it?

There is (at least) one precedence. When you extend a complex type with an
attribute wildcard, you can add a new attribute that's allowed by the wildcard.
This is effectively a restriction.

I was a little uncomfortable by this deviation too, but thought it was OK:
a) I couldn't think of a better way to deal with it. Ignoring assertions from
base is certainly wrong; not allowing new assertions in extension?
b) It doesn't seem to be harmful. We can imagine systems that depends on the
semantics of restriction (accepts less). Not sure whether anyone depends on the
extension semantics of a newly introduced property.

Received on Friday, 24 November 2006 18:33:15 UTC