------=_NextPart_000_0029_01BD7952.8E0B8240
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Here are three random things which may be useful to consider.
1) The first is that DSSSL allows you to have external functions. So =
even though DSSSL itself has no way to query the pagination system, =
DSSSL does allow you to stick in your own queries or functions. You can =
do all sorts of tricks with these. I dont know to what extent JADE =
supports this, though. One trouble with stream-based SGML processors is =
that they often have an output buffer (or are in a pipe) so unless you =
can flush the output buffers, your SGML processor may be left stranded =
if it waits for some feedback from a downstream program.
A DSSSL system built on top of a general purpose Scheme would be most =
likely to cope with feedback from layout engines. Tony Graham of the =
DSSSL list would be a good contact in this regard.
2) People often put pagination information in processing instructions. =
Or the information can be kept in an external database with, for =
example, HyTime locators. If you can decide in advance to only break =
pages on paragraph boundaries, then you can piggyback the pagination =
information on top of element markup.
3) If you find you have many of these concurrent structures, you may opt =
for "point markup", which is rather extreme, and would be an interesting =
challenge for some stream-based processors. In point markup, your main =
text is just marked up using=20
<!DOCTYPE document [
<!ELEMENT text ( #PCDATA | point)*>
<!ELEMENT point EMPTY>
<!ATTLIST point id ID #REQUIRED >
Then you have as separate element trees for each kind of structure: =
these trees probably contain no character data of their own, just IDREFs =
to the start and end of their range. In this way you can represent =
concurrent, overlapping hierarchies in SGML. For example:
<!ELEMENT document (tree+, text)>
<!ELEMENT tree (start, tree*, end)>
<!ELEMENT ( start | end ) EMPTY >
<!ATTLIST tree type NMTOKEN #IMPLIED >
<!ATTLIST (start | end ) refid IDREF #REQUIRED >
]>
<document>
<tree name=3D"pages">
<start refid=3D"x1"/> =20
<tree name=3D"page1">
<start refid=3D"x1"/>
<end refid=3D"x4"/>
</tree>
<tree name=3D"page2">
<start refid=3D"x4"/>
<end refid=3D"x5"/>
</tree>
<end refid=3D"x5"/>
</tree>
<tree name=3D"p">
<start refid=3D"x2"/>
<tree name=3D"b">
<start refid=3D"x3"/>
<end refid=3D"x5"/>
</tree>
<end refid=3D"x5"/>
</tree>
<text><point id=3D"x1"/>here is <point id=3D"x2"/>some<point =
id=3D"x3"/>
data <point id=3D"x4">of no interest.<point =
id=3D"x5"/></text>
</document>
This structure has the advantage of neatness, and provides a lot of =
modeling power
for just one extra level of indirection. If you used HREF rather than =
REFID, you can use
external point markup too.
The effect, of course, is to have concurrently
<pages><page1>here is some
data </page1><page2>of no interest.</page2></pages>
and
<p>here is <b>some</b>
data of no interest.</p>
Rick Jelliffe
Author, "The XML & SGML Cookbook", out in May from Prentice Hall.
------=_NextPart_000_0029_01BD7952.8E0B8240
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">