xml-dev May 1998: Architectural Forms, separation of formatting and loose-leaf management

------=_NextPart_000_001B_01BD78FF.8F18C240
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello,
We are involved in a SGML project and we are finalisizing the analysis =
phase.
At present we are thinking about how to implement the management of =
loose-leaf pages updates because any availabe off-the-shelf comercial =
implementation can cope with our needs.
We think that the concept of architectural forms can help to manage the =
processing the flow between the intial information structures (SGML =
semantic tags ) and the presentational/layout structures of the final =
pages.=20
As Rick Jelliffe said in a past discussion on XML-dev DSSSL ( with the =
MIF/RTF backend for example) can help to do the transformations to the =
the layout structures ( down-sizing), but we can't obtain any feedback =
from the layout program to the stylesheet language.
We know that others programs as Omnimark or Balise can help to down-size =
the SGML instances but we will need a flow of dependence from the =
pages/layout to the original SGML.=20
=20
A possible implemention of our system would be to build three =
independent Databases:
- Information SGML Database.
- Layout Database (Quark, FrameMaker,...).
- Page Objects Database ( PDF).
=20
and a "meta-Database" to manage all the "processing" an "relationships" =
between the elements of each database. This "meta-Database" would =
control and manage the workflow and updates of the different elements.
Can architectural forms model this meta-database schema to control the =
three database from a top structure? Architectural forms can store all =
the information about processing.
How difficult would be to build a similar system ?=20
It will be necessary to define property sets and grove plans for the =
Layout scheme and Page scheme, doesn't ? Is there any working experience =
on this topic ? ( PDF, Quark, FrameMaker,...)=20
=20
Any feedack will be of great value for us!=20
=20
Thanks,
Jordi Mulet=20
Editorial Praxis S.A=20

------=_NextPart_000_001B_01BD78FF.8F18C240
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello,

We are involved in a SGML project and we are = finalisizing=20 the analysis phase.

At present we are thinking about how to = implement the=20 management of loose-leaf pages updates because any availabe = off-the-shelf=20 comercial implementation can cope with our needs.

We think that the concept of architectural forms = can help=20 to manage the processing the flow between the intial information = structures=20 (SGML semantic tags ) and the presentational/layout structures of the = final=20 pages.

As Rick Jelliffe said in a past discussion on = XML-dev=20 DSSSL ( with the MIF/RTF backend for example) can help to do the=20 transformations to the the layout structures ( down-sizing), but = we can't=20 obtain any feedback from the layout program to the stylesheet=20 language.

We know that others programs as Omnimark or = Balise can=20 help to down-size the SGML instances but we will need a flow of = dependence=20 from the pages/layout to the original SGML.

A possible implemention of our system would be = to build=20 three independent Databases:

- Information SGML=20 Database.

- Layout Database = (Quark,=20 FrameMaker,...).

- Page Objects=20 Database ( PDF).

and a = "meta-Database" to=20 manage all the "processing" an "relationships" = between the=20 elements of each database. This=20 "meta-Database" would control and manage the workflow and = updates of=20 the different elements.

Can architectural forms model this meta-database = schema to=20 control the three database from a top structure? Architectural forms can = store=20 all the information about processing.

How difficult would be to build a similar system = ?

It will be necessary to define property sets and = grove=20 plans for the Layout scheme and Page scheme, doesn't ? Is there any = working=20 experience on this topic ? ( PDF, Quark, = FrameMaker,...)

Any feedack will be of great value for=20 us!

Thanks,

Jordi Mulet

Editorial Praxis=20 S.A