RE: Serialization (sometimes) needs to include type information

>
> First, you need to give us some more information about the in-scope
> schema components and validation mode for your query.
>
I would like to have an in-scope schema component allowing me to validate
(so I assume strict or lax validation) the "result" element and construct a
PSVI that will contain the same (or equivalent) type information as the
source data. What I am trying to express is that I cannot write such  valid
complex type, due to restrictions in the schema specification (elements with
the same name must have the same type in a given content model).

> Assuming that you imported the two elements below, have the document
> typed with the information and have lax validation mode, then your
> result would be an element result of type xdt:untyped since it could not
> find a definition in the schema components for the result element. This
> then also means that the C elements will be untyped and not preserve
> their original type.
>

Yes, I understand that. The point is that I cannot write such a schema
component for the "result" element.

> So your example does not convey the semantics that you assume it does
> and does not require a type serialization.
>

I hope the above clarifies why it does require type serialization.

> Also note that XML is primarily late typed data: You have the
> self-describing XML document and you associate type information after
> creation of a document. Thus, mandating the serialization of type
> information and thus making the document early typed seems contrary to
> the general XML philosophy.
>

It seems to me that the xsi:type attribute (which I think is not contrary to
the general XML philosophy) has been introduced for exactly that purpose.

In addition, consider the following extract from the Data Model spec (§4):
"Constructing an Infoset from an instance of the data model, for example in
order to perform schema validity assessment, is accomplished by serializing
the document and parsing it. Implementations are not required to implement
this process literally, but they must obtain the same result as if they
had."

This is impossible if we cannot specify the types of each individual C
elements in the result (though xsi:type).

Best regards,

Antoine Mensch

> > -----Original Message-----
> > From: public-qt-comments-request@w3.org [mailto:public-qt-comments-
> > request@w3.org] On Behalf Of Antoine Mensch
> > Sent: Wednesday, February 11, 2004 12:23 AM
> > To: public-qt-comments@w3.org
> > Subject: Serialization (sometimes) needs to include type information
> >
> >
> > Consider the following schema fragment:
> >
> > <xs:element name="A">
> > 	<xs:complexType>
> > 		<xs:sequence>
> > 			<xs:element name="C" type="myns:Type1"/>
> > 		</xs:sequence>
> > 	</xs:complexType>
> > </xs:element>
> >
> > <xs:element name="B">
> > 	<xs:complexType>
> > 		<xs:sequence>
> > 			<xs:element name="C" type="myns:Type2"/>
> > 		</xs:sequence>
> > 	</xs:complexType>
> > </xs:element>
> >
> > Now if we consider a document (or any other data source) containing
> both A
> > and B elements, the following query
> >
> > <result>
> > { 	for $x in doc("myDocument")//C
> > 	return $x
> > }
> > </result>
> >
> > returns a result that cannot be strongly typed without losing type
> > information by any valid schema, as the schema spec forbids elements
> with
> > the same name and a different type in the same content model.
> >
> > It seems to me that the only way of retaining type information would
> be to
> > annotate produced C elements with xsi:type. This could be a
> serialization
> > parameter, similar to the cdata-section-elements. However, this would
> > raise
> > another issue, as anonymous type names would then be exposed, and
> would
> > thus
> > require to be handled in a consistent way by different XQuery and XML
> > Schema
> > processors.
> >
> > This issue is important, especially for tools that perform distributed
> > XQuery processing, and that need to retain consistent type information
> > when
> > moving XML data from one processing node to another.
> >
>
>

Received on Wednesday, 11 February 2004 03:48:09 UTC