xml:type (Was: Re: [xml-dev] ten years later, time to repeat it?)

["Pete Cordell" <petexmldev@codalogic.com>]

Summarizing my latest thoughts on the 'xml:type' issue, I, at least, get a 
bit confused when people talk about 'typed' data.

So if people that say they don't like typed data mean that they prefer:

    <foo>123</foo>

to:

    <foo><int>123</int></foo>

(or similar) then I agree.  If a device (maybe a human one!) doesn't know 
how to process a <foo>, then knowing it's an int is probably not going to 
help it much.  (Does anyone think this is the wrong way to look at it?  If 
so, why?)

I do think it's very important to be able to specify what type a <foo> is, 
e.g. to say <foo> is an int, and maybe the max and min values etc.  Being 
able to validate that it is what it's supposed to be at a fairly automated 
low level is also very handy.  How you specify that is less important, but 
given that it's an interoperability issue, it makes sense that the method 
you use is widely understood and supported.

The use-case I was initially interested in for having xml:type is the case 
of XSD polymorphic complex types (c.f. OO polymorphism).  I agree though 
that this is a pretty grim use-case.  xsi:type is also often used as some 
form of poor man's co-constraint (and I agree there are often better ways 
that this could be done).  If XSD1.1 supports co-constraints, maybe the rare 
use-cases for xsi:type will reduce further.

As a result I agree that it shouldn't be promoted to a first class citizen, 
even if it is a dog to implement as it is (at least for data binding).

Cheers,

Pete Cordell
Codalogic
For XML C++ data binding visit http://www.codalogic.com/lmx/

----- Original Message ----- 
From: <noah_mendelsohn>
To: "David Carver" <d_a_carver>
Cc: "Pete Cordell" <>; "Robin Berjon" <>; "XML Developers List" <>
Sent: Thursday, February 21, 2008 4:39 AM
Subject: Re: [xml-dev] ten years later, time to repeat it?


> David Carver writes:
>
>> Personally, I HATE xsi:type. In most B2B scenarios I've been involved
>> with it causes more interoperability issues then it solves.
>
>> I'd much rather get rid of XML type, and force people to validate
>> against the  schema as is
>
> Schema types (which I'm guessing is what you mean by XML type) and
> xsi:type aren't at all the same thing.  If you get rid of Schema types,
> then you can't say "this element must contain an Integer".  Is that the
> complication you're trying to avoid?  If so, yes, you should argue against
> Schema types.
>
> If you're arguing against xsi:type, I can certainly understand that.  It's
> the wrong thing in >90% of use cases (probably way more, but I'm just
> guessing and trying to be conservative), and it makes a mess of instance
> documents.  It was introduced because some members of the Schema WG were
> very anxious to handle serialization of object graphs, I.e. to do what
> Java Object Serialization (used by RMI) does.   SOAP Encoding is an
> example of such XML-based object serialization, and it uses xsi:type.
> Indeed, because of dynamic subtyping, it's generally the case that the
> serialization formats for such systems must carry for each item both its
> name and its type.  Go read through the format spec. for Java Object
> Serialization and you'll see that's the core of it.  In XML with schema,
> you can use the tag for the name, and xsi:type for the type.
>
> Personally, I'm not convinced that supporting that scenario should have
> made an 80/20 cut for schema, but as happens on a big committee, some
> people argued very strongly for it.  You can, of course, turn it off by
> using suitable "block" attributes at the right points in your schema.
> While that pretty much ensures that your instances are clean (I think
> xsi:type is still allowed for better or worse, but it can't then designate
> a type other than the one your element would have had anyway, as I
> recall), but it's a nuissance in the schema.
>
> Noah
>
> --------------------------------------
> Noah Mendelsohn
> IBM Corporation
> One Rogers Street
> Cambridge, MA 02142
> 1-617-693-4036
> --------------------------------------
>
>
>
>
>