[
Lists Home |
Date Index |
Thread Index
]
Hi Tom,
>> 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).
Yes, absolutely. It means that I want access to *a* PSVI generated
from a document with *a* particular schema, not *the* PSVI generated
from a document with *the* particular schema.
>> 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.
It depends on what you mean by PSVI (oh dear...).
Taking a small example, if you have an element 'foo', then one of the
PSVI properties for the element information item for that element is
its element declaration. This property holds (in XML Schema speak) an
"item isomorphic to" the element declaration that's been used to
assess the validity of the foo element.
The element declaration information item has a number of properties
(e.g. name, value constraint, abstract), one of which is annotation.
The annotation property holds an annotation information item, which
has the properties application information, user information and
attributes. The application information property holds the element
information items for the elements held within the xs:appinfo element
within the schema.
There are similar annotation properties on most of the schema
components; schema components are part of the PSVI -- they have to be
because otherwise there wouldn't be a way for applications to figure
out whether a particular type was derived from another type.
It appears to me that when people talk about the PSVI they tend to
focus on the augmentations made to the element and attribute
information items, neglecting the huge raft of other information
that potentially comes from the schema.
And now that the PSVI is being used to construct the XQuery/XPath 2.0
data models, there's another version of "PSVI", which is the subset of
information that is used within the XQuery/XPath 2.0 data models.
The XQuery/XPath 2.0 WD (not the data model WD) talks about the
"in-scope schema definitions" being available as part of the static
context; they would come from the PSVI too, though its not clear at
the moment what subset of the schema definitions (types, element and
attribute declarations, group and attribute group definitions etc.)
will be included in XPath 2.0. (You need quite a lot to support
addressing of local element declarations, which might be nested within
complex type definitions within element declarations within group
definitions.) They would *potentially* allow access to application
information, but somehow I doubt that it's going to be supported.
>> 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.
Quite -- it involves changing keys so that the key value is a sequence
rather than a string, but for backward compatibility with XSLT 1.0 I
guess you won't be able to create such keys *except* automatically
from a schema. Otherwise I don't *think* there's a particular problem
with translating XML Schema keys across, but I may be wrong.
Cheers,
Jeni
---
Jeni Tennison
http://www.jenitennison.com/
|
