Re: Types and Context

[Jeni Tennison <mail@jenitennison.com>]

Hi Gavin,

>> Yes.  If you use an entity then you have to edit the stylesheet and
>> the schema; if you have a type-checking mechanism, you only have to
>> edit the schema. 
>
> ... and if you change the schema, surely your processing logic would
> likely need some changes too?

It depends on the application. For example, there is a class of
stylesheets that don't depend on the XML vocabulary that they're used
with - used to give pretty or editable displays of XML or whatever -
that could use type information to determine how an element/attribute
would be best displayed/edited.

Or take phone numbers for example.  I might have a type:

  <xs:complexType name="my:phone-number">
     <xs:element name="international-code" type="xs:integer" />
     <xs:element name="area-code" type="xs:integer" />
     <xs:element name="number" type="xs:integer" />
  </xs:complexType>

And a generic way of displaying elements of that type (I'm assuming
that elementFormDefault was set to 'qualified' here):

<xsl:template match="*[xs:type('my:phone-number')]">
   <xsl:text />+<xsl:value-of select="my:international-code" />
   <xsl:text /> (<xsl:value-of select="my:area-code" />) <xsl:text />
   <xsl:value-of select="my:number" />
</xsl:template>

(perhaps with different modes to give different types of formatting or
whatever)

When someone creates a new vocabulary that uses my schema, they will
probably find the XSLT useful as well. I think that if they
reuse/refer to my:phone-number then they should be able to use the
same XSLT template without editing the match pattern.

>> My point is that as an XSLT application developer, I could write a
>> stylesheet that people would not have to touch even if they
>> extended/amended the schema.
>
> I doubt this is true in anything except fairly trivial cases, and for
> those cases, you could more than likely write an equivalent XPath/mode
> based stylesheet.

OK, perhaps I should amend my bald statement... obviously, if someone
wanted special treatment for the new components that they add to the
schema, then they will have to write their own code for that. But if I
have templates that are based on element types rather than element
names, then they are much better able to reuse those templates to
process elements of those types.

I agree that you could write an equivalent match pattern for the
above.  If you were being strict about it, it would look like:

  *[*[1][self::my:international-code] and
    *[2][self::my:area-code] and
    *[3][self::my:number] and
    not(@* or *[4] or text()[normalize-space()])]

But making the content model more complicated - if I were to make
my:international-code optional, or add some limits on the values that
it can take, for example - would add a lot of complexity to the
pattern. As you said in another email, complex match patterns are bad
news for XSLT processors, so this is something we want to avoid.

I think you make a very good point about using modes as an extensible
way of getting type-ish-based processing. I could have:

<xsl:template match="home | mobile">
   <xsl:apply-templates select="." mode="my:phone-number" />
</xsl:template>

<xsl:template match="*|@*" mode="my:phone-number">
   ...
</xsl:template>

in my stylesheet; when someone else added a 'work' element, they need
only add:

<xsl:template match="work">
   <xsl:apply-templates select="." mode="my:phone-number" />
</xsl:template>

to reuse the phone number template. My only issue with this is the
manual labour involved in making sure the schema and the XSLT are in
sync. It would be nice if, when I changed the type of the 'mobile'
element in the schema, it was automatically reflected in the XSLT.
Possibly this is a way to go, though - use the XML Schema to create a
stylesheet with default templates for all the elements that it
defines, applying templates using the type as the mode, import that,
and add overriding templates for type-based behaviour... hmm...

Cheers,

Jeni

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