- From: Philip Wadler <wadler@research.bell-labs.com>
- Date: Tue, 23 May 2000 15:11:47 -0400
- To: Noah_Mendelsohn@lotus.com
- cc: www-xml-schema-comments@w3.org
Noah gives a particular encoding of an oo language into XML. He then asks: > So, I am a little confused by your concern > that "it is very difficult to fit xsi:type into existing type systems". Fair point. Indeed, as you show, xsi:type provides an appealing way to encode objects in an oo type system into xml (a similar encoding is used in SOAP). In retrospect, perhaps I should have omitted the Java examples from my message, as they are slightly beside the point. My real worry is that I don't know how to incorporate xsi:type into type systems like that used in Xduce, or the type system we are working on for the Lucent-ATT algebra proposal. I've been trying to think of a way to do so, but so far no luck. I'm fairly certain that it cannot be done in a general way. It may be doable by treating xsi:type differently from all other attributes, I'm not sure. At worse, this means that we won't know how to do a useful and simple type system for a query algebra. At best, it means that any complexity in Schema would end up leading to similar complexity in a type system for the query algebra. > Again, xsi:type does represent a layer of complexity and some added power. > Whether it is on balance apprioriate is a good question. On the other > hand, it was added exactly because it does model certain reasonable idioms > for modeling existing type systems. I feel like I'm missing something. At first blush it looks contradictory, but I don't think it is. As you say, xsi:type was added to make it easier to model oo type systems in xml, and it increases the power of xml at the expense of adding some complexity. That complexity shows up, among other places, in a more complex type system for xml itself. -- P
Received on Tuesday, 23 May 2000 15:12:06 UTC