RE: Serialization (sometimes) needs to include type information

> The current rule is that if you want xsi:type attributes, you generate
> them yourself. Is that too difficult in your situation?
>

Well, it is a syntax issue: I would need to replace an very simple
expression such as doc("myDoc")//C (or $x//C) with something like

for $x in doc("myDoc")//C
return
typeswitch($x)
case $a as element(*, ns1:Type1) return <C
xsi:type="ns1:Type1">{$x/@*}{$x/*}</C>
case $a as element(*, ns1:Type2) return <C
xsi:type="ns1:Type2">{$x/@*}{$x/*}</C>
... (as many as there are possible types)


A bit clumsy, no? Having a function returning the type of the element would
make things a little bit easier, but not that much.

> Asking the serializer to do this could get very complicated. For
> example, as well as generating the xsi:type attribute it would have to
> generate namespace declarations for it;

Declaring appropriate namespaces in the prolog could be left to the user,
but in general the schema defining the source datatypes would already be
imported and thus already present in the in-scope namespace and prefix list

> there would need to be rules
> about what happens if there is already an xsi:type attribute;

I would say nothing: if the type information is already present, we don't
need to have it once more.

> there
> would need to be some kind of rules about which elements require an
> xsi:type attribute (no-one, surely, would want one on *every* element);

My suggestion would be to use something similar to the
cdata-section-elements in the serialization to control the set of elements
for which this is needed.

> and there would need to be rules to handle the common case where the
> most specific type is anonymous.

Right, a common portable way to refer to anonymous types would be required.
However, there is already someting similar in the XQuery syntax, namely the
SchemaContextPath, which can retrieve any local declaration, and thus any
type associated to them.

>
> Also, xsi:type is only half a solution. It solves the problem for
> elements but not for attributes. I'm not keen to make a lot of effort to
> solve half the problem.
>

In the case of attributes, the problem is easier, because we are only
talking about simple types (while in the element case, both simple and
complex types can be involved). In such as case, it is possible to define a
simple type as the union of all the involved simple types, so no particular
support from the serialization would be required.

Antoine Mensch

> Michael Kay (speaking personally)
>
>

Received on Wednesday, 11 February 2004 08:37:52 UTC