RE: Committee Draft of ISO Schematron available
"Daniel Cazzulino" <[email protected]> Thu, 24 Jun 2004 14:51:07 -0300
| Newsgroups | gmane.text.xml.schematron |
|---|---|
| Organization | Lagash Systems SA |
| Message-ID | <[email protected]> |
Another one: 5.3.6 fpi attribute A formal public identifier for the schema or phase. =20 According to the RelaxNG schema, not only schema or phase can have this attribute (that belongs to the rich definition). -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of = Daniel Cazzulino Sent: Lunes, 07 de Junio de 2004 04:26 p.m. To: [email protected] Subject: RE: [Schematron-love-in] 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=20 > 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=20 > 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=20 > 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=20 > 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=20 > 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=20 > 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=20 > 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=20 > 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=20 > 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 - 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 _______________________________________________ Schematron-love-in mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/schematron-love-in ------------------------------------------------------- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com