Re: Architectural Forms, separation of formatting and loose-leaf management

Subject: Re: Architectural Forms, separation of formatting and loose-leaf management
From: "W. Eliot Kimber" <eliot@xxxxxxxxxx>
Date: Wed, 06 May 1998 08:52:33 -0500
At 09:46 AM 5/6/98 +0200, Jordi Mulet wrote: 

>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  
>?  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,...)

There are several ways in which architectures might be helpful:

1. To define a common structure for the base information that is sufficient
to enable production, from which more specialized documents can be derived
(e.g., a general "tech manual" architecture that defines the structures
needed to generate pages from which different documents types are derived
(e.g., "user guide", "ref manual", etc.).

2. To define the minimum information needed to enable management of the
information in a repository, things like unique IDs, basic semantic
distinctions related to business rules that must be enforced, etc. This
level of architecture is usually very simple (on the order of 20 forms) and
is the base from which all other architectures are derived.

3. To define the metainformation needed to represent information about the
documents in the repository. This architecture would apply to documents
that describe the base documents, not the base documents themselves.  This
architecture might include definitions of link types (relationship types),
"tables" of metadata, etc.  Documents of this type might be "virtual" in
that they are not managed as literal documents but are inherent in some
optimized representation of the metadata (e.g., relational tables).  The
architectures serve as the primary schema definition for the metadata
(remembering that an architecture is not just a set of DTD declarations,
but the documentation that describes the semantic objects the architecure
defines).  By having an architecture, you can always export the metadata as
SGML documents for interchange or archiving.

For non-SGML data, I think you are describing the definition of property
sets for those data types so that groves can be constructed. Given groves
you can use standards like DSSSL and HyTime to define processing of those
data types in a non-proprietary, non-implementation-specific way.  This is
certainly the approach I would recommend.

There is some practical experience using architectures as I've described.
ISOGEN has used these approaches in varying ways for some of our clients.
Unfortunately, the largest such I'm not at liberty to name or
characterize--I can only say that it is an application of the largest scale
and business criticality.

For the use of non-SGML groves, there is also some experience, but less,
because the supporting software is much newer. TechnoTeacher Inc. is
building a general grove management system, GroveMinder, that will be
available for initial testing later this year (see
"http://www.techno.com";). I'm constructing a toy grove manager called
"PHyLIS" (Personal HyTime Linking Information System) that will be
available for general use in the next month or so. The current state of the
code enables the creation and integration of grove constructors for any
kind of data but does not yet implement HyTime linking or location
addressing (but it will soon). With it you could test property sets for
non-SGML data types and grove constructors for them. Unfortunately, it is
not intended nor appropriate for production work (it is truly a toy for
demonstration purposes). [You can get the source code (VB5) from
"http://www.drmacro.com/phylis"; if you want it--it's still quite rough,
undocumented, no installation process, etc.  But you can play with groves
generically. It does, however, demonstrate the construction and use of
groves for non-SGML data.]

Cheers,

Eliot
--
<Address HyTime=bibloc>
W. Eliot Kimber, Senior Consulting SGML Engineer
ISOGEN International Corp.
2200 N. Lamar St., Suite 230, Dallas, TX 95202.  214.953.0004
www.isogen.com
</Address>


 DSSSList info and archive:  http://www.mulberrytech.com/dsssl/dssslist


Current Thread
  • Architectural Forms, separation of formatting and loose-leaf management
    • Jordi Mulet - from mail1.ability.netby web4-1.ability.net (8.8.5/8.6.12) with ESMTP id DAA11500Wed, 6 May 1998 03:58:56 -0400 (EDT)
      • Paul Prescod - from mail1.ability.netby web4-1.ability.net (8.8.5/8.6.12) with ESMTP id KAA15797Wed, 6 May 1998 10:28:17 -0400 (EDT)
        • Peter Newcomb - from mail1.ability.netby web4-1.ability.net (8.8.5/8.6.12) with ESMTP id QAA27080Wed, 6 May 1998 16:45:20 -0400 (EDT)
      • <Possible follow-ups>
      • W. Eliot Kimber - from mail1.ability.netby web4-1.ability.net (8.8.5/8.6.12) with ESMTP id KAA15376Wed, 6 May 1998 10:00:51 -0400 (EDT) <=
      • Frank A. Christoph - from mail1.ability.netby web4-1.ability.net (8.8.5/8.6.12) with ESMTP id DAA18672Thu, 7 May 1998 03:23:11 -0400 (EDT)
      • Jordi Mulet - from mail1.ability.netby web4-1.ability.net (8.8.5/8.6.12) with ESMTP id FAA19953Thu, 7 May 1998 05:31:48 -0400 (EDT)
      • W. Eliot Kimber - from mail1.ability.netby web4-1.ability.net (8.8.5/8.6.12) with ESMTP id KAA24829Thu, 7 May 1998 10:32:50 -0400 (EDT)