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

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





------- Comment #16 from noah_mendelsohn@us.ibm.com  2008-01-21 19:53 -------
Michael Kay writes:

> I'm fine having a rule that says "if the language is DE then the currency must
> be EUR". But what is the object to which this rule relates? I don't think it's
> a rule about the validity of the currency, I think it's a rule about the
> validity of some object that contains both a language and a currency.
> 
> Now we could have done this differently, of course. The principle outlined
> above is not an absolute. But it happens to be an assumption that's built
> pretty deeply into QT's adoption of a type system based on XML Schema. When in
> XSLT I do:
> 
> <invoice xml:lang="en">
>   <xsl:copy-of select="$payment" validation="preserve"/>
> </invoice>
> 
> I'm relying on the fact that if the payment was valid in one context, then it
> is going to remain valid in a different context.
> 
> So I don't think there's anything philosophically absurd about the idea that
> the validity of an object should be context-sensitive, I'm just saying that
> changing the rules of the game in this way is going to be unacceptable to two
> of the important stakeholders.

Yes, exactly.

Fabio Vitali writes:

> In fact, that was my point: context-independence of type is more a political
> issue than a technical one, and it is definitely not a design issue.  

I really don't think it's fair to say that.  

I can't speak for others who were involved or for the working group as a whole,
but I think it's fair to say that I was among those who played a significant
role in suggesting [1,2] the "Tag/Type" distinction, and what's now known as
Complex Types.  I can tell you that the ability to use them in the manner that
XQuery later chose to do was intentional on my part in proposing them.  I was
not otherwise involved in the design of XQuery, but as Michael Kay says, they
seem to have used context-independent types in exactly the manner that I (and I
presume others, though perhaps not all others in the working group) expected
when the design for types was proposed.

So, as Michael says, while there are other technically plausible ways that both
XML Schema and/or XQuery could have been designed, I certainly don't think that
makes the decisions political.  As far as I'm concerned, technical trade-offs
were made in the design of Schema.  We bit off the conceptual and design
complexity of separating complex types from element declarations, and we built
a lot of machinery to make them first class abstractions and sufficiently
context-insensitive to use in the manner that Michael describes.  The XQuery
working group decided to use the abstraction in what I consider the manner
intended: I.e. to ensure that one has assignment compatibility between two
"element"s that have the same complex types, and thus to be able to use schema
types for functions, etc.

Surely there are trade0offs embodied in those choices.  I don't think it's fair
to imply that those who made the trade-offs did so for primarily political
reasons.  The costs and benefits are primarily technical, IMO.

Furthermore, as Michael also says:  changing this now would be far more
disruptive than changing it before XQuery had come to depend on it.  I strongly
favor keeping our types context-independent, to the degree that they currently
are.

Noah

Received on Monday, 21 January 2008 19:53:27 UTC