SGML Architecture questions

[W. Eliot Kimber]

At 03:46 AM 2/1/98 +0300, Dmitri Kondratiev wrote:
>I may be wrong, but from my understanding of SGML architecture, only
>bridging mechanism provides for type extension. Everything else in
>architecture seems to be element and attribute names remaping. Bridging
>element serves as a target for mapping substructure to it. Still bridging
>element is not defined in DTD and as a result its content/attributes can't
>be validated by parser. Is that correct ?

The bridging element *is* defined in the DTD, so it's use can be validated
by the parser, but your real question is:

>how validity constraints can be enforced for bridging element substructure ?

You do it locally in the document's own DTD, or you do it by deriving the
bridging element from another architecture. 


>There is no DTD for <archbridge> element content so:

Yes there is: (#PCDATA | archbridge)* 

However, you're point is that you might want to impose constraints on the
local (to this document) content of elements that map to archbridge.  You
could define, locally, the content for the name element to match your
constraints:

<?XML version="1.0" ?>
<?IS10744:arch name="personarch"
  bridge-form="archbridge"
?>
<!DOCTYPE customer.record [
 <!ATTLIST customer.record personarch NAME #FIXED "person" >
 <!ELEMENT  cust.name (last, first) ><!-- NOTE: local content model -->
 <!ATTLIST  cust.name      personarch NAME #FIXED  "name"   >
 <!ATTLIST   last          personarch NAME #FIXED   "archbridge" >
 <!ATTLIST   first         personarch NAME #FIXED   "archbridge" >
 <!ATTLIST  cust.address   personarch NAME #FIXED  "address" >
 <!ATTLIST   street        personarch NAME #FIXED   "archbridge" >
 <!ATTLIST   city          personarch NAME #FIXED   "archbridge" >
 <!ATTLIST   state         personarch NAME #FIXED   "archbridge" >
 <!ATTLIST   zip           personarch NAME #FIXED   "archbridge" >
]>
<customer.record>
 <cust.name><last>Kimber</last><first>William</first></cust.name>
 <cust.address>
 <street>1234 Maple St.</street>
 <city>Austin</city><state>TX</state><zip>78757</zip>
 </cust.address>
</customer.record>

You can also do it by deriving the bridging element from another architecture:

(This modifies the above declarations:)

<?IS10744:arch name="namearch"
   public-ID="Architecture for the rules for names of people and things"
?>
 <!ELEMENT  cust.name (last, first) >
 <!ATTLIST  cust.name      personarch NAME #FIXED  "name"   
                           namearch   NAME #FIXED  "person-name">
 <!ATTLIST   last          personarch NAME #FIXED  "archbridge" 
                           namearch   NAME #FIXED  "lastname">
 <!ATTLIST   first         personarch NAME #FIXED  "archbridge"
                           namearch   NAME #FIXED  "firstname">

This says that the cust.name element plays the role "name" within the
personarch architecture and the role "person-name" within the namearch
architecture. I can validate that cust.name satisfies the rules for "name"
as defined by the personarch and that its content satisfies the rules for
"person-name" in the namearch.

Notice how the cust.name element "bridges" from the personarch architecture
to the namearch architecture or from the architecture to the local
(document-specific rules).

Cheers,

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

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)