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

Hi.

One way of dealing with this, which I'm not advocating is necessarily the
best way, merely another tool in the kit, is when one has a basic logical
unit represented as a tag, who's general use is straightforward, but that
may convey extra meaning underster certain circumstance, is to extend the
logical unit into several using attributes.

Hence you might have <name> which can be extended with a simple type to
<name type="surname">. This is useful if you know that you'll rarely be
concerned if the name is a surname, so don't want to add to what the author
must learn, especialy if the type attribute defaults to say "full-name",
and ideally has a fixed set of values.

In young DTDs type attributes are very useful in that they allow you to
easily extend the model, and if you find a particular type being heavily
used it's normaly a good indicator that a new tag is needed.

The other option with something like the date given bellow is to allow the
two alternatives of either...

<date format="dd-mm-yy" y2k="no">15/03/99</Date>

...or..

<date y2k="yes">
     <day format="numeric">15</day>
     <month format="alpha">March</month>
     <year format="####">1999</year>
</date>

Now the author has choices about how detailed they think they need to be
giving the date.

Just my 2p worth :)

Cheers
     Guy.





xsl-list@xxxxxxxxxxxxxxxx on 03/15/99 01:02:01 PM

To:   xsl-list@xxxxxxxxxxxxxxxx
cc:    (bcc: Guy Murphy/UK/MAID)
Subject:  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






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