[
Lists Home |
Date Index |
Thread Index
]
Jeni Tennison wrote
> 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.
>
This one seems to ask for embedding a schema within the stylesheet that the
stylesheet would use, rather that using the external schema. After all, as
you said, another time you might want to use a different classification.
Maybe that would not be something specified in the original schema (perhaps
an anonymous complex type. for example).
> 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:
>
I can see #2, but is that appinfo data going to be in the PSVI? If not,
there's not any way to get access to it, is there? I thought the PSVI was
going to hold type info and validation status.
>
> 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.
>
This one makes sense to me, if there is going to be a way for the processor
to actually use the Schema key definition to build a key.
Cheers,
Tom P
|
