This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Regarding Section 5-Structured XML Output from Schematron Rules: Does this section bring any significant value over the sch:diagnostic element? It seems that XML output, if needed, can be constructed as the user sees fit using sch:diagnostic element and the Schematron <name> and <value-of> elements. In addition, ISO schematron specifies a Schematron Validation Report Language (SVRL) which is an XML 'report' file. See appendix D in the spec. Can we drop section 5 or else work within the above 2 features provided by Schematron?
*** Bug 4807 has been marked as a duplicate of this bug. ***
Since bug 4807 has been marked duplicate of this bug, I am copying below the proposal I had added to that bug. I have switched points #1 & #2 for clarifying the emphasis on pt #1. ----- I propose that we should remove this section entirely rather than spending time fixing/clarifying it. There are a couple of reasons: 1. It is strange that the SML spec even attempts to define this. This should either be implementation dependent or should be the responsibility of the schematron spec to define. 2. Support for structured xml output is optional. It will be more productive to spend our time on core (non-optional) SML issues. If we have lot of time left after fixing all core issues, we can discuss whether to bring this back.
SML spec does not define structure of error messages even for SML validation messages.
Pratul will investigate what the original pre-submission group had in mind. Valentina will investigate possible use cases for this.
The primary scenario for this was impoverished devices that were incapable of doing SML model validation but wanted to perform some actions based on validation errors. An example is a management controller card that enforces a desired configuration on a computer. The desired config can be captured as an SML model, the controller card can discover the current state of the machine and send it to a remote server for validation against the SML model, get the structure error output, and use it to peform corrective actions to bring the computer's state in compliance with the desired config. It was felt that defining a mechanism, albeit optional, in the SML spec will encourage vendors to adopt and imoplement it. Note that the above scenario is partially addressed by smlerr:output since it assumes that all desired configuration will be captured through Schematron rules. If SML identity constraints and target* constraints are used, then there is no standard mechanism for reporting these errors.
I have investigated the usage and added my comments under this note http://lists.w3.org/Archives/Public/public-sml/2007Nov/0196.html In summary : The structured XML output was defined to enable variable substitution support for localized messages, with the assumption that variable substitution cannot be achieved any other way. In the proposal I submitted for http://www.w3.org/Bugs/Public/show_bug.cgi?id=4772 , (see http://lists.w3.org/Archives/Public/public-sml/2007Nov/0195.html) I show that there is possible to have variable substitution support by just using xsl:variable. As a result, I think this structured output is not necessary and can be removed from the spec.
As a member of the private WG that submitted SML to W3C, I disagree with the following assertion in Comment #6 ____________ In summary : The structured XML output was defined to enable variable substitution support for localized messages, with the assumption that variable substitution cannot be achieved any other way. ____________ The primary scenario for this feature was the one listed in Comment #5. Localized error message support was added later, but it was not the primary driving scenario.
re comment #7 I based my comments on discussions I had with Harm Sluiman, one of the initial members of the workgroup, who had contributed to this section. I had an open action from the current group to investigate ( and by that clarify ) the usage of the XML structured output; since you were part of the initial group, which I was not aware of until now, I think it should have been easier if you owned that action.. So based on the results of my investigation which concluded that the XML output format was mainly intended for localization support, I concurred with the current proposal on removing this section as not required. As more usescases are being unveiled, usecases that contradict my findings, I am not sure if the removal proposal is still acceptable. Another think I decided to not pursue investigating due to obvious time constraints, is how this xml output format relates to the schematron validation report language http://www.dpawson.co.uk/schematron/svrl.ch.html - I assume the initial group had investigate this support and decided to create a new output under the SML spec for a valid reason.
Sorry, I was just pointing out the primary use case that drove this feature in the private WG. As I pointed out in #5, structured error output is at best a partial solution for the primary scenario. I agree with the recommendation in #6 (which is inline with the last straw poll we did on this issue) that smlerr:output should be removed from the spec.
Please remove the smlerr:output section from the SML spec - this was agreed to on the 11/19 call
fixed as per comment #10 Section removed from SML spec: 6. Structured XML Output from Schematron Rules sml-err-source.xsd modified to take out Structured XML Output types