[Bug 7242] Type inconsistencies introduced by inheritable attributes

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





--- Comment #1 from C. M. Sperberg-McQueen <cmsmcq@blackmesatech.com>  2009-08-07 19:20:42 ---
[Speaking for myself]

You are correct that defining several inheritable attributes with the same name
and different types and semantics is likely to cause confusion among unwary
users; personally I expect good designers to avoid that practice for that
reason.  But it's worth noting that for purposes of conditional type
assignment, the attributes and element in the XDM instance are not typed, so
whatever the various types assigned to attributes named 'required' by different
complex types, any XDM instance used for conditional type assignment will have
the attribute bearing the special 'type' xsd:untypedAtomic.   

It would be difficult though not impossible to change this and create an XDM
instance with typed attributes for conditional type assignment, because there
is no guarantee that all the alternative types being considered will assign the
same type to like-named attributes.  We did consider the possibility of 
validating all attributes in the instance against the declared type of the
element, constructing the XDM, evaluating the test expressions, and then
re-validating the attributes again if necessary; that proposal did not generate
consensus.

The fact that the attributes are untyped for CTA and typed for assertions may
also be responsible for the asymmetry between the two as to whether inherited
attributes are present in the XDM at all.  In recent discussions, various
people including me have spoken as if inherited attributes are present in the
XDM instances used to evaluate assertions, but re-reading the spec more closely
I see that I was wrong.  The XDM used for assertions does not include inherited
attributes.  I don't remember the discussion of this  point in the WG, if any;
it could be just a failure to make the two cases consistent, or it could be a
way of avoiding the kind of variation in type assignment that you describe.  

It was a key, and controversial, design decision in the development of
assertions to specify that all attributes and children should be typed when the
assertion is evaluated. Some members of the WG wanted the element itself to be
typed, before they were eventually persuaded that that could lead to logical
inconsistency in the XDM model (or possibly they were never persuaded, but gave
up because the rest of the WG was adamant).  It's not difficult to see that in
that context some WG members would deplore, as you do, the idea of allowing an
attribute to show up in the XDM instance bearing now one type and now another
unrelated type.

For similar reasons, the fear that attribute inheritance might make XPath-based
processing unreliable seems to me ungrounded.  You write

    A document which had passed validation and was then processed using XPath 
    based on an XDM which in turn was based on the PSVI could produce 
    unexpected and problematic results in these situations. 

Well, you are right that it could, if the XDM instance treated inherited
attributes as if they were normal attributes, and made them accessible through
the attribute axis on elements which inherited them.  

The XDM instances created for the special purposes of checking type-alternative
tests do in fact map inherited attributes in the PSVI into XDM attributes.  But
the canonical mapping defined by the XDM spec does not do so, and it is not to
be expected that it will do so in any future revision, for the reasons you
cite, among others.   It's hard to make guarantees about what others will do in
the future, but the XSL and XML Query working groups responsible for a revision
of XDM would need to be signally bereft of technical judgement in order to make
a mistake like that.  And if anyone proposes it, you and I will be on the same
side in arguing against it.  The only situation in which it makes sense to map
inherited attributes in the XML instance, as currently specified, into normal
attributes in the XDM instance is one in which for reasons good or bad it is
not feasible to traverse the ancestor axis in order to find the attribute
instance one is interested in.  That's the case for conditional type assignment
and assertions, in order to preserve the property that elements can be
validated against a given type in isolation from their context.  That's not
likely to be the case in normal XML processing.

For the same reasons, I would not expect a data binding tool to do anything
particular about inherited attributes; specifically, I would not expected
inherited attributes to show up in the binding as if they had been locally
present.   (But I am not a designer or regular user of data binding tools, so
my expectations are not particularly important.)

I would not want to restrict attribute inheritance to top-level attributes,
because attribute inheritance is well established in languages like TEI and
HTML, which use it in non-top-level cases.

In sum:  in the special case (CTA) where inherited attributes are visible in an
XDM instance, they are untyped, so type inconsistencies of the kind you
describe cannot, strictly speaking, occur.  Inherited attributes are not (as I
understand it) visible in XDM instances used to check assertions, as the spec
is written today.  And it is not expected or recommended that inherited
attributes should be treated by other specs or processing tools as if they were
normal attributes.  

The semantic inconsistencies you describe remain possible, but it's not clear
that it's possible to prevent people from writing confusing schemas, or wise to
try, by any means other than designing a language in which it's easier to be
clear.  ISO 8879 went to great lengths to prohibit specific markup practices it
described as "obfuscatory", but in the most widely discussed cases any
prohibited obfuscation became legal as soon as one additional level of
indirection was added by embedding the prohibited construct within the
declaration of a parameter entity.   The result:  some obfuscation was made
illegal, at the cost of making people who needed it use even more heavily
obfuscated constructs.  A net gain?  


-- 
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, 7 August 2009 19:20:52 UTC