RDDL and types. Re: Types and Context

[Jonathan Borden <jborden@mediaone.net>]

Let me try to address a couple of issues regarding types and the PSVI and
propose an example of an implemention of the typeOf function which makes use
of RDDL.

There are several ways to implement the "typeOf" function.

1) The "typeOf" function might be implemented on top of an internal PSVI, as
a way to provide access to the type adornments. This assumes the schema
validator has preprocessed a document instance.

2) The "typeOf" function might be implemented in a lazy fashion, testing a
node against a type specification only when encountered.

There are also several ways to gain access to the PSVI

1) one can implement an interface which has methods like "typeOf" which
tells us whether the node matches the type.

2) one can 'expand' the input XML into an XML representation of the PSVI has
below.

For example one might construct a SAX Filter than implements XML Schema by
expanding the input events into the adorned and expanded output events (lots
of new events). An XSLT processor would accept the PSVI input events and
perform the transform on these, not the original SAX events.

One might _implement_ XML Schema as an XSLT stylesheet, providing the XML
below as a function of an input document and a schema. One might 'compile' a
particular XML schema into a particular XSLT stylesheet that transforms an
input document into the XSV representation below (for example).

This issue is that an entirely _new_ XSLT implementation is needed that
accepts this PSVI expansion of an XML document as input. Of course this can
be done, but the example below shows how complicated this is (and I imagine
not very efficient either).

How might RDDL help?

An implementation of typeOf(typename) ... and this is just a suggestion ...
might 'look' in the namespace URI of the node (for an element) or the
enclosing element (for an attribute) for resources with purposes:
http://www.rddl.org/purpose#schema-validation or possibly
http://www.rddl.org/purposes#type-specification and collect the set of
schemata.

Alternatively an "xsi:schemaLocation" can be checked.

Using something like the new Xerces-J schema interfaces the schemata would
be parsed into a "validator factory". From the factory a DatatypeValidator
interface is obtained for the datatype (see
http://xml.apache.org/xerces-j/apiDocs/org/apache/xerces/validators/datatype
/DatatypeValidator.html). Presumably if a type is not found in one schema,
another could be checked until a sufficient validator is discovered.

The node is tested for validity against this validator. In the schema
algebra _this is the same thing_ as being an instance of a type. This if the
node is valid, typeOf returns true.

This doesn't require implementation of a new XSLT engine.

-Jonathan




> On 23 May 2001 10:17:52 +0100, Jeni Tennison wrote:
> > > Sure thing.  Now do that with <foo myInt="123"/> and tell me what it
> > > looks like.
> >
> > For interest, using the PSVI output from XSV 1.2, it looks roughly
> > like:
> >
> >   <element xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'
> >            xmlns='http://www.w3.org/2001/03/XMLInfoset'
> >            xmlns:psv='http://www.w3.org/2001/03/XMLSchema-infoset'>
> >     <namespaceName xsi:nil='true'/>
> >     <localName>foo</localName>
> >     <prefix xsi:nil='true'/>
> >     <children/>
> >     <attributes>
> >       <attribute>
> >         <namespaceName xsi:nil='true'/>
> >         <localName>myInt</localName>
> >         <prefix xsi:nil='true'/>
> >         <normalizedValue>123</normalizedValue>
> >         <specified>true</specified>
> >         <attributeType xsi:nil='true'/>
> >         <references xsi:nil='true'/>
> >         <psv:validationAttempted>full</psv:validationAttempted>
> >         <psv:validationContext>
> >           <pointer ref='g1'/>
> >         </psv:validationContext>
> >         <psv:validity>valid</psv:validity>
> >         <psv:schemaErrorCode xsi:nil='true'/>
> >         <psv:schemaNormalizedValue>123</psv:schemaNormalizedValue>
> >         <psv:schemaSpecified xsi:nil='true'/>
> >         <psv:typeDefinition>
> >           <pointer ref='xsd:type.integer'/>
> >         </psv:typeDefinition>
> >         <psv:memberTypeDefinition xsi:nil='true'/>
> >         <psv:declaration>
> >           <pointer ref='attr.myInt.9'/>
> >         </psv:declaration>
> >       </attribute>
> >     </attributes>
> >     <namespaceAttributes/>
> >     <inScopeNamespaces>
> >       <namespace>
> >         <prefix>xsi</prefix>
> >
<namespaceName>http://www.w3.org/2001/XMLSchema-instance</namespaceName>
> >       </namespace>
> >       <namespace>
> >         <prefix>xml</prefix>
> >
<namespaceName>http://www.w3.org/XML/1998/namespace</namespaceName>
> >       </namespace>
> >     </inScopeNamespaces>
> >     <baseURI>file:/C:/temp/test.xml</baseURI>
> >     <psv:schemaInformation xsi:nil='true'/>
> >     <psv:validationAttempted>full</psv:validationAttempted>
> >     <psv:validationContext>
> >       <pointer ref='g1'/>
> >     </psv:validationContext>
> >     <psv:validity>valid</psv:validity>
> >     <psv:schemaErrorCode xsi:nil='true'/>
> >     <psv:schemaNormalizedValue xsi:nil='true'/>
> >     <psv:schemaSpecified xsi:nil='true'/>
> >     <psv:typeDefinition>
> >       <pointer ref='type._anon_11'/>
> >     </psv:typeDefinition>
> >     <psv:memberTypeDefinition xsi:nil='true'/>
> >     <psv:declaration>
> >       <pointer ref='elt.foo.12'/>
> >     </psv:declaration>
> >     <psv:nil>false</psv:nil>
> >     <psv:notation xsi:nil='true'/>
> >     <psv:idIdrefTable xsi:nil='true'/>
> >     <psv:identityConstraintTable xsi:nil='true'/>
> >   </element>
>
> I knew that was _an_ answer, but I can't say I consider it practical or
> useful, except as an illustration of how far off the deep end XML Schema
> 1.0 has gone with (what I see as) a misguided approach to defining the
> world through types.
>
> Remember those people who think XML is already way too verbose?
>
> Makes me downright nostalgic for Datatypes for DTDs (DT4DTD):
> http://www.w3.org/TR/dt4dtd
>
> yields:
> <foo myInt="123" a-dtype="myInt int"/>
>
> > The pointer elements refer to XML representations of the
> > element/attribute declarations included further down the XML
> > representation, which may point to global type representations, or
> > have anonymous ones nested within them. There are also pointers
> > indicating the base type of each type, so you can follow the
> > type hierarchy.
>
> Yes, but I can't say I've ever found this information worth the
> complexity cost.  Feature for some, inflicted on many.
>
> > The PSVI XML output from XSV always contains XML representations of
> > all the built-in XML Schema data types, so it's always very long, but
> > it's quite cool for seeing exactly how XSV is interpreting your XML.
> > And of course it would be possible to use it as input to a
> > stylesheet...
>
> But it's damn near worthless for interchange.  Usable, but verbose even
> by XML standards.  Thanks for presenting it, but all it does for me is
> illustrate once again how ugly the problem is.
>
>