Re: Objections to / uses of PSVI?
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/
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