[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Types and Context

• From: Jeni Tennison <mail@j...>
• To: Jonathan Borden <jborden@m...>
• Date: Tue, 22 May 2001 15:41:41 +0100

Hi Jonathan,

[cross-posting to list@e... - suggest we follow up there]

> no the intention is an extension function taking two arguments
>
>   typeOf(node,typeQname)

OK. We'd have to use a node-set as the data type for the first
argument. I guess the intention would be that it would only operate on
the first node in the node set, though?  Or should it return true only
if all the nodes were of that type?

> note that this assumes there is some 'active' schema present. one
> could more generally do:
>
>         typeOf(node, typename, schema)

Do you intend the schema in the above to be a node-set or a string
indicating a document? I think that indicating a node-set would be
more flexible, given that you could then generate a schema within the
stylesheet itself and then use it.  Plus it means that we wouldn't
have to add a fourth optional argument equivalent to document()'s
second argument.

> and note that the 'schema' need not _only_ be an XML Schema, for
> example one might have a simple XSLT file:
>
>         <xsl:variable name="person.type">
>                 father|mother
>         </xsl:variable>

In that case, there should probably be a fourth argument that
indicates the (specification of a) schema syntax that should be used
in interpreting the schema indicated by the third argument. Following
the model of other XPath/XSLT functions, this should be a qualified
name.  And we'd need to define behaviour if the XSLT processor itself
couldn't interpret schemas of that type...

>> Anyway, I thought this syntax for xs:type() gelled well with the way
>> that lang() works in XPath at the moment. Another possibility for the
>> same kind of extension function would be:
>>
>>   match="*[xs:type() = 'this:person']"
>
> that doesn't work because a node may have many types.

Good point, although it could feasibly return a node set of nodes
whose string values were the various types for the node given in the
argument (here I assumed that . was the default argument to xs:type),
in which case it would work as a kind of type axis (xs:type()[1]
indicates the node's type, xs:type()[2] that type's super-type and so
on).

Cheers,

Jeni

---
Jeni Tennison
http://www.jenitennison.com/

• References:
  • RE: Types and Context
    • From: Jonathan Borden <jborden@m...>

• Prev by Date: Re: Types and Context
• Next by Date: Re: Namespace: what's the correct usage?
• Previous by thread: RE: Types and Context
• Next by thread: RE: Types and Context
• Index(es):
  • Date
  • Thread