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

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





------- Comment #23 from noah_mendelsohn@us.ibm.com  2008-02-04 21:11 -------
Michael Kay writes:

> I wonder if I can put forward another suggestion:
> parameterized validation.  Currently we say that
> the validity and type of an element depend only on
> (a) the content of the subtree rooted at that
> element, and (b) the input conditions for the
> validation, such as an optional element
> declaration and type. One way forward might be to
> allow additional parameters to the validation, and
> to allow these parameters to be referenced as
> XPath variables in expressions such as the
> alternative and assertion expressions.

> [...]

> This sounds rather beyond the scope of 1.1, but it
> feels to me like an interesting way forward.

Yes, interesting, but definitely beyond 1.1 IMO.  

Beyond that, I have to say that my intuition is still to be quite conservative
about things like this.   One of my conclusions about XML Schema in a
presentation I gave years ago [1] was: "There's no such thing as a simple
feature."  Like so many other things in our language that seem simple in
isolation (e.g. locally scoped elements), I'm concerned that things like this
add conceptual as well as implementation complexity.  In the case of these
parameterized types, I think there's a sense in which we'd now be saying:  a
type now validates not just the subtree to which it applies, but the
combination of the subtree and zero or more parameters.  If I'm building a
databinding system that creates rather than consumes XML, what's my data model?
 Does it include the parameters?  If not, what data do I collect?  Presumably,
if I want the resulting XML to be valid, I need to be able to not just build up
the XML itself, but also the corresponding parameters that will be necessary
for it's validation.  One way or the other, there's significant conceptual and
practical complexity there, at least in some scenarios.

I certainly agree that there are cool things you could do with a system like
this, and so I agree with what I take to be the essence of your proposal:  I.e.
that when and if we start planning the next non-bugfix release of Schema, this
is an interesting idea to consider.  I'm just saying that I can also see
reasons why it might not work out from a cost/benefit point of view.

Noah

[1] http://www.intertwingly.net/slides/2002/devcon/SchemaSecrets.ppt

Received on Monday, 4 February 2008 21:11:13 UTC