Sands for XAG: Syntax and Semantics

Abstract

The XML Accessibility Guidelines discuss semantics and syntax, with emphasis on exporting and documenting semantics as much as possible. However, techniques for this are lacking, due to the deficiencies of the schema languages for XML. This document presents a strawman proposal for more closely binding syntax with semantics in XML languages.

Introduction

In XAG, we talk about semantics a lot - and particularly the binding of semantics to the syntax. In fact, the binding is often implicit, and the fact that the purpose of XML is often other-than to frame and hang in an art museum contributes to this. The problem is that the "semantics" of an markup construct is very difficult to capture. For example, <p> in HTML is supposed to be a "paragraph", but the actual meaning of a paragraph for many people is dependent upon years of studying language forms - of associating line breaks and indentations (or pauses, to be less media dependent) to this particular concept.

This introduces a severe problem for accessibility. It's a showstopper in many cases. The problem, as hinted at above, is that semantics and syntax are inseparably bound, and often dependent upon media. For many browsers, an HTML blockquote tag [sic] means "indent the next bit of text here". Because of that, people may confuse the syntax for the semantics.

But O.K., we know this is a problem. We want to fix it.

The Extent

Before we do, we should take a look at another blatant case of syntax/semantics confusion; that of XML Schema. In XML Schema, there are a certain amount of constructs that give the impression of semantic association. For example, there's the humble substitution group:-

<xsd:element name="title" substitutionGroup="u:annotation"/>
<xsd:element name="summary" substitutionGroup="u:annotation"/>
<xsd:element name="description" substitutionGroup="u:annotation"/>

You would think that this implies that the title, summary, and description elements shame some common semantics, but remember that XML Schema is a schema language for syntactic validation only. To quote the XML Schema primer (slightly out of context) about the substitution group construct, "[it] simply provides a mechanism for allowing elements to be used interchangeably."

Semantics

"Decentalization" and "grounding semantics in the Web" are cliches, but for a good reason. As stated before, the semantics behind particular markup constructs vary over the contexts in which they are created, used, and otherwise interpreted. With the Web, we have the real opportunity to create some semblance of a shared context - we can agree to use terms without any one particular group dictating what will be.

With the introduction of XML namespaces, it made many buzzwords possible (for each new acronym created, at least ten buzzwords appear); decentralization, evolution, transformability. One of the key technologies for connecting the semantics of each language together is RDF. In fact, the various serializations of RDF are not important, but the model is.

What we are working towards is being able to not only identify markup constructs as first class objects on the Web, but to be able to identify them as members of a certain semantic type, and link those types together in a Web of logic.

WTF?

The point of this is that it makes the XAG conformance criteria automatable to some extent. For example, take checkpoint 1.1: Provide a mechanism to explicitly associate alternative equivalents for content or content fragments. To test conformance to this checkpoint, you need to know the following:-

When the latter is used on the former, you pass the test. You also need to know what qualifies as "use".

An Example

For example, let's say that we have a media element, and a link element for linking bits of media together:-

[ a :MediaElement; 
  :ns <http://blargh.org/#>; 
  :name "media" ] .
[ a :AssociativeElement; 
  :ns <http://blargh.org/#>; 
  :name "link"; 
  :takesAsValue [ :ns <http://blargh.org/#>; :name "media" ] ] .

It is achingly clear that this passes XAG checkpoint 1.1 to some extent. The syntax used above may not, however, be clear. It is a mixture of semantics and syntax. The nearest DTD equivalent is:-

<!ELEMENT media [...] >
<!ELEMENT link (media+) >

The "ns" and "name" predicates simply create a QName of the subject. The rdf:type (keyname: a) predicate relates the type of the QName, remembering that a QName is more than just a bit of syntax: it is actually a block of a language. In this case, we can actually give the semantic types of the elements. That's quite neat in itself.

But there is more at play here: the "takes as value" predicate associates the the subject QName with the object QName under constraint of the types of the QNames involved. In other words, in this case, we may define that when an element of type "AssociativeElement" takes as value an element of type "MediaElement", syntactically the value can occur 1 or more times inside the subject element, and that semantically, all instances that occur are somehow bonded together (i.e., this is the nature of an associative element).

I hope that's clear. We're giving people their semantics back, and making sure that this is all testable. For example, one can now write a FOPL rule such that:-

{ [ is log:semantics of <MySchema.rdf> ] 
   log:contains { [ a :MediaElement ] }; 
   log:notContains { [ a :AssociativeElement; 
                       :takesAsValue [ a :MediaElement ] ] } } log:implies 
 { this earl:asserts 
      [ rdf:subject <MySchema.rdf>; 
        rdf:predicate earl:fails; 
        rdf:object <http://www.w3.org/TR/2001/WD-xmlgl-20010829#cp1_1> } .

There are many element types that evolved by consensus. XAG talks about "element types that allow classification and grouping (header, section, list, etc)". Elements for navigation with well-defined roles are also good examples.

More Detail

What is a good XHTML-like language made up of?

For example XHTML is a semantic and syntactic language composed of various (syntactic) modules. The types of each element and markup construct may be allied closely to its particular module, or there may also be some cross module relationships. In fact, although XML is necessarily hierarchial, there is no for the semantics of the elements to be closely hierarchial.

By means of analogy, HTTP is (or was, orginally) based upon a folder-hierarchial model, but HTML allowed one to break free. There is no reason why our languages shouldn't be allowed to do the same.

Sticking to the XHTML example, we can apply some rules to three of the modules therein:-

@prefix : <#> .
@prefix w3c: <http://www.w3.org/1999/> .

[ a :Module; :title "Link Module"; 
   :containsElements ([ :ns w3c:xhtml; :name "link" ]) ] .
[ a :Module; :title "Metainformation Module"; 
   :containsElements ([ :ns w3c:xhtml; :name "meta" ]) ] .
[ a :Module; :title "HyperText Module"; 
   :containsElements ([ :ns w3c:xhtml; :name "a" ]) ] .

:AssociativeElement is rdf:type of 
     [ :ns w3c:xhtml; :name "link" ], 
     [ :ns w3c:xhtml; :name "meta" ], 
     [ :ns w3c:xhtml; :name "a" ] .

[ :ns w3c:xhtml; :name "link"; 
   :associativeSubjectType :Document; :associativeObjectType :Resource ] .
[ :ns w3c:xhtml; :name "meta"; 
   :associativeSubjectType :Document; :associativeObjectType :Literal ] .
[ :ns w3c:xhtml; :name "a"; 
   :associativeSubjectType :TextSpan; :associativeObjectType :Resource ] .

Issues

Of course, there are plenty of issues - from the social (who will take care of a sands schema, if at all?) to the technical (how do we model QNames?). There is probably not enough drive space on the W3C machines to discuss these things to resolution, but I hope that won't stop us from trying.

Conclusion

"Tell 'em what you told 'em".

Formalizing semantics has recently got a lot of press through RDF and the Semantic Web, and yet these principles have not really been applied to XML. It is about time that they were.

Acknowledgements

Well, just about everyone. This idea is by no means new. Aaron Swartz, Tim Berners-Lee, and Jonathan Borden are amongst the people that have had the same idea, and inspired this document.

Sean B. Palmer