Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Objections to / uses of PSVI?
Ron,
> That's one reason that I asked how people intended to use the PSVI.
> I find it interesting that the answer has, so far, been silence.
I can think of three ways in which I'd like to use information
available in the PSVI within XSLT:
1. I'd like to be able to have a template that matches all elements in
a certain group, for example "all block elements". Mostly those groups
should be formed around substitution groups, but all elements in that
group having the same type would be another way of doing it.
Here's a real-world example. I have some document-oriented XML in
which things like lists and block quotes can be embedded within
paragraphs, and I want to transform it to HTML, where that's not
allowed. With vanilla XML+XSLT 2.0, I can do something like:
<xsl:function name="my:is-block-element">
<xsl:result select="self::orderedList | self::unorderedList |
self::definitionList | self::blockquote |
..." />
</xsl:function>
<xsl:template match="para">
<xsl:for-each-group select="node()"
group-adjacent="my:is-block-element()">
<xsl:choose>
<xsl:when test="my:is-block-element()">
<xsl:apply-templates select="current-group()" />
</xsl:when>
<xsl:otherwise>
<p>
<xsl:apply-templates select="current-group()" />
</p>
</xsl:otherwise>
</xsl:choose>
</xsl:for-each-group>
</xsl:template>
I'd like the fact that the various "block-level" elements were
"block-level" elements to be something recorded declaratively, in a
schema, rather than procedurally, as code. Importantly, the assignment
of "block-level" status is something that's only relevant in the
context of this transformation to HTML. If I was transforming to
DocBook, for example, there might be a different classification.
2. Schemas seem like a good place to store information that's used
across transformations, such as the mapping between codes and full
values. I'd like to have access to the PSVI so that I can have access
to the contents of appinfo elements from within the stylesheet. I gave
the following example on XSL-List yesterday:
<flavour>CHC</flavour>
and:
<xs:element name="flavour" default="VNL">
<xs:simpleType>
<xs:annotation>
<xs:appinfo>
<flavour code="VNL">Vanilla</flavour>
<flavour code="CHC">Chocolate</flavour>
<flavour code="MNT">Mint</flavour>
<flavour code="CFE">Coffee</flavour>
</xs:appinfo>
</xs:annotation>
<xs:restriction base="xs:token">
<xs:enumeration value="VNL" />
<xs:enumeration value="CHC" />
<xs:enumeration value="MNT" />
<xs:enumeration value="CFE" />
</xs:restriction>
</xs:simpleType>
</xs:element>
leading to the text:
Your favourite ice cream is Chocolate
3. I'd like keys to get automatically set up based on the identity
constraints in the PSVI. Rather than having to write:
<xsl:key name="lessons"
match="lesson"
use="concat(generate-id(parent::class), '+',
@date, '+', subject)" />
I'd like to have the following in the schema:
<xs:element name="class" type="classType">
<xs:key name="lessons">
<xs:selector xpath="lesson" />
<xs:field xpath="@date" />
<xs:field xpath="subject" />
</xs:key>
</xs:element>
This is particularly because it's easy to scope keys in XML Schema
whereas it's pretty fiddly with XSLT; also because XML Schema keys
have multiple fields.
Cheers,
Jeni
---
Jeni Tennison
http://www.jenitennison.com/
|
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
|
|||||||||
