[May 05, 2001] While the terminology "architectural forms" apparently originated in connection with the HyTime standard (ISO/IEC 10744), the concept was generalized in the Technical Corrigendum to HyTime in such fashion that the notion of arbitrary SGML architectures became popular [1996-1997]; subsequently, the idea was carried over into XML.
The "Architectural Form Definition Requirements (AFDR)" section in Annex A (SGML Extended Facilities) of HyTime Second Edition documents the revision, and recent versions of James Clark's SP and Jade support architectural processing. An architecture engine implemented as part of a HyTime or general SGML system can act upon semantics specified in architectural forms. Information about architectural forms in the following section [currently] overlaps with that of the HyTime section in the XML Cover Pages; the revised intent is to create and maintain links to AFs here. Please contribute by sending candidate URLs via email.
References:
[March 11, 2002] "A Simple Property Set for Contract Architectural Forms." By Sam Hunting. In Markup Languages: Theory & Practice 3/1 (Winter 2001), pages 73-92 (with 14 references). "Because the contract is ubiquitous in commercial life (and thus in life), applications for a contract property set are almost too numerous to be worth mentioning. Therefore, I will simply list a few here: (1) On-line, ready-to-use, boilerplate contracts; (2) Specification for conversion operations; (3) Lending equity to XSL transforms; (4) Electronic commerce; (5) Enterprise modeling; and (6) Semantic overlays to legacy procedural code. These applications may well require different architectures conforming to the contract property set... Conclusion: "Contracts, because of their power and ubiquity, seem a natural target for an international standards effort using property sets. Property sets provide a simple and very powerful mechanism for representing such complex, real-world relationships."
[March 05, 2002] "Architectural Forms: The Next Generation." Comments on XML-DEV from Joe English, Steven R. Newcomb, and Leigh Dodds, and Rick Jelliffe.
[February 04, 2002] "Architectural Forms: A New Generation." By John Cowan. Draft 2.1. 2002-02-04 or later. "This is a preliminary description of a work in progress called 'Architectural Forms: A New Generation', or AF:NG for short. This document is highly subject to change without notice... AF:NG provides the facilities, but does not employ the syntax, of SGML Architectural Forms. AF:NG is intended to be used in conjunction with the schema language RELAX NG, but is not dependent on it in any way. The purpose of AF:NG is to provide for tightly specified transformations of XML documents, consisting of renaming or omitting elements, attributes, and character data. AF:NG is not intended as a general-purpose transformation language like XSLT or Omnimark. Using AF:NG, a recipient may, instead of specifying a schema to which documents must conform exactly, specify a schema to be applied to the output of an AF:NG transformation. In that way, the actual element and attribute names, and to some degree the document structure, may vary from the schema without rendering the document unacceptable. In particular, it is easy to use AF:NG to reduce a complex document to a much simpler one, when only a subset of the document is of interest to the recipient. The information provided to AF:NG consists of a short XML document called an architectural map, or archmap, plus the appearance of a special attribute called the form attribute within the source document. The name of the form attribute is given in the archmap, and it is the only required portion of the archmap. This draft of AF:NG does not have the ability to map a source attribute into architectural character data..."
[August 03, 2001] "Architectures in an XML World." By Joshua Lubell (National Institute of Standards and Technology, Manufacturing Systems Integration Division). [To be] published in the proceedings of Extreme Markup Languages 2001, Montréal, Cananda, August 14-17, 2001. "XML (Extensible Markup Language) developers have at their disposal a variety of tools for achieving schema reuse. An often-overlooked reuse method is the specification of architectures for creating and processing data. Experience with APEX, an architecture processing tool implemented using XSLT (Extensible Style Language Transformations), demonstrates that architectures can fulfill a role not well served by alternative approaches to reuse... Developers of markup languages have long recognized the importance of reuse. Since the early days of SGML (Standard Generalized Markup Language), authors of DTDs (Document Type Definitions) have used parameter entities to help make markup declarations more reusable. Newer approaches to reuse run the gamut from the relatively simple concept of namespaces to more sophisticated methods such as the facilities available in the W3C's (World Wide Web Consortium's) XML Schema specification. As a result, XML developers today have at their disposal a variety of tools for achieving reuse... Architectures, alternatively referred to as 'architectural forms' or 'inheritable information architectures,' have been around since the mid-1990s. Although the architecture mechanism's invention predates the standardization of XML, architectures are still being used today -- most notably in the ISO Topic Maps standard and in the W3C's XML Linking specification (XLink). In this paper, I briefly describe the architecture mechanism. Next, I discuss APEX (Architectural Processor Employing XSLT), a tool implemented using XSLT (Extensible Style Language Transformations) for processing architectures. I conclude by discussing how architectures compare with some alternative reuse techniques. Within the context of markup languages, an architecture is a collection of rules for creating and processing a class of documents. Architectures allow applications to: (1) Extend XML vocabularies without breaking existing applications. (2) Create architecture-specific document views, retaining only relevant markup and character data while hiding all other content. (3) Promote data sharing between user communities with inconsistent terminologies by enabling the substitution of identifier names and by allowing simple document transformations." Note, in connection with APEX and the Extreme 2001 paper, Lubell's recent post to the RELAX NG mailing list: "I added an example to my XSLToolbox package that uses RELAX NG patterns to represent the 'purchase order' and 'international purchase order' sample schemas from Part 0 of the W3C XML Schema recommendation. The international purchase order pattern uses the purchase order pattern as a (ISO/IEC 10744 Annex A.3) architecture. My example attempts to show how you can use RELAX NG and architectures together to mimic W3C XML Schema features such as type extension and substitution groups. The example also exploits RELAX NG's namespace-awareness in that the international purchase order pattern contains an embedded annotation specifying the default attribute values needed for architectural processing. I'm thinking of making this example into a poster presentation for Extreme 2001, to supplement a paper I'm presenting on architectures and XSLT... To run my example, download and unzip the XSLToolbox distribution, and look at README.TXT in the apex/examples/schema directory."
[May 05, 2001] See preceding entry. "About Architectures." By Joshua Lubell (NIST). Produced in connection with the XSLToolbox. "An architecture is a collection of rules for creating and processing a class of documents. Although the idea of architectures comes from SGML (Standard Generalized Markup Language), SGML's architecture mechanism is easily adaptable to today's XML processing environments and provides XML application developers with some very useful capabilities. Architectures allow applications to: (1) Extend XML vocabularies without breaking existing applications. (2) Create architecture-specific document views, retaining only relevant markup and character data while hiding all other content. (3) Promote data sharing between user communities with inconsistent terminologies by enabling the substitution of identifier names and by allowing simple document transformations. Unlike a grammar, which defines every aspect of representation and processing for a class of documents, an architecture need not specify a complete document type. Instead, an architecture defines rules known as architectural forms that application designers can apply in defining their XML vocabularies. An XML document using an architecture contains special attributes, called architecture support attributes, describing how its elements, attributes, and data correspond to their architectural counterparts (which are governed by the architecture's architectural forms). Architectural support attributes are ignored by non-architecture-aware software tools. Because architectural support attribute values are usually invariant for all documents throughout an XML vocabulary, these attributes can be given default values. Hence, it is easy to hide a document's use of architectures from architecture-unaware software tools as well as from humans viewing or editing the data..."
"Architectures in an XML World." By Joshua Lubell (National Institute of Standards and Technology). Paper prepared for Extreme Markup Languages 2001, August 17, 2001. "An often overlooked method for schema and DTD reuse is the specification of architectures. An architecture is a collection of rules (for creating and processing a class of documents) that application designers can apply in defining their XML vocabularies. An XML document using an architecture contains special architecture-support attributes that describe how its elements, attributes, and data correspond to their architectural counterparts. Software tools for processing architectures are called architecture engines. APEX is a non-validating generic architecture engine written in XSLT. Input to APEX consists of an XML document plus stylesheet parameters identifying an architecture used by the document. APEX produces as output an architectural document conforming to the architecture specified by the stylesheet parameters and the input document's architecture support attributes. Experience with APEX demonstrates that architectures and XSLT are complementary and that architectures can fulfill a role not well served by alternative approaches to reuse." APEX description from the web site: "APEX (Architectural Processor Employing XSLT) implements a simple subset of the Architectural Form Definition Requirements (AFDR) specified in Annex A.3 of ISO/IEC 10744:1997. APEX behaves similarly to David Megginson's XAF package for Java and differs from the AFDR in the same ways as XAF. Input to APEX consists of an XML document plus stylesheet parameters identifying an architecture used by the document. APEX produces as output an architectural document, i.e., an XML document containing only the markup and data defined by the architecture specified..." For background, see the introduction to Architectures, Architectural Forms, Architecture Support Attributes, and Architectural Processing. Source: see the program listing]
SGML Architectures: Implications and Opportunities for Industry, by Steven R. Newcomb, President, TechnoTeacher, Inc. [mirror copy]
[January 13, 1998] "A Tutorial Introduction to SGML Architectures." By W. Eliot Kimber (ISOGEN International Corporation). 'Provides a brief, tutorial introduction to SGML architectures.' Cited by the author on XML-DEV 980113. [local archive copy, 980113]
[April 10, 2000] XML Base Architectures in SP. Steve Newcomb writes: "You can now use SP to validate the conformance of XML documents to base architectures (meta-DTDs). TechnoTeacher has created a version of SP with full industrial-strength support for the alternative PI-based "Base Architecture Declaration" syntax. The enhancement builds on pioneering work done by Luis Martinez while he was working at TechnoTeacher, and it has recently been brought up to industrial strength by Peter Newcomb. Because of urgent need in certain industrial quarters (mortgage, healthcare, etc.), we've placed binaries of this version of SP at our FTP site: ftp://ftp.techno.com/TechnoTeacher/SPt..." [cache]
[May 05, 2001] XSLToolbox Supports XML Application Interoperability via AF Processing. Joshua Lubell (NIST) has announced the creation of an open source toolkit designed to "help developers avoid the drudgery of writing the complicated XSLT transforms often needed to integrate XML applications." The software has been developed within NIST's Manufacturing Systems Integration Division (MSID). The 'XSLToolbox' toolkit "currently contains two tools, both written in XSLT: (1) APEX is an application for transforming XML documents as specified by architectural forms; (2) ATTS is a stylesheet generator for adding default attribute values to XML documents. Unlike some other XSLT libraries, the XSLToolbox is specifically geared toward XML data exchange between applications rather than conversion of XML to human-readable data formats." APEX as a generic architecture engine processes "architecture support attributes which describe how its elements, attributes, and data correspond to their architectural counterparts governed by the architecture's architectural forms. [This allows the designer to:] extend XML vocabularies without breaking existing applications; to create architecture-specific document views, retaining only relevant markup and character data while hiding all other content; and to promote data sharing between user communities with inconsistent terminologies by enabling the substitution of identifier names and by allowing simple document transformations. Input to APEX consists of an XML document plus stylesheet parameters identifying an architecture used by the document. APEX produces as output an architectural document, i.e., an XML document containing only the markup and data defined by the architecture specified. ATTS provides an XSLT meta-stylesheet for assigning default attribute values to an XML document. ATTS is intended for XML applications lacking a convenient method, such as a DTD (document type definition), for specifying attribute defaults. Since the attributes that control architectural processing are usually fixed, ATTS can be used to supply their values. ATTS is therefore handy for DTD-less applications using APEX." [Full context]
"SGML Architectural Forms" by Ludo Van Vooren and Eric C. Severson [bibliographic record with abstract for] an article in <TAG> 5/2 (February 1992) 1-3. See also now: the full text of the article online, from SGML Associates, Inc.; [mirror copy, text and partial links only].
Catalog of HyTime Architectural Forms and HyTime SGML Specification, Version 2.0, June 28, 1993, by Charles F. Goldfarb
Tutorial Introduction to SGML Architectures - "This tutorial provides an informative introduction to the SGML architecture mechanism, how it is used with documents, and how processors can take advantage of architectures. Practical examples of SGML Architectures will be presented, including demonstrations of authoring systems." Contact learn@isogen.com for schedule details.
"It's All About Architectures - SGML has always been about information architecture", by Steven R. Newcomb; [mirror copy, partial links]
The 1997 HyTime Conference documented several uses of architectural forms in business applications: see the conference record/proceedings.
[November 01, 1997] Achitectural forms and the SGML/XML '97 Conference: In addition to Eliot Kimber's "HyTime Quickstart" tutorial, several papers focus on SGML architectures: "From Architectures to Authoring DTDs" (Carla Corkern, ISOGEN); "Using SGML Architectures for Information Interchange" (Colin Gajraj, Nortel Technology, Canada; Tonua Brown, Nortel Technology); "Making Architectural Forms Work For You: Architectural Forms without HyTime" (Bob DuCharme, Moody's Investors Service); "Using Architectural Forms to Map SGML Data into an Object-oriented Database" (Gary F. Simons, Summer Institute of Linguistics); "FrameMaker+SGML and HyTime Architectural Forms" (Lynne A. Price, Text Structure Consulting).
[May 07, 1999] "The Role of Architectural Forms in XML/EDI Applications." By Martin Bryan (The SGML Centre). May, 1999. This paper suggests how some of the Architectural Form Definition Requirements expressed in Annex A: SGML Extended Facilities of ISO/IEC 10744:1997 could be used to simplify the creation and management of XML document type definitions (DTDs) that are designed to be used for business-to-business electronic data interchange (EDI). Background to architectural forms: Architectural forms (AFs) were introduced to SGML in 1997 to allow the development of meta-DTDs that could be used to create classes of elements which could share common processing characteristics. There are four basic types of AFs: (1) Element type architecutural forms, which define a meta-model for a particular class of elements. (2) Attribute type architectural forms, which can be used to assign process control attributes to specific types of elements. (3) Notation type attributes, used to identify notation processors that understand how to handle specific meta-data classes. (4) Data attribute type architectural forms, which can be used to assign processing control attributes to notation processors. . . One of the key advantages of using AFs rather than schemas is that the techniques proposed in this paper can be used by any DTD-aware XML parser, whether or not it is a fully validating parser. For example, the parser used in Internet Explorer 5.0 is DTD-aware, but is not a validating parser. A secondary advantage is that XSLT is based on the data passed to the application by a DTD-aware parser: it currently has no facilities for using information stored in a schema to manage the transformation. The AF approach ensures that the required information is available with the specifications as they stand today, rather than waiting for the next update of the relevant standards, and the harmonization of the many specifications involved, which is likely to take us into the next century." Note: the document contains a section "Relationship between architectural forms and XML schemas." [local archive copy]
[December 13, 1997] At the WG4 meeting in Alexandria, Virginia (December 1997), WG4 N1957 was accepted as the proposed text of an amendment to ISO/IEC 10744:1997 (HyTime). As a subclause to Annex A.3 ("A.3.4.4 Architecture Use Declaration Processing Instruction"), the proposed architecture use declaration (arch) processing instruction would provide "an alternative form of architecture use declaration for use in environments where notations or data attributes are not supported." The amendment was sponsored by Charles F. Goldfarb, Steven R. Newcomb, W. Eliot Kimber, and Peter Newcomb. See the related posting by Eliot Kimber "Architectures, Schemas, and XML: Proposed Amendment to ISO/IEC 10744:1997," with followup by David Megginson; see also Eliot's note of 1998-01-13. [N1957, local archive copy]
[June 10, 1998] XAF - an XML Architectural Forms Processor. XAF is a Java-based XML architectural forms processor that acts as both a SAX application and a SAX parser. . . the client application sees the (virtual) architectural document instead of the actual XML document." Accompanying the software package is detailed, tutorial-oriented documentation about XAF and architectural forms (Using the XAF package for Java), appropriate for both XML document designers and XML software designers. From David Megginson.
[September 11, 1998] "XAF: Using Architectural Forms with XML." Presented by David Megginson at XML Developers' Conference, 21 August 1998. The document incudes an "Overview of Architectural Forms." David Megginson's presentation slides are available online in HTML and PDF format.
[February 24, 2000] Q: "I have been searching around the web for a while now and have not seen any tool other than XAF that acknowledges the existence of Architectural Forms..." A: [from David Megginson] ... and the reaction to XAF was very, very small -- enough so that I decided not to devote any more time to it. There are no other implementations because people don't tend to jump in and imitate also-rans..." XML-DEV 2000-02-24.
[February 24, 2000] Steve Newcomb writes on AFs to the effect that "any obituary for architectural forms (AFs) is premature... [as of 2000-02-24]". One may add to his list of vital signs the interest in using AFs in the context of TEI DTDs (subsets).
[November 06, 1998] "A DTD for Literate DSSSL Programming with DocBook." From Norman Walsh. A DocBook-derived DTD with the DSSSL architecture. - 'This DTD is an extension to DocBook that conforms to the DSSSL architecture. This means that instances of this DTD can be legal DSSSL stylesheets and (almost) legal DocBook documents simultaneously.'
[April 08, 1999] Gary F. Simons, C. Michael Sperberg-McQueen, and David G. Durand: "PANEL: Rethinking TEI markup in the light of SGML architectures." To be presented at ACH-ALLC '99. See provisionally the program.
[January 11, 1999] Gary Simons presented "Using Architectural Processing to Derive Small, Problem-Specific XML Applications from Large, Widely-Used SGML Applications" at the Markup Technologies '98 Conference. Abstract: "The large SGML DTDs in widespread use (e.g. HTML, DocBook, CALS, EAD, TEI) offer the advantage of standardization, but for a particular project they often carry the disadvantage of being too large or too general. A given project might be better served by a DTD that is no bigger than is needed to solve the specific problem at hand, and that is even customized to meet special requirements of the problem domain. Furthermore, the project might prefer for the data it produces to meet the different syntactic constraints of XML conformity. This paper demonstrates how architectural processing can be used to develop a problem-specific XML DTD for a particular project without losing the advantage of conforming to a widely used SGML DTD. As an example, the paper develops a small XML application derived from the Text Encoding Initiative DTD. The TEI Guidelines offer a mechanism for building TEI-conformant applications; the paper concludes by proposing an alternative approach to TEI conformance based on architectures." An online copy of this paper is available in the SIL Electronic Working Papers Series.
[June 13, 1998] Using architectures for versioning. From Steve Newcomb.
[March 23, 1999] In connection with the release of tmproc, note that Geir Grønmo has released a new version of xmlarch [0.25] - An XML Architectural Forms Processor. "The xmlarch module contains an XML architectural forms processor written in Python. It allows you to process XML architectural forms using any parser that uses the SAX interfaces. The module allow you to process several architectures in one parse-pass. Architectural document events for an architecture can even be broadcasted to multiple DocumentHandlers."
[September 16, 1998] - See prevous entry. xmlarch.py is a module which contains "an XML architectural forms processor written in Python. It allows you to process XML architectural forms using any parser that uses the SAX interfaces. From Geir Ove Grønmo (STEP Infotek). See the announcement and the main entry. Announced July 24, 1998; updated September 15, 1998.
[July 19, 1997]. Announcement from Eliot Kimber for an extended tutorial example on SGML architectures, embodied in a highly-structured document type for DSSSL specifications. The author described the document type as illustrative of "Using SGML Architectures and DSSSL to Do Literate Programming." The associated paper, publicly available on the ISOGEN Web site, "relates the author's experience in developing an SGML-based system for creating and managing DSSSL specifications using SGML architectures as defined by the new Architectural Forms Declaration Requirements Annex of ISO/IEC 10744:1997 (Annex A.3 of HyTime). [It] Demonstrates the use of the following: (1) Using architectures to combine semantic objects from different domains into a single document; (2) Using architectures to associate general-purpose metadata with domain-specific objects (DSSSL functions and specifications in this case); (3) Using multiple architectures with a single document; (4) Using the same set of declarations for both client documents and as an architectural meta-DTD; (5) Using multiple levels of architecture; (6) Using architectural instance derivation to do useful things; (7) Suppressing architectural processing of elements and data; (8) Using SGML to structure program code ('literate programming').
[April 03, 1998] David Megginson's book Structuring XML Documents (1998) devotes all of Part 4: DTD Design with Architectural Forms to architectural forms. Specifically: "Chapter 9. Architectural-Forms Concepts; Chapter 10. Basic Architectural-Forms Syntax; Chapter 11. Advanced Architectural-Forms Syntax."
[April 02, 1998] Extract: Eliot Kimber and Paul Prescod on "inheritance" and "subtyping" in the context of ISO/IEC 10744 Architectural forms.
[April 08, 1998] Tutorial Introduction to SGML Architectures - from ISOGEN
[October 2, 1997] Architectural Forms handout from a presentation "Java Beans and Architectural Forms," (August 21, 1997 - XML Dev Day), by David Megginson: "Proposal: Architectural Forms for XML". See the accompanying XML-DEV posting (October 2, 1997) ; [archive copy]
[November 26, 1997] "Using Architectural Forms to Map TEI Data Into an Object-oriented System." By Gary Simons. Pages 123-129 in TEI 10: A Conference in Celebration of the Tenth Anniversary of the Text Encoding Initiative. Abstracts. A related paper Importing SGML data into CELLAR by means of architectural forms is also online in HTML format: see http://www.sil.org/cellar/import/.
"Managing SGML Architectures and Object Models with Groves." By W. Eliot Kimber (Isogen International).
Document by David Durand and Steven DeRose, Concerns about HyTime TC 1.0. June 8, 1995 version. See the bibliographic entry or the [July 1995] the HTML source, or [mirror copy, made June 1996].
"A Thought About AF [Architectural Form] 'Definitions'", by David G. Durand. June 28, 1995[mirror copy]
"HTML and Architectural Forms." By Russell O'Connor (roconnor@uwaterloo.ca). Paper for W3C Workshop - "Shaping the Future of HTML." May 1998. [local archive copy]
Böhm, Aberer, and Klas: "Building a Hybrid Database Application for Structured Documents," in Multimedia Tools and Applications 5 (1997) 275-300 [Kluwer Academic Publications], also available online. See the abstract for hints.
Stream-based architectural processing of multiple groves at once (posting from James Clark)
"Modellierung von HyTime Architectural Forms als Grundlage für das Annotieren strukturierter Dokumente." By Isabel Scheiding (GMD-Studien No. 299, Sankt Augustin, Oktober 1996).
URL for the [future, post-971101] document "A Quick Guide to SGML Architectures." From the HyTime User's Group, and apparently by Eliot Kimber of ISOGEN
Topic Navigation Maps A proposed set of architectural forms for the definition of topic navigation maps, from The SGML Centre; [mirror copy]
Architectural form support in James Clark's SP package
Examples of architectural form processing using SP (1.1), from James Clark
Eliot Kimber explains (HyTime) architectural forms [May 1997]
"Document processing based on architectural forms, with ICADD as an example", by Klaus Harbo [mirror copy, text only]
"Object Oriented Architectural Forms." By David Peterson. <TAG>: The SGML Newsletter 8/5 (September 1995) 14.
[December 05, 1997] Publication of the International SGML Users' Group Newsletter Volume 3, Issue 4 (October 1997). The Newsletter editor Eamonn Neylon writes: "This issue is to devoted to 'architectural forms' - a component of the HyTime standard. Steven Newcomb asks whether you should be interested in this revolutionary application of SGML in an overview of the new features in the standard. Martin Bryan illustrates the application of architectural forms in the form of Topic Navigation Maps; and Hasse Haitto writes on the implications of the emerging standards for product developers."
"HyTime Architectural Forms for Workflow Processing", by Franz Burger, FAW - Research Institute for Applied Knowledge Processing
EADR (below) is outdated as of May/June 1997, being superceded by the [May 1997} publication of the "Final text of corrected HyTime" [TC] with its Annexes A and C. Annex A now has "Architectural Form Definition Requirements (AFDR)" and Annex C, "Architectural Meta-Declarations". For the AFDR, see provisionally this viewable HTML version, being but partially HTMLized from the official WG8 SGML source cited above.
Enabling Architecture Definition Requirements (EADR) [outdated as of May/June 1997; see above] from the SGML Repository: HyTime TC, Annex C. Enabling Architecture Definition Requirements (EADR): "This annex states the requirements for the formal definition of the architectural forms by which an enabling document architecture governs the SGML representation of its documents. Filename: hi1anarc.txt, 46K. [local mirror copy]
Related discussion: documenting DTD semantics with (meta-) DTDs: see the collection of links
Thus: Wayne Wohler's CApH design, "To provide a DTD to express the structure and semantics of an SGML DTD to allow SGML processing on SGML DTD information"; see also the mirror copy.
See also: Description of DTD Semantics, by Wayne Wohler
