[dsdl-comment] Schematron issues

I was hoping to send this last week. Better late than never, I hope.

I came across a large number of issues implementing ISO Schematron.
Some of the issues have been hashed out on the now-defunct Schematron
mailing list but I have not seen an updated draft that addresses them.
Many others are issues that are not yet resolved to satisfaction, or
that I haven't seen mentioned. Here is a list of what I can remember.

1) The inclusion mechanism is barely specified. Is the included
document a new schematron with sch:schema as root? Is it any root
element, with only the children checked for Schematron elements? Can it
be a general entity or must it be a WF document entity? etc.

2) The abstract patterns mechanism is under-specified. Is all the text
of an abstract template processed for parameter
substitution or just rule/@context, assert/@test, report/@test?
For example is value-of/@select also processed?
Is the following valid?:
 
  <pattern abstract="true" name="spam">
    <rule context="sardine">
      <$tuna test="true()">Eat more Chicken of the sea</$tuna>
    </rule>
  </pattern>
                                                                                
  <pattern name="concrete-spam" is-a="spam">
    <param formal="tuna" actual="assert"/>
  </pattern>

3) How does one express an actual XPath variable in an abstract
pattern? Need an escaping mechanism for "$": perhaps "$$"?

4) What are the lexical naming rules for identifiers (such as
pattern/@name). same as XPath IDs?

-- % --

The following were reported by Brian Ewins and have not been addressed
to my knowledge.

5.2.9, 5.2.10, Annex A; there is some confusion in the spec between
'name' and 'id'. pattern, phase have a 'required name attribute'
according to the text, but the RelaxNG schema has 'id'.

5.2.10, 'the name given in in the phase attribute on the schema' should
read 'the name given in in the defaultPhase attribute on the schema'

5.2.5 ' The required value attribute is an expression evaluated in the
current context that returns a string' vs 6.4 ' The let value query
language, a function which returns a data value.' (missing the words
'coercable to a string' that appears on previous lines) - which? I
don't see the need to restrict the values returned by let queries to
strings, if the query language supports their use.

5.2.6 'an expression evaluated in the current context that returns
either a string that is the name of a node or a node that has a name' -
expanded name? qname? localname? I think implementations previously used
the xpath of the subject as the name... I'm not sure whats supposed to
be here.

5.2.10 '#ALL' - while this is reserved, its use as a phase id isn't
prohibited by the additional constraints in annex B (ditto '#DEFAULT')
however, it may be useful to allow #ALL as a phase name, to allow
variable to be assigned that cannot otherwise be assigned, since
variables are constant; eg phase1 sets 'currency' to 'dollar', phase2
sets 'currency' to 'dollar|pound', the patterns used by these phases
make use of 'currency' - the only mechanism allowed according to the
spec when using '#ALL' is to supply this externally? It might be better
to define phase as:

phase =
element phase {
rich,
(foreign & inclusion* &
(
    (attribute id { xsd:ID, "#ALL" }, p*, let*) // not sure how to
express this but you see what I mean - if id=#ALL, no 'active' elements
| (attribute id { xsd:ID }, p*, let*, active*)
)
}

Annex A: the specification for 'rule', 'pattern' aren't as tight as they
could be - id should be required for abstract patterns and rules, since
otherwise they can't be used? ie:

pattern =
element pattern {
rich,
(foreign & inclusion* &
( (attribute id { xsd:ID }, attribute abstract { "true" }, title?, (p*,
let*, rule*))
| (attribute id { xsd:ID }?, attribute abstract { "false" }?, title?,
(p*, let*, rule*))
| (attribute id { xsd:ID }?, attribute abstract { "false" }?, attribute
is-a { xsd:IDREF }, title?, (p*, param*))
)
}

rule =
element rule {
rich,
linkable,
(foreign & inclusion*
& ((attribute id { xsd:ID }, attribute abstract { "true" }, let*,
(assert | report | extends)+)
| (attribute id { xsd:ID }?,attribute context { path }, attribute
abstract { "false" }?, let*, (assert | report | extends)+)))
}

[Uche's note: I assumed it's the name attribute on the abstract pattern
that is used later in is-a. Clearly the spec needs to be tightened
here.]

-- 
Uche Ogbuji                                    Fourthought, Inc.
http://uche.ogbuji.net    http://4Suite.org    http://fourthought.com
A hands-on introduction to ISO Schematron - http://www-106.ibm.com/developerworks/edu/x-dw-xschematron-i.html
Schematron abstract patterns - http://www.ibm.com/developerworks/xml/library/x-stron.html
Wrestling HTML (using Python) - http://www.xml.com/pub/a/2004/09/08/pyxml.html
Enterprise data goes high fashion - http://www.adtmag.com/article.asp?id=10061
Principles of XML design: Considering container elements - http://www-106.ibm.com/developerworks/xml/library/x-contain.html
Hacking XML Hacks - http://www-106.ibm.com/developerworks/xml/library/x-think26.html
A survey of XML standards - http://www-106.ibm.com/developerworks/xml/library/x-stand4/
--
DSDL comments
To unsubscribe, please send a message with the
command  "unsubscribe" to dsdl-comment-request@dsdl.org
(mailto:dsdl-comment-request@dsdl.org?Subject=unsubscribe)