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 |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: Architectural Forms, separation, Peter Newcomb | Thread | RE: Architectural Forms, separation, Frank A. Christoph |
Re: Border resolution question, James Clark | Date | Re: Architectural Forms, separation, Paul Prescod |
Month |