OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] Objections to / uses of PSVI?

[ 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.


Tom P


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS