W3C home > Mailing lists > Public > www-xml-schema-comments@w3.org > January to March 2008

[Bug 5003] Applicability of <alternative> element to xml:lang

From: <bugzilla@wiggum.w3.org>
Date: Wed, 23 Jan 2008 11:40:36 +0000
CC:
To: www-xml-schema-comments@w3.org
Message-Id: <E1JHdy8-0007FB-Df@wiggum.w3.org>

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





------- Comment #19 from ht@inf.ed.ac.uk  2008-01-23 11:40 -------
(In reply to comment #13)
> Dear Michael,
>
>> But what it does do is to destroy the property that you can
>> validate an element, label it with a type annotation, and then copy
>> the element to a new tree knowing that the type annotation will
>> still be sound. That property is extremely important to QT.
>
> I have been trying to come to grip to this and other comments along
> the same line for a while now, and I haven't been able to understand
> their point.  Context-free validation can be considered as a
> property or a goal . . .

Not 'considered as a property', it _is_ a property of validity as
defined in XSDL 1.0 as published and XSDL 1.1 as currently spec'd.  As
Mike Kay points out, it's a property QT depend on.  So we don't change
it without careful thought and good reason.

> . . .

> The acceptability of some elements in some document types does OFTEN
> depend on circumstances that exist outside of the subtree they
> head. That is unfortunate but is true, as the xml:lang example can
> testify, as well as the HTML form/input example mentioned by MSM in
> [2], the <alternative> without test attribute in XSDL 1.1, or for
> that matters even ID/IDREF pairs.

XSDL 1.0 provides two design patterns for addressing these cases:
local declarations and the notion of choosing where best to 'stand'.
By the latter I mean our approach to Identity Constraints and the
legacy ID/IDREF types: these are, correctly in my view, described as
determining the validity of the appropriate scoping subtree, not the
immediate locus of one or the other of the items which duplicate or
fail to match.

Local declarations, which enable the tag-type distinction, are a very
powerful way of encapsulating and managing context dependence which
has worked well, as far as I can tell.  Not only in the sForS, but in
major production schemas (judging from my random sample in 2004), this
mechanism gets a lot of use.

So my inclination in looking for ways to address the examples which
currently cannot be handled by XSDL is to look to our existing
architecture.

Lets consider the three cases Fabio mentions.

 1) That last <alternative>: Feels right to me to address this from
    the "where best to stand" perspective -- just as the
    spec. currently states this as a constraint on xs:element, I would
    choose to enforce this in the sForS at that point, with an
    assertion along the lines of

  <xs:assert test="not(xs:alternative[not(@test) and
                                      position() < last()])"/>

  or

  <xs:assert test="every $a in xs:alternative satisfies $a[@test or last()]"/>


 2) HTML form/input: In principle I think again that this is a
    question of where best to stand.  On balance I would rather say
    "x:form defines a scope within which x:input may occur" than
    "x:input must only occur within x:form".  To achieve this within
    XSDL, we would need to allow type definitions to be dynamically
    scoped.  I think that would be a great feature, but not for 1.1
    :-(.  In its absence, I'll say "Either do the hard graft to use
    the local element declaration approach outlined in [1], or accept
    that this is a constraint which XSDL can't express without more
    complexity than you're prepared to accept."

 3) xml:lang: I stated elsewhere [2] that I prefer the defaulting
    approach to this rather than the inheritance approach, but however
    we do it, just implementing inheritance won't allow us to solve
    the problem put to us, i.e. to choose a type for an element based
    on its xml:lang value.  The reason for this is that whichever
    approach we take, we will need to know the type of the element in
    question _before_ we know whether to use the inherited value for
    its xml:lang or not, since that type might itself _specify_ a
    value for that attribute.  But we want to appeal to the value of
    xml:lang to _determine_ the type.  Result: impasse.

    Note that this impasse doesn't go away if we loosen the
    restrictions of looking up the tree when choosing alternatives.

    My preferred solution, which I nearly thought of during our
    initial discussion of tree trimming, would be something along the
    lines of saying that _if_ an element declaration includes an
    explicit value for {type definition}, that

     a) all alternatives must be derived from it and
     b) its attribute declarations are used to type attribute values
        in the XDM which is used for alternative selection.

    I think this idea has independent value, and I hope the group will
    consider it.  It contributes to a solution of the xml:lang
    problem, by allowing the relevant declaration for xml:lang to be
    moved out of the alternatives and into the {type definition}, thus
    breaking the circularity identified above.

[1] http://www.w3.org/2000/04/26-csrules.html
[2] http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2008Jan/0024.html
Received on Wednesday, 23 January 2008 11:40:50 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 6 December 2009 18:13:12 GMT