[Mirror copy from http://www.csi.uottawa.ca/~dduchier/misc/wohler1.html]
From: wohler@vnet.IBM.COM (Wayne L. Wohler)
Date: Wed, 16 Feb 94 13:38:28 MST
Subject: Descriptions of DTD semantics
When we started we worked hard on providing syntax to associate semantics with elements and attributes. We now realize that the syntaxes we were using were simple query languages and that their simplicity was a liability since it was quite easy to theorize situations where the language would breakdown. Element context, attribute/element combinations, and many other useful combinations of properties can indicate special semantics. A general mechanism required general property query language. HyTime contains such a query language, HyQ, that CApH proposes to use (Conventions for the Application of HyTime, after all) but the concept could be used with other query languages.
The actual mechanism is quite simple: It has a container, call it a declaration, which contains two parts, a description and the target location specification. The description contains any text that is necessary to describe the semantic. The target location specification gives the location query or queries that yield the targets whose semantic matches the description. For an architecture or set of conventions, like CApH, the defining group need to define the semantics they wish to provide a convention for. They may also wish to provide queries which are recommended. For example, CApH will provide a list of semantics and a set of attribute specifications that may be the target of the query. To use the semantic, it would be a good idea to use the conventional attribute specification but would not be necessary, just recommended.
This approach has a number of advantages:
There are a couple of interesting points here. First, the locations define semantics for all locations that satisfy the location specification. To work at the DTD level rather than the document instance level requires a different kind of resolution of the query. Usually, one thinks about document instance locations that satisfy the query, not elements declarations themselves that satisfy the query. Second, semantics definitions would be interchanged by passing a separate document containing the semantic declarations, not within the DTD itself.
Some very simple syntax to illustrate the principle (I'll omit some of the CApH for clarity), this example defines the attribute to be used to carry CApH-defined keywords. In the example I won't define an architectural form for the elements defined but this could easily be done and is done in the CApH work:
<!element SemanticDeclarations - - (SemanticDeclaration)+ > <!element SemanticDeclaration - O (SemanticDescription, Location+) > <!element SemanticDescription - O ANY > <!element Location O O (Query) > <!attlist Location ID ID #IMPLIED HyTime CDATA #FIXED nameloc > <!element Query O O (#PCDATA) > <!attlist Query Notation NOTATION HyQ HyTime CDATA #FIXED nmquery > <!notation WohlerQ system "" --my notation in lieu of the correct HyQ--> <SemanticDeclarations> <SemanticDeclaration> <SemanticDescription> Carries the semantic key name(s) applicable to this element according to the Conventions for the Application of HyTime (CApH). <Location> <Query notation=WohlerQ> attribute name = 'CApHrole" </SemanticDeclarations>