[
Lists Home |
Date Index |
Thread Index
]
Uche Ogbuji <uche.ogbuji@fourthought.com> wrote:
| My main problem with [the AF approach] has always been that it involves
| processing that is not available to XML generically. [...] the best
| solution to this whole matter [might] have been to hypnotize the XML 1.0
| folks to add into XML 1.0 the ability to [re-map] elements and attributes.
This is one of the intended possible capabilities of ISO Schematron, b.t.w.
Use the role attribute to decorate elements.
So we can have something like (in the intended syntax)
<pattern abstract="true" name="abstractTable" >
<rule context="$table" role="table-element">
<assert test="$row">A table has rows</assert>
</rule>
<rule context="$row" role="row-element">
<assert test="$cell">A table row has cells</assert>
</rule>
<rule context="$row/$cell">
<assert test="true()">Cells only appear in rows</assert>
</rule>
</pattern>
<pattern use="abstractTable">
<param name="table" value="html:table" />
<param name="row" value="html:tr" />
<param name="cell" value="html:td" />
</pattern>
<pattern use="table-rule">
<param name="table" value="cals:tble" />
<param name="row" value="cals:tbody/cals:row" />
<param name="cell" value="cals:entry" />
</pattern>
In this case, we have an abstract pattern of a generic table.
Then we have two uses of that abstract pattern: the
HTML table and the CALS table.
Processing the document could result in an enhanced DOM
with the extra information, or an external document
linking to the original, or just the original document augmented
with the role attribute acting as architectural forms.
What the architectural forms people call "architectures" can be
pretty similar to Schematron patterns. When I wrote the
XML & SGML Cookbook I found there was no grammar-based
approach that really was very satisfactory for capturing rhetorical
structures, and I think for generic browsers for XML would be
much easier to make if we had styles for rhetorical structures
(generic tables, lists, paragraphs, heading, see www.xmlpatterns.com)
rather than names (which are too particular) or complex types
(which are also at the level of "what should be present" rather
than "how does this element function in context"). Anyway,
a work in progress.
Cheers
Rick Jelliffe
|