[Bug 7242] Type inconsistencies introduced by inheritable attributes

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





--- Comment #3 from C. M. Sperberg-McQueen <cmsmcq@blackmesatech.com>  2009-08-21 22:55:41 ---
[Again, speaking only for myself]

Regarding the questions asked in comment #2:

    1. The motivation for CTA seems to be support for Atom.  Are
    inheritable attributes needed for Atom?  I.e., should Atom
    type determination consider some attributes of ancestors but
    not others?

Whether Atoms uses any inheritable attributes I don't know.  But
while it's a favorite example to illustrate the utility of the
construct, it's not the only motivation; see the work by Vitali
and all on SchemaPath for further examples of the utility of
conditional type assignment.  (Note, however, that in specifying
CTA the working group added a number of restrictions to the
construct, which have the effect of making it less powerful and
less useful.  So not all the examples in the SchemaPath paper are
examples of what can be done with CTA.)

    2. Is there an alternative whereby the spec just says that
    CTA expression evaluation requires ancestral attributes to be
    considered?

No.  This was proposed as a resolution of bug 5003 but the
working group was deeply divided on the question: there was
enough opposition to prevent the proposal being adopted.

    3. If in fact the Schema 1.1 intention is to be able to use
    inherited attribute values in "assert" expressions, but no
    intention to expect XPath XDM to be changed we would be in a
    confusing situation where a schema assert behaved one way but
    the exact same expression in Schematron behaved differently.

Yes.  This is already the case owing to the special methods of
XDM instance construction specified for checking assertions.  A
Schematron rule can be applied to xhtml:input, for example,
requiring that "ancestor::xhtml:form" be true.  The same rule can
be attached to xhtml:input in an XSD schema, but it will not have
the desired effect as the assertion will always be false.  (The
assertion is checked against an XDM instance in which the
xhtml:input element is the root element and has neither ancestors
nor siblings.)

    4. If there is pressure in future to make this feature more
    general than just CTA the issues already discussed will have
    to be considered, and the fact that there may be schemas out
    there by then will make it more difficult to rein back on the
    latitude allowed.

That may be a reason to require some form of type consistency.

Perhaps, for example, Schema Information Set Contribution:
Inherited Attributes in section 3.3.5.6 might be augmented with a
clause 4:

  4 If T is the locally declared type T of A within the declared
    type of E, then T is also the governing type definition of A.

This would mean that the values of inherited attributes are
inherited only by elements which don't have conflicting
alterative attribute declarations, and would in turn mean that
there would be less bizarre cruft in the way of any future
attempt to make the inherited attribute feature significantly
more general -- in particular, any attempt to allow attribute
declarations to specify a default value which is inherited from
some other location in the document instance.

But the history of attempts to model attribute inheritance in XSD
leads me to doubt the likely success of any such attempt, so it's
not clear to me that the additional clause is worth the effort.

    5. There are implications for inherited attributes with
    regard to document fragments and XML canonical form.  Is this
    a concern that needs to be thought through?

The explicit declaration of inheritability makes it easier to see
from the schema whether taking an element out of context is going
to cause problems or not.  As has been pointed out, inheritable
attributes are already specified by a number of widespred
vocabularies; providing some documented way of identifying them
seems to me a modest step forward.

And now, a question for my own for those interested in this
issue: is the type guard described in the answer to question 4
worth introducing or not?


-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Friday, 21 August 2009 22:55:51 UTC