AF and Schematron

["Rick Jelliffe" <ricko@allette.com.au>]

 From: "Steven R. Newcomb" <srn@coolheads.com>

> "Rick Jelliffe" <ricko@allette.com.au> writes:
> >...I cannot imagine that AF per se has much of
> > a life. Archectural Forms has lost the battle but has
> > won the war.
> 
> Please understand that I understand the difference
> between the battle and the war.  

I think most of Steve and my difference here comes down
to me using "Architectural Forms" and Steve using
"architectural forms".  I mean the specific technology,
Steve means the paradigm. 

> James Clark's award acceptance speech at XML 2001
> included the sentence, "It's time to stab SGML in the
> back."  I think this is premature. 

Well, maybe that is just cage-rattling, crowd-pleasing, vote-buying
wishful thinking, but until someone figures out what to do with 
standard public entities it is just ear-pandering.  (I think the ISO 
and MATHML standard entity sets should be built in to XML 2.0, 
by the way.  XML needs to be bigger in that area
in order to be clarified w.r.t. links and schemas)

> >   5) it invented its own non-SGML dialect with  a meta-DTD containing
> >         <!ADFR ...>,  a new particle #ALL, 
> >       and new parameters on the SGML Declaration. 
> 
> (a) None of these convenience features are necessary to
>     the operation of the paradigm.  Bringing them up here
>     only muddies the water.

When people say "why is AF with the Dodos?" it is good to have
some reasons, such as the non-8879 dialect of the original.
Otherwise people could only reasonably conclude it would have
to be because of some flaw with the idea of "enabling architectures."
I don't think it does muddy the waters. 

> (b) Calling these convenience features "non-SGML" is
>     misleading.  The relevant ISO standard, which is a
>     member of the SGML family of standards, calls them
>     "SGML Extended Facilities".  If that doesn't make
>     them "SGML", what, in your mind, would?

Conforming to ISO 8879.

> > Even Schematron has a role attribute, which could be
> > used to augment an information set for the benefit of
> > downstream processes.  I think the path approach is
> > easier to figure out and more powerful than the
> > meta-grammer approach of AFs.

> I don't think so.  I'll be convinced if you can show
> how, with your approach, a single element can describe
> how it can be validated and processed in multiple
> processing contexts, each with its own understanding of
> the valid context(s) and content(s) of that element.

Schematron supplies several features for this.

For a start, a Schematron schema is made of "patterns".
Each pattern represents a distinct pass over the document's
information set. (Every "context" node in the document will only
match a single rule per pattern, the lexically first one if
there is multiple possible matches.)

Patterns can be grouped into "phases".  One pattern may
be active in more than one phases.  

So a phase represents an architecture. A different phase
can, under user control, be active during different stages
of processing. Indeed, there is no reason why an implementation
could not use a document according to different phases 
automatically. 

There are two attributes particularly useful, to act like
architectural forms. 

The "subject" attribute lets you specify, for every
report that succeeds or assertion that fails, a path
from the context node. This allows us to specify 
the actual node at play, which may not be the context
node. If there is no subject XPath specified, just
the context node is used. I think this is the "context" that
Steve asks for.

The "role" attribute allows you to assign a name to any 
assertion (or report) within a rule. I think that is the "contents"
Steve asks for.

An example of this kind of use can be seen in Topologi's
free Schematron Validator, which I apologise for mentioning
too often on this list.   We can take a document and
an appropriate Schematron schema, and automatically generate 
a Topic Map (or RDF).   Such a Topic Map would, it seems
to me, provide much more powerful information set for
generating a specific architectural view of a document
(by some future architecural forms processor, lower case)
than Architectural Forms (title case).

For example, here is the kind of Schematron schema giving roles.

<schema xmlns="http://www.ascc.net/xml.schematron";>
  <title>Example for Steve N.</title>

  <phase name="html" patterns="h1" />
  <phase name="databaseMapping" patterns="d1" />

  <pattern name="html">
        <rule context="people">
            <report test="true()" role="table" />
        <rule>
        <rule context="people/person">
            <report test="true()" role="tr" />
         </rule>
        <rule context="person/*">
            <report test="true()" role="tr" />
        </rule>
   </pattern>

   <pattern name="d1">
        <rule context="people">
            <report test="true()" role="table" />
        <rule>
        <rule context="people/person">
            <report test="true()" role="row" />
         </rule>
        <rule context="person/*">
            <report test="self::name" role="primary_key">The "name" element is a primary key</report>
            <report test="true()" role="field" />
        </rule>
    </pattern>

</schema>

This gives two phases, and I think these phases are nothing
less than architectures.

The "html" phase lets us specify a mapping of elements
to HTML.  The "database" phase lets us specify a
mapping of elements to database bits. Note that
in the case of person/name, we specify 
that a name is a primary key as well as being a field.


Cheers
Rick Jelliffe