[
Lists Home |
Date Index |
Thread Index
]
At 06:31 PM 5/9/2002 +0100, Jeni Tennison wrote:
> > Would you really suggest using *none* of the type operators, or are
> > there some that you think would be worthwhile if they were easy to
> > implement? I suspect that any XSLT processor that has access to the
> > PSVI would find 'treat' and 'cast' reasonably easy to implement -
> > 'cast' requires facet checking, but this amounts to about 10
> > relatively simple functions.
>
>Let me see if I can describe what I think each of these expressions
>are supposed to do; after all, I might be misinterpreting what they're
>supposed to be useful for.
>
>First, "instance of". I think that "instance of" meets the requirement
>of being able to select elements based on their type, which is
>something listed in the XPath 2.0 Requirement document. So I think
>that this is worthwhile.
Yes, basically. More precisely, it determines whether a node or value is of
a given type.
>On the other hand, I think it should be based
>on named typing rather than structural typing, firstly because I think
>that's simpler for implementers (they can look at the PSVI to work out
>whether one type is derived from another) and secondly because I think
>it would be frustrating for users if they don't have control over what
>types count as subtypes of each other.
As of the latest XQuery 1.0 WD, it *is* based on named typing, and supports
derived types.
>For example, if I have the
>following two element declarations:
>
><xs:element name="address" type="addressType" />
><xs:complexType name="addressType">
> <xs:sequence>
> <xs:element name="line" type="xs:string" />
> </xs:sequence>
></xs:complexType>
>
><xs:element name="poem" type="poemType" />
><xs:complexType name="poemType">
> <xs:sequence>
> <xs:element name="line" type="xs:string" />
> </xs:sequence>
></xs:complexType>
>
>then if I do:
>
><xsl:template match="*[. instance of element of type addressType]">
> ...
></xsl:template>
>
>then I want to select those elements of the addressType, not the
>poemType. The structure of addressType and poemType might be the same,
>but they do not have the same semantics.
Ah, so you are using the Boolean test in a filter. That's a good way to use
it for the goal you wish to achieve.
>Second, the "cast" operator. From what I can tell, cast is used to
>cast one simple type to another simple type.
Yes.
[ !!! SNIP !!! ]
>The question is whether we'll ever need to explicitly convert a value
>to other kinds of values. I can think of potential use cases, but
>neither are compelling:
>
> - to print out the canonical representation of a particular data
> type (but then there should be format-number() and format-date()
> etc. functions for them)
>
> - to test whether a node is of a particular type (but then there's
> the "instance of" expression for that)
>
>I haven't yet seen a good use case, and unless there is one I think
>that cast should be omitted.
Hey, anybody got a compelling use case for cast in XPath 2.0?
>
>Now onto the difficult ones, "treat" and "assert". From what I can
>tell, "treat" states that the type of a node or value is a supertype
>of a given type, whereas "assert" states that the type of a node or
>value is a subtype of a given type. The only benefits that I can see
>from these is that it means the processor might reject certain things
>during compilation (and as above I think that this should be done by a
>separate tool), and that explicitly casting one complex type to
>another enables optimisation etc.
Well, sort of.
Here's the basic intuition: assert as wants to guarantee, at static
analysis time, that an expression will always return an instance of the
required type. Let's say we have the types Person, Surgeon, and
BrainSurgeon. If the required type is Surgeon, but the computed type of an
expression is Person, assert fails, because some people are not surgeons.
At run time, if static analysis has been done, there is no need for assert
as to do anything at all, so it is a no-op. Of course, if the
implementation does not do static analysis, there is still work to be done.
Assert is not willing to take any chances, and leaves nothing to be done at
run time.
Treat is similar, but treat is more open minded. If the required type is
Surgeon, and the computed type of the expression is Person, treat says,
"well, some people are surgeons, after all, let's wait and see." At run
time, it looks at the instance, and returns the error value if the instance
is not a surgeon.
Does that help?
>I looked for use cases for these in the XQuery document to try to see
>where it might be helpful. There isn't a use case that involves
>"assert"; the use case for "treat" seems to be that it prevents the
>processor from complaining when you try to access a child node that,
>according to the schema, shouldn't be present for a node of a
>particular supertype. Since I don't think XSLT processors should be
>raising errors in those kinds of situations anyway, I don't see the
>point of supporting either of these expressions.
That's pretty clear cut.
>Finally, "validate", which takes the result of an expression and
>validates it, usually in some context. Again there's no use case in
>the XQuery Use Cases document, so it's hard to tell how the WGs are
>imagining this will be useful. The only thing that I can think of is
>that this is a way of adding default values to elements and attributes
>that you generate; but then, if you're generating those nodes, surely
>you can indicate what type they are when you generate them rather than
>taking an extra step to do so? So again, I don't see any reason for
>validate to be present in XSLT, but there might be one that I'm not
>aware of.
I take your point on validate. Actually, several use cases have been used
to develop this proposal, and it would be helpful to add them to our use
cases document. I was a bottleneck on the latest release of the use cases
document, and I just didn't have time for new material. We should consider
this for the next cycle, I think.
Jonathan
|
