Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: PSVI using existing infoset items
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
------------------------------------------------------------------------
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
