Re: [xml-dev] PSVI using existing infoset items

[Eric van der Vlist <vdv@dyomedea.com>]

Hi Francis,

Francis Norton wrote:

> Hi Eric,
> 
> Eric van der Vlist wrote:
> 
>>As a last alternative, it would also be possible (and quite simple) to
>>pass the 2 infosets (source document and PSVI) to a transformation (one
>>as source, the second as a parameter). The way to link a node between
>>the source and the matching information of the PSVI doesn't seem
>>obvious, though, and I don't think it could easily do the trick.
>>
>>
> Yes, the link poses the old join question. I think you'd need something
> like an extension function so that you could get the context node into
> the function as a parameter without changing context, eg
> 
> <xsl:variable name="cantHaveTopLevel_value-of_Elements"
> select="psvi-init(/)" />
> ...
> <xsl:apply-templates select=".//*[psvi-info(.)/@type='xyz:myType']" />


OTH, if we keep it "purely" XML, we have an immediate support from all 
the XSLT processors...


> 
> Apart from unique element names and unique type names, I'd like access
> to:
> 
> [1]	does the current element type inherit from type X?
> 
> [2]	does it inherit from type X purely through extension? (ie would it
> be safe to apply type X templates to this element?)
> 
> [3]	an enumeration of its inheritance tree, if any
> 
> [4] 	its facets, if any
> 
> And I'd like this info to be represented in an easily XPath query-able
> manner.
> 
> Does this sound a reasonable start?


If it needs to be included in the "inline" PSVI, I don't think so! It 
would be both too schema dependent and too verbose IMHO.

It seems to be a reasonable start as the objectives for a "compiled" or 
"normalized" schema more XPath friendly.

The list of information you include seems rather exhaustive, though. I 
guess that appinfo should be included too if we want to be SAF friendly 
and I wonder if we will not end up by including the full schema!

If we need most of the information from the schema in this compiled 
form, there would be a lot of advantages to keep it a valid W3C XML Schema.

This would lead to the definition of a normalized W3C XML Schema which 
would, at least, process all the inclusions and redefinitions and 
include a unique ID in all the component definition, even when they are 
anonymous which are compliant but not mandatory in a schema.

To help XSLT/XPath processing, we could add then add simple XLinks 
between the anotated source document and the schema and within the schema.

If I take back my example:

<foo xmlns:...>
<psvi:element type="complex" datatype="foo" whitespace="false"/>
<bar>
<psvi:element type="simple" datatype="xs:string"
          primary="xs:string"
          minOccurs="0" maxOccurs="unbounded" whitespace="false"/>
...</bar>
</foo>

This could become (just thinking aloud):

<foo xmlns:...>
  <psvi:element contentModel="elementOnly">
   <psvi:schemaDefinition
     xlink:type="simple" xlink:href="normalized.xsd#id1"/>
   <psvi:datatype ref="foo"
     xlink:type="simple" xlink:href="normalized.xsd#id2"/>
  </psvi:element>
<bar>
  <psvi:element contentModel="simple">
   <psvi:schemaDefinition
     xlink:type="simple"
     xlink:href="normalized.xsd#id2"/>
   <psvi:datatype ref="xs:string"
     xlink:type="simple"
     xlink:href="normalizedSchema4schema.xsd#string"/>
  </psvi:element>
...</bar>
</foo>

and the normalized schema could be:

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <xs:element name="foo" type="foo" id="id1"/>
  <xs:complexType name="foo" id="id2">
   <xs:sequence>
    <xs:element id="id3" name="bar" type="xs:string"
      minOccurs="0" maxOccurs="unbounded"/>
   </xs:sequence>
  </xs:complexType>
</xs:schema>

The processing using a XSLT processor fully supporting the XML media 
types (and thus XPointer when it will be a rec) could use the document 
function, for instance "document(psvi:datatype/@xlink:href)" to access 
to the datatype definition of the current element.

In a schema, references could also be defined as simple links (W3C XML 
Schema allows attributes from other namespaces) to help their processing.

For instance, the first element reference could become:

  <xs:element name="foo" type="foo" id="id1"
      xlink:type="simple" xlink:href="#id2"/>

but this would catch the difference between <xs:element ref="..." ...> 
and <xs:element type="..." ...> and it should probably be better 
normalized as:

  <xs:element name="foo" id="id1">
   <xs:complexContent>
    <xs:complexType id="id4">
     <xs:extension base="foo"
        xlink:type="simple" xlink:href="#id2"/>
    </xs:complexType>
   </xs:complexContent>
  </xs:element>

This example is far from being generic and the analyzis just superficial 
(for instance I haven't checked these schemas), but I think it gives a 
better idea of what I have in mind when I am speaking of "XPath/XSLT 
friendly normalized" schema!

Eric


> Francis.
> 


-- 
Rendez-vous à Paris pour le Forum XML.
                    http://www.technoforum.fr/Pages/forumXML01/index.html
------------------------------------------------------------------------
Eric van der Vlist       http://xmlfr.org            http://dyomedea.com
http://xsltunit.org      http://4xt.org           http://examplotron.org
------------------------------------------------------------------------