Re: XSL-optimized DTDs (Was: Re: Mixed content: selecting cu

>O indeed. This is the sort of reason why my 6-month-old DTD is already up
>to version 3.0 :).


:-)

[...]
> with those exceptions, mixed content really does
>seem to induce logical difficulties downstream.
>
>Similarly, it's beginning to seem a mistake to define first-level children
>which may occur multiple times, *without* enclosing them in their own
>container/wrapper parents, at least when the data are intended for XSL
>transformations to rendering.


There's always a choice to be made as to where you draw the line between
implicit structural markers that a human (and possibly an application)
understands and explicit markup that an XML processor can deal with.

Consider <Name>John E. Simpson</Name> and <Date>15/03/99</Date> where the
content has an implicit structure that is opaque to XML (although the
element type and possible a notation can give an application a clue). Want
to know the person's surname? The month? Can't be done easily the way it's
been marked up.

In data-oriented markup, you often want to ask questions about (or style on
the basis of) both entities (in the non-SGML/XML sense) and relationships.
So it often makes sense to markup both. In your actor role example, you
could have (where I'm calling the mapping of actor to character a role):

<Role>
    <Actor>
        <Name>Candace Hilligoss</Name>
    </Actor>
    <Character>
        <Name>Mary Henry</Name>
    </Character>
</Role>

It may seem verbose, but notice we are capturing both entities and
relationships. If we want to list all names (or style all names) a
particular way, we can because we've explicitly marked up all names as such.
Interested in just character names? Just match or select Character/Name.
Interested in the roles Candace Hilligoss has been in? Just use
Role[Actor/Name="Candace Hilligoss"]. Interested in the names of characters
played by the actor whose name is Candace Hilligoss? Just use

    Role[Actor/Name="Candace Hilligoss"]/Character/Name

and so on. It's always easier to start verbose and throw away information
and structure than be terse and try and infer it later on.

James


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list