This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Given the discussion that we have had regarding the "strict" and "lax" behavior (of validators vs. non-validating consumers) and in impact that that discussion has had on the definition of the deref() function (see Sandy's ReferencesIssue.doc discussions), I would like to recommend that we DROP the requirement that a validator MUST provide an implementation for deref(). A validator MUST attempt to *resolve* references under the requirements of strict behavior, but this behavior does not require an implementation of deref(). The validator may implement the validation behavior by some other implementation.
Validators MUST provide an implementation of deref() - otherwise they can't evaluate SML identity constraints and Schematron constraints that make use of the deref() function.
Comment accepted! However, the context in which the normative statement is made (section 4.1.2.4) provides a misleading context (IMHO). 4.2.1.4 states: Each model validator MUST provide an implementation of the deref() XPath extension function that is capable of resolving references expressed in the model validator's chosen scheme(s). To be sure, this section gives the semantics of the deref() function, but NOT the reason why a model validator has to implement it. I would recommend that the requirement on the model validator in this regard should be moved to section 4.4 and its rationale augmented to include the text of comment #1.
4.4 covers SML identity constraints but deref() is also needed for Schematron constraints. I am OK with moving this requirement to Section 7 (Conformance Criteria)
Yes, I agree with the recommendation in comment #3--move the requirement to section 7.
I agree with the effective result of the comments from Kirk & Pratul. It is summarized in the proposal below. It does not add anything new. Proposal: Based on the earlier comments, add the following line to section "7. Conformance Criteria" The validator MUST provide an implementation of the deref() XPath extension function.
I'm not sure what this would mean. An SML processor/validator takes an SML model as input, and produce results about its validity and apply schema/schematron rules. What does it mean for it to provide a deref() implementation? That can be used outside of the context of SML validation? Note that this is an XPath function. Are we imagining that some XPath processing is performed after the model is validated, and the XPath engine can use the validator's deref() implementation when evaluating XPaths?
A deref() function is required for validation. One cannot evaluate SML identity constraints and schematron constraints without it. The proposal simply says that we should explicitly state this requirement in the conformance section.
Responding to Comment #6, the deref() XPath extensions function is NOT a standard XPath 1.0 function (i.e. it is not defined in the XPath 1.0 spec). Each SML validator needs to implement the deref() function so that it can evaluate the SML identity constraints and Schematron asserts/reports, all of which can use the deref() function. There is no requirement that the validator must provide/expose its deref() implementation to XPath engines, but I suspect that most validators will find it convenient to use existing XPath 1.0 engines by providing the deref() function to XPath 1.0 engines. So is the following text acceptable? MODIFIED PROPOSAL The validator MUST implement the deref() XPath extension function.
I agree that a validator must implement deref() but does not have to expose it to other programs. This was not the intention when I wrote the proposal. I can see that it could be interpreted that way. I believe Pratul's suggested wording from comment# 8 is more precise. The validator MUST implement the deref() XPath extension function.
pls fix as per Comment #9
-----Original Message----- From: Kumar Pandit Sent: Monday, November 05, 2007 9:46 AM To: Smith, Virginia (HP Software); public-sml@w3.org Subject: RE: [Bug 5070] Requirement for validator to implement deref() I agree. 'MUST support' sounds good. If everyone is ok with this, we can go with 'MUST support'. -----Original Message----- From: Smith, Virginia (HP Software) [mailto:virginia.smith@hp.com] Sent: Saturday, November 03, 2007 3:46 PM To: Kumar Pandit; public-sml@w3.org Subject: RE: [Bug 5070] Requirement for validator to implement deref() I'm ok with that. I assume that a reasonable interpretation of this sentence is that a validator is free to make use of a 3rd party implementation of the deref() function... "MUST support" also sounds good.
Fixed. Added to the conformance section: "The validator MUST support the deref() XPath extension function." I used support instead of implement since support covers both cases as suggested by Ginny. -- implement -- use some other implementation