RE: Committee Draft of ISO Schematron available

Comments on the spec.

3.11 assertion
"ancilliary" should be "ancillary".

3.14 rule
"ancilliary" should be "ancillary".
> "a rule is said to fire when an information item matches its query".=20
Maybe add "matches its rule-context expression query", so that we know =
we're
talking about the following definition.

3.22 name
If there aren't actually further restrictions, I think this should point =
to
the XML 1.0 definition of a name token...

4.2 Predicate Logic
The second and third functions are identical.
Functions match and assert: replace "iff" with "if".

5.2.1 active element
Maybe reword? Something like "Determines the pattern that is active in =
the
current phase. The required pattern attribute must be a reference to an
existing pattern."

5.2.2 assert element
> "The data context is a natural-language assertion."
Not sure if "data context" is the best term... No definition for it has =
been
given, and it's not clear what you mean by that. Maybe just "element =
value"
or "element contents"?
> "If the test evaluates positive, the report succeeds."
Change "report" by "assertion", to avoid confusion with the report =
element.
Maybe even reword in the negative form: "If the test evaluates negative, =
the
assertion fails."

5.2.5 let element
I think this element could be more flexible. Examples:

> "The required value attribute is an expression evaluated in the =
current
context that returns a string."
I believe allowing non-string (i.e. nodeset) expressions is very =
powerful,
and pretty easy to implement (both in XSLT and Schematron.NET). For =
example,
you could define a variable with the set of nodes to be reused as part =
of
the context of several rules, such as:

<let name=3D"customer" value=3D"/company/customer" /> <let =
name=3D"supplier"
value=3D"/company/suppliers/supplier" /> ...
<pattern name=3D"Basic Info">
  <rule context=3D"$customer | $supplier">
    ...test basic info in both nodes...

The variables could be used in assertions to check for containment =
(using
EXSLT, for example) and so on. IMO, the spec should only say that the
expression must be valid for the query language binding chosen, and =
nothing
more.

> "It is an error for a variable to be multiply defined in the current
schema, phase, pattern and rule."
I think this is an unnecessary restriction. It goes against usual rules =
of
programming languages, where you can have equally named variables in
different scopes, and referencing it will give you the value of the
"closest" scoped value. This is how I implemented in Schematron.NET
(non-released version). This restriction would cause a nasty problem: if =
a
"parent" schema defines many variables and at the same time uses many
<include> elements, you must ensure that no included fragment collides =
with
the including schema variables, which can be quite tricky, specially in
large modularized schemas. I think it's better to remove it.

> "The query language binding specifies which lexical conventions are =
used
to detect references to constants."
Maybe change "constants" with "variables".

5.2.6 name element
> "The name is replaced by the string result of evaluating the select
attribute in the current context."
The previous paragraph says the select attribute is optional. Therefore, =
it
should state which is the string result when it's absent.

5.2.7 ns element
I still have problems understanding why doesn't schematron use the usual
xmlns: binding approach. I think we discussed this before, but still =
don't
get it :(

5.2.8 param element
> "The required value attribute is a fragment of a query."
Don't understand this. A fragment? Why?

5.2.9 pattern element
> "A structure, simple or complex."=20
Not necessary. May be removed.

5.2.10 phase element
> "The name #DEFAULT is reserved and available for use by=20
> implementations as a phase name, denoting that the name given in in =
the
phase attribute on the schema element should be used.
The "phase" attribute is missing from the schema definition in 5.2.13. =
IIRC,
you called it "default-phase" somewhere...

5.2.11 report element
> "The data context is a natural-language assertion."
Same concern as assertion.=20

5.2.12 rule element
> "A list of assertions tested within a context. The context attribute
provides the rule context expression."
Maybe reword: "A list of assertions tested within the context specified =
by
the required context attribute."

5.2.13 schema element
> "The top-level element of a Schematron schema. empty"
What does that "empty" means?
"phase" or "default-phase" is missing. According to the RelaxNG schema =
it
should be defaultPhase.

5.2.14 value-of element
> "The required select attribute is an expression evaluated in the =
current
context that returns either a string."
Either a string or what?
> "Variable references in the string are resolved ..."
Should say "Variable references in the select attribute are resolved..."

5.3 Ancilliary Elements and Attributes
Typo: ancillary.

5.3.2 diagnostic element
> NOTE 5: Diagnostics in multiple languages may be supported by using a=20
> different diagnostic element for each language, with the appropriate=20
> xml:lang language attribute, and referencing all the unique =
identifiers of
the diagnostics elements in the diagnostics attribute of the assertion.
So, each localized version of the diagnostic element must have a =
different
ID, right? I guess it would be better to allow them to all have the same =
ID
(provided they have different xml:lang attribute), so only one ID must =
be
referenced.

5.3.5 flag attribute
Can't understand what this attribute is about :(

5.3.9 role attribute
> "If the assertion has a subject attribute..."
Such attribute is not mentioned in the assert or report elements.=20
> "then the role labels the arc between the context node and any nodes =
which
match the path expression."
Not sure what that means :S ... Can you give me an example?

5.3.12 subject attribute
This is a cool addition! This could simplify grouping into more
coarse-grained rule contexts, and refining in the assertion itself.
Must say to which elements it applies (assert and report). BTW, the spec
should say pretty much up-front that an assertion is represented either =
as
an assert or a report element. Otherwise, the reader may be confused =
into
thinking we're talking about the former and not the later.

6.1 Validation Function
> "The function performs notationally performs two steps"
Typo: says performs twice.

> "two steps: transforming the schema into a simple syntax, then testing =
the
instance against the simple syntax."
I believe this is too implementation-specific. Nothing forbids an
implementation from testing an instance with the schema in a single =
step,
without transformation at all. If it's just for explanation purposes, =
it's
OK then. This is correctly stated in the following title ("To =
simplifying
the specification of semantics later, the following transformation"),
however in this location it seems as if the implementation must work =
this
way.

> "a list of name-value pairs, if the schema uses external variables."
Wowowow... External variables aren't mentioned before at all! What's =
their
syntax? If this is implementation-specific (i.e. XSLT), it should be =
left
out of the spec. Otherwise, there should be a defined mechanism to refer =
to
external variables from the schema. This is necessary because the let
(5.2.5) element definition says:
"It is an error to reference a variable that has not been defined in the
current schema, phase, pattern, or rule."
An external variable is exactly a case where it may have not been =
defined.
Or maybe the let element could be used as a slot where the external =
variable
value goes (like XSLT). In any case, this should be stated in the spec.

6.2 Simplified Syntax
> "To simplifying ..."
Typo: "simplify"

> "=97 //sch:pattern[@is-a]"
"is-a" attribute is not mentioned in 5.2.9, neither is "abstract".=20

6.4 Query Language Binding

> NOTE 8: The following other query language names are reserved without=20
> further definition. Implementions which use different
query language bindings are encouraged to use one of these names if
appropriate : stx, xslt xslt1.1, exslt, xslt2, xpath, xpath2, xquery.

One thing I note here is how should multiple languages be specified? For
example, exslt does not necessarily implies xslt support (in .NET, =
EXSLT.NET
is independent of XSLT, for example), and xpath2 may not mean exslt is =
not
supported... Maybe the query language should be a list of supported
features, such as "xslt exslt xpath xquery".=20

6.5 Order and side-effects
> "The only elements for which order is significant are the sch:rule and
sch:let elements."
This is the first time elements are mentioned with the "sch" prefix. For
consistency, it should be removed.

> "The only element which has a side-effect is key, which may provide =
extra
index information for other queries."
I believe the key element has dissapeared...

8.2 Full Conformance
> "A correct schema has one definition only in scope for any variable =
name
in any context."
Did I say I don't like this restriction much? ;)

Just like 5.2.6 (name element) says:
> "An implementation which does not report natural-language assertions =
is
not required to make use of this element."
The same may be added to both assert and report elements. That is, their
"data context" (as it's called in the spec, although I prefer "element
content") could be empty if the implementation does not report
natural-language assertions.

Annex A: RelaxNG Schema

Maybe I'm misunderstanding the schema, but most definitions use =
"inclusions"
instead of direct "include" element as specified in the spec. text. =
Although
it looks like a shortcut only...=20
Many definitions include a "linkable" attribute which isn't introduced =
in
the spec.=20
I believe both assert and report definitions should allow value-of =
children
due to "popular" demand, right?
Name element definition specifies "path" attribute instead of "select"
attribute introduced in 5.2.6.

Annex B: Schematron Schema

The following rules are unnecessary because the corresponding
element/attributes are defined as ID/IDREF/IDREFS
- Rule checking sch:active/@pattern=20
- Rule checking sch:pattern/@is-a
- Rule checking sch:extends/@rule

This only leaves the check for the version attribute.

Best regards,
/kzu

Daniel Cazzulino [MVP XML]
Clarius Consulting SA
http://weblogs.asp.net/cazzu
http://aspnet2.com =20

=20

-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of =
Rick
Jelliffe
Sent: Mi=E9rcoles, 02 de Junio de 2004 02:54 a.m.
To: [email protected]
Subject: [Schematron-love-in] Committee Draft of ISO Schematron =
available

I am happy to announce that the Committee Draft of ISO Schematron (ISO =
DSDL
Part 3) has been submitted and is available for review at
   http://www.jtc1sc34.org/repository/0524.pdf

I will also make it available at another website.  Many thanks to Martin
Bryan and others for typesetting it.  I specifically thank the open =
source
implementers of Schematron, and I would like to repeat that here.
Unfortunately, ISO rules apparantly do not allow individuals to be =
credited
in standards, otherwise I would have made a list.

I do not foresee any changes for the Committee Draft, except for some
housekeeping:
  * the names and numbers of the other parts of ISO DSDL will be updated
  * some logic symbols disappeared
  * the RELAX NG schema currently uses the compact syntax for =
readability,
and will
  be substituted

Some of you may have recently seen Dave Megginson's recent claims that =
at
ISO people make changes willy nilly in standards the night before votes
close. I wish it were so: the current expectation is that this Committee
Draft will take 12 more
months to become an ISO standard!   (A Committee Draft has a six month =
gap
until it can be voted a Draft International Standard, and a DIS has a =
six
month gap until it can be voted as a International Standard, to allow =
time
for adeqaute review by national bodies.)  In the case of Schematron, if =
I
had standardized it through, say, OASIS first, there would have been a
streamlined procedure that was more rubber-stamping.

There were a couple of minor last minute changes to ISO Schematron:--

* Following Daniel C's suggestion, I have added <let> expressions to
<schema>, <phase> and <pattern>.
 * Following UK requests, I added an @flag attribute to assertions, to =
allow
assertions to also set boolean flags.  If <assert test=3D"x" =
flag=3D"no-x">...
fails, then the validation results may include that the flag no-x has =
value
true.
 * Following UK and Japanese requests the Schematron Validation Report
Language  has been added: SRVL is  the little language I made up for the =
old
Screamatron torture  tests, and can allow better  conformance testing
between implementations (given some  test suite. )
* Following Japanese request, there is a section on how to use =
Schematron
elements  in isolation embedded in other languages, so that people can =
just
use <sch:assert>  if that is all they need.
* <pattern> may have an @id and a <title>, rather than an @name
* more attributes have been allowed in more positions, to make the =
language
more regular: for example @see

ISO Schematron is specified as an XML framework language, in which there =
are
query language bindings. XSLT 1.0 is the default bindings, but other can
(and have) been made. It is defined as a small core language, with many
ancilliary elements or attributes that an implementation can ignore but
which provide needed power for some use cases. ISO Schematron has only =
20
normative pages, plus 10 pages of publishing matter and informative =
annexes.

Please report any errors you find to me. And thanks again to everyone =
for
helping ISO Schematron get this far. As several of you know, I have =
resisted
rushing Schematron into standardization even though this has probably =
hurt
is adoption rate and visibility.

I don't foresee that any substantive changes will be made to ISO =
Schematron,
based on all indication now. So I think anyone who has been holding off
implementing (or updating their implementations) to ISO Schematron need =
wait
no longer.

Cheers
Rick Jelliffe

Editor, ISO/IEC CD 19757-3


-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X.
From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and =
evaluate
today! http://www.installshield.com/Dev2Dev/0504
_______________________________________________
Schematron-love-in mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/schematron-love-in




-------------------------------------------------------
This SF.Net email is sponsored by: GNOME Foundation
Hackers Unite!  GUADEC: The world's #1 Open Source Desktop Event.
GNOME Users and Developers European Conference, 28-30th June in Norway
http://2004/guadec.org