This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 4811 - Clarify section 6.1 regarding Schematron phases
Summary: Clarify section 6.1 regarding Schematron phases
Status: RESOLVED FIXED
Alias: None
Product: SML
Classification: Unclassified
Component: Core (show other bugs)
Version: unspecified
Hardware: PC Windows XP
: P2 normal
Target Milestone: LC
Assignee: Virginia Smith
QA Contact: SML Working Group discussion list
URL:
Whiteboard:
Keywords: resolved
: 4655 (view as bug list)
Depends on:
Blocks:
 
Reported: 2007-06-27 23:10 UTC by Bassam Tabbara
Modified: 2007-11-12 22:54 UTC (History)
1 user (show)

See Also:


Attachments

Description Bassam Tabbara 2007-06-27 23:10:23 UTC
 
Comment 1 Bassam Tabbara 2007-06-28 00:01:19 UTC
From old open issue in Appendix E:

Do we need to support an sml:phase attribute (similar to the phase attribute in Schematron) that can be used for selective validation of SML constraints? Should this be extended to apply to XML Schema constraints?

Comment 2 Virginia Smith 2007-06-28 19:29:36 UTC
*** Bug 4655 has been marked as a duplicate of this bug. ***
Comment 3 Virginia Smith 2007-10-17 20:02:58 UTC
Ginny will follow up on this.
Comment 4 Virginia Smith 2007-10-31 23:01:03 UTC
An SML validator must support the ISO schematron spec and this spec includes the phase element which makes specific patterns/rules active or inactive in a particular validation run. 
  
I would consider an SML model "valid" only when validating on the #ALL phase but there would be times when a phased validation is useful. If a phase validation is used, then the model is only "phase-valid". 
  
I propose that we do the following:

1. Remove the statement (#3) from Section 7 regarding the #ALL phase.
2. Change #5 from:
Each document in the model MUST satisfy all applicable Schematron constraints.
to:
Each document in the model MUST satisfy all applicable Schematron constraints when validated in the #ALL phase.
Comment 5 Virginia Smith 2007-11-01 20:02:12 UTC
Initial proposal during Thurs meeting:
#3 should be rephrased to support just Schematron (remove reference to #ALL)

Split 2nd section into 2 parts:
part 1 - "conforming model" with #1-3 
part 2 - "valid model" with #4-7, reword #5 as proposed.

Sandy has concerns with this which he will email.
Comment 6 Kumar Pandit 2007-11-01 20:33:24 UTC
Here is the proposed new text:
==============================


7. Conformance Criteria
A program is a conforming SML model validator if it satisfies the following conditions:
1.	The validator MUST perform model validation as defined in this specification. Model validation is the process of examining each document in a model and verifying that this document is valid with respect to the model definition documents, i.e., each model instance document satisfies the schemas and rules defined in the applicable model definition documents.
2.	The validator MUST support XML, XML Schema and XPath but MAY also support any future versions of these specifications.
3.	The validator MUST support schematron [ISO/IEC 19757-3].

A set of XML documents is a conforming SML model if it satisfies the following conditions:
1.	Each document in the model MUST be a well-formed XML document [XML]
2.	Each XML Schema document in the model's definition documents MUST satisfy the conditions expressed in Errors in Schema Construction and Structure (§5.1). [XML Schema Structures]
3.	Each Schematron document in the model's definition documents MUST be a valid Schematron document [ISO/IEC 19757-3]

A conforming SML model is valid if it satisfies all of the following conditions:
1.	In each instance document in the model, the [validity] property of the root element and all of its attributes and descendants MUST NOT be "invalid" when schema validity is assessed by a conforming schema-aware processor with respect to the referenced XML Schema documents in the model's definition documents. [XML Schema Structures]
2.	Each document in the model MUST satisfy all applicable Schematron constraints when validated in the #ALL phase.
3.	Each document in the model MUST satisfy all applicable sml:acyclic and sml:target* constraints.
4.	Each document in the model MUST satisfy all applicable SML identity constraints.

Comment 7 Virginia Smith 2007-11-09 01:31:37 UTC
Per discussion during the 11/08 teleconference, I propose the following:

-> Accept proposal in comment #6, with a change in bullet point #2 in first section of new text as follows (I added normative references):

2. The validator MUST support XML [XML], XML Schema [XML Schema Structures, XML Schema Datatypes] and XPath [XPath] but MAY also support any future versions of these specifications.


-> Add bullet point 4 in the first section of new text as follows:

4. The validator MUST perform Schematron rule evaluation on the #ALL phase.


-> I want to point out that Bug #5070 intersects with this bug so there is a new bullet #5 in the first section (as a result of the fix for Bug #5070):

5. The validator MUST support the deref() XPath extension function.
Comment 8 Kumar Pandit 2007-11-09 02:57:52 UTC
I agree with Ginny's suggestion.
Comment 9 Kumar Pandit 2007-11-10 07:05:12 UTC
adding Sandy's comments for easy reference:
================================

From: public-sml-request@w3.org [mailto:public-sml-request@w3.org] On Behalf Of Sandy Gao
Sent: Monday, November 05, 2007 8:25 AM
To: Smith, Virginia (HP Software)
Cc: public-sml@w3.org
Subject: [w3c sml] About Conforming Processor (was [Bug 4675] ...)


Ginny, 

About "conformance", here's my theory. There are actually 3 levels we could be talking about conformance. 

1. A particular invocation 

This is the easiest to understand. If this invocation procures expected result, it's conformant; otherwise it's not. 

2. A particular configuration 

To know things statically, "invocation" level isn't always useful. If invocations under a certain configuration (parameters, environment, etc.) always produce expected results, then this configuration is conformant. 

3. A particular piece of software 

Software may want to provide multiple modes/configurations. Some of them may be conformant; and some not. We often say the software is conformant if a subset of its configurations are conformant. 


When a spec talks about conformance, it's about behavior, so it's really about a particular invocation, which can be reasonably extended to configurations. But it's not about software. 


Using the above definition, 

> Can a conforming process that
> supports all specification requirements/features all of a sudden not be
> a conforming process (momentarily) because it is behaving in a manner
> not covered in the spec when **specifically requested to do so**? 

That momentarily non-conformance is about a particular invocation/configuration. This does not make the validator non-conformant, as long as it can run in a mode that has conformant invocations. 

> This
> ties in with Sandy's comments in the last meeting regarding schematron
> phases. SML specifies that an IF document is 'valid' if valid in the
> #ALL phase and that conforming producers must support Schematron (which
> means phases). I don't see how a conforming validator can be classified
> as non-conforming just because it also allows some non-SML features to
> be invoked by a user (such as a non-ALL phase validation). 

In the above case, I don't think the validator should be classified as non-conforming. Just like if my SML validator has a mode for "don't check sml key/keyref constraints", it should still be conforming, as long as it has a mode that does check that. 

On the other hand, I do believe the spec should be consistent in terms of conformance. Allowing conforming invocations/configurations to accept non-conforming models makes me uncomfortable. Also it's not the spec's responsibility to explicitly allow all different useful non-conforming ways people may want to invoke the validator. 

But I can live with the change if other people agree (see my other mail), in the spirit of "let's make things go faster". :-) 

Thanks,
Sandy Gao
Comment 10 Pratul Dublish 2007-11-12 21:24:32 UTC
Fix as per COmment #7
Comment 11 Virginia Smith 2007-11-12 22:54:43 UTC
Fixed as proposed. Section 7 now reads:

==========
7. Conformance Criteria

A program is a conforming SML model validator if it satisfies the following conditions:

   1. The validator MUST perform model validation as defined in this specification. Model validation is the process of examining each document in a model and verifying that this document is valid with respect to the model definition documents, i.e., each model instance document satisfies the schemas and rules defined in the applicable model definition documents.
   2. The validator MUST support XML XML], XML Schema [XML Schema Structures], and XPath [XPath] but MAY also support any future versions of these specifications.
   3. The validator MUST support Schematron [ISO/IEC 19757-3].
   4. The validator MUST perform Schematron rule evaluation on the #ALL phase.
   5. The validator MUST support the deref() XPath extension function.

A set of XML documents is a conforming SML model if it satisfies the following conditions:

   1. Each document in the model MUST be a well-formed XML document [XML]
   2. Each XML Schema document in the model's definition documents MUST satisfy the conditions expressed in Errors in Schema Construction and Structure (§5.1). [XML Schema Structures]
   3. Each Schematron document in the model's definition documents MUST be a valid Schematron document [ISO/IEC 19757-3]

A conforming SML model is valid if it satisfies all of the following conditions:

   1. In each instance document in the model, the [validity] property of the root element and all of its attributes and descendants MUST NOT be "invalid" when schema validity is assessed by a conforming schema-aware processor with respect to the referenced XML Schema documents in the model's definition documents. [XML Schema Structures]
   2. Each document in the model MUST satisfy all applicable Schematron constraints constraints when validated in the #ALL phase.
   3. Each document in the model MUST satisfy all applicable sml:acyclic and sml:target* constraints.
   4. Each document in the model MUST satisfy all applicable SML identity constraints.