[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] AF and Schematron
From: "Steven R. Newcomb" <srn@c...> > "Rick Jelliffe" <ricko@a...> 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
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|