- From: <bugzilla@wiggum.w3.org>
- Date: Wed, 23 Jan 2008 11:40:36 +0000
- To: www-xml-schema-comments@w3.org
- CC:
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 UTC