Kimber - Base vs. Derived

Subject: Re: Base vs. Derived (was Seattle Conference)
Date: 30 Aug 1996 00:00:00 GMT
From: "W. Eliot Kimber" <kimber@passage.com>
Organization: Passage Systems Inc.
Newsgroups: comp.text.sgml

> sgmlsh@world.std.com (Sam Hunting) wrote in article
>
> Thank you. What would really help me would be a fresh example that
> illustrates the syntax and semantics used to create a base architecture,
> and to derive DTDs from the base architecture. It would be nice if the
> example were concise enough to fit on a single page....
>
> For example: how about an architectural form "customer" from which an
> element type form "purchasing-agent" is derived? Make any necessary
> assumptions about requirements.

I'll try.

We first define an architecture consisting of two "architectural forms",
the element type form "customer" and a document element form to contain
customer elements (you always have to have a document element form so that
you can generate valid architectural documents).

The architecture is defined by creating a "meta-DTD". This meta-DTD is
syntactically identical to a normal SGML document type declaration subset
but will be referred to differently, as we'll see:

******** File customer.mdt **********************************
<!--=========================================================
    Customer architecture meta-DTD. Defines the
    "customer" architectural form.
    =========================================================-->

<!element custdoc   O O (customer*)
          -- Document element for document that contains
             zero or more customers --
>

<!element customer  - O (#PCDATA)
          -- A customer "record". Content is the customer
             name. Status attribute indicates the active
             status of the customer.
          --
>
<!attlist customer  status (prospect|active|inactive) active
>
<!-- End of Customer meta-DTD -->
*************************************************************

The meta-DTD above will then be referred to from the following client
document. The client document's DOCTYPE declaration contains two relevant
parts:

1. The formal declaration of the use of the customer architecture,
   including the reference to the meta-DTD
2. The declarations of the elements derived from the custdoc and
   and customer element type forms declared in the customer
   meta-DTD.

******* File mydoc.sgm **************************************
<!DOCTYPE MyDoc [
  <!--===========================================
      Trivial document showing derivation of client
      document from base architecture
      ============================================-->

  <!-- Declare use of customer architecture: -->

  <!-- This PI lists the architectures this document uses: -->
  <?ArcBase customer >

  <!-- The following notation defines the "customer" architecture.
       It's notation is always "AFDRMeta", meaning that it is
       a meta-DTD.
    -->
  <!NOTATION AFDRMeta PUBLIC "ISO/IEC 10744//NOTATION
                              AFDR Meta-DTD Notation//EN"
  >
  <!ENTITY custarc-metaDTD SYSTEM "customer.mdt" NDATA AFDRMeta
  >

  <!-- Declare customer architecture as a notation according
       to the rules defined in the AFDR annex of the corrected
       HyTime standard.
    -->
  <!NOTATION customer PUBLIC "-//ME//NOTATION Customer Arch//EN"
  >
  <!ATTLIST #NOTATION customer
            ArcFormA  NAME  #FIXED "custarc"
            -- Name of attribute used to map an element
               to a customer architectural form. This is
               the "architecture form attribute" --
            ArcDocF   NAME  #FIXED "custdoc"
            -- The name of the architectural document element
               form. --
            ArcDTD    CDATA #FIXED "custarc-metaDTD"
            -- Reference to entity containing actual
               meta-DTD. This has to be CDATA because
               you can't use ENTITY for data attributes --
  >

  <!-- Declarations of element types derived from the
       customer architectural forms:
    -->
  <!ELEMENT MyDoc  (#PCDATA|Purchasing-Agent)* >
  <!ATTLIST MyDoc
            Custarc NAME #FIXED "custdoc"
            -- The MyDoc element type is derived from
               the customer architectural form "custdoc" --
  >
  <!ELEMENT Purchasing-Agent  - O (#PCDATA) >
  <!ATTLIST Purchasing-Agent
            Custarc NAME #FIXED "customer"
            -- The Purchasing-Agent form is derived from
               the customer architectural form "customer" --
            status (prospect|active|inactive) prospect
            -- NOTE: derived form uses a different default
                     value for architectural attribute "status"
                     to reflect the element type's semantic. --
  >
]>
<MyDoc>
We think we can get
<purchasing-Agent status=prospect>Betty Buyabunch</> to
buy a lot, much more than our current contact,
<purchasing-agent status=active>Mike Miserly</>.
</MyDoc>

Here is the result of processing the above with SGMLNORM (part of the SP
package), with the -A flag set to "customer", which generates the
"architectural instance" for the customer architecture:

<CUSTDOC>
<CUSTOMER STATUS="PROSPECT">Betty Buyabunch</CUSTOMER>
<CUSTOMER STATUS="ACTIVE">Mike Miserly</CUSTOMER>
</CUSTDOC>

--
<Address HyTime=bibloc
         homepage="http://www.squirrel.com/squirrel/drmacro">
W. Eliot Kimber, kimber@passage.com
Senior SGML Consultant and HyTime Specialist
Passage Systems, Inc., 10596 N. Tantau Ave., Cupertino, CA 95014-3535
(408) 366-0300 (Cupertino), (512) 339-1400 (Austin),
http://www.passage.com </Address>
"If I never had existed, would you still remember me?..."
--Austin Lounge Lizards, "1984 Blues"
(http://www.webcom.com/~yeolde/all/lllhome.html)