ISO draft typos

I've spotted a few typos in the draft I don't think Daniel picked up on:

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. (Dan picked up on the 
first line too, but he didn't mention that its inconsistent with later 
bits of the spec)

Some other bits that need clarified:

5.2.4 'an external XML document with a schema fragment'. If this 
external document is to be loaded by an XML parser, it needs to be 
well-formed; so it'll have a root element. What would that be? Should it 
just be 'something' in another namespace that we can ignore as its 
children are the things that are important? Or would the external 
documents consist of e.g. a single <rule> element, so the root isn't 
ignorable? (should I be looking

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.8 param, in general. Reading Daniel's comments I see that he was 
under the same misapprehension as I was, that param values are (eg) 
xpaths to be evaluated in context, etc. On closer reading I see they're 
just string substitutions. That's clear as mud from the text! That two 
of us have misunderstood it means there's something wrong - the 
description of the param element should really have a sentence or two 
added to clarify the intent.

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)+)))
}


Just to declare my interest here - Rick, I'm the guy who wrote a bunch 
of replies on your blog about java xpath APIs. I'm trying to rewrite my 
xpath-schematron-like jaxen implementation into a 'proper' ISO 
schematron implementation, which I'd like to donate to the sf.net 
project, under a similar license to the reference implementation, if you 
don't barf at the code. I'm working on top of jaxen rather than xsl 
because I need to do validation of xml-like trees that aren't xml 
documents - something like the JSR-170 content repository API  
(http://www.jcp.org/en/jsr/detail?id=170).
What I've got written covers most of the spec, but most optional 
features are omitted - no natural language assertions (I'd like to make 
use of <name> and <value-of> though, as in java its convenient to use 
those as parameters for MessageFormat, to do internationalised 
assertions), also I've not done <include> yet (see above). Anyway, more 
on this later in the week, if I get time.

Cheers,
    Baz



-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click