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 5070 - Requirement for validator to implement deref()
Summary: Requirement for validator to implement deref()
Alias: None
Product: SML
Classification: Unclassified
Component: Core (show other bugs)
Version: unspecified
Hardware: PC Windows XP
: P2 normal
Target Milestone: ---
Assignee: Kumar Pandit
QA Contact: SML Working Group discussion list
Depends on: 4683
  Show dependency treegraph
Reported: 2007-09-24 19:52 UTC by Kirk Wilson
Modified: 2007-11-06 19:53 UTC (History)
0 users

See Also:


Description Kirk Wilson 2007-09-24 19:52:15 UTC
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.
Comment 1 Pratul Dublish 2007-09-24 19:58:00 UTC
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 2 Kirk Wilson 2007-09-24 20:15:56 UTC
Comment accepted!  However, the context in which the normative statement is made (section provides a misleading context (IMHO). 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.
Comment 3 Pratul Dublish 2007-09-24 21:11:56 UTC
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)
Comment 4 Kirk Wilson 2007-09-24 23:05:08 UTC
Yes, I agree with the recommendation in comment #3--move the requirement to section 7.  
Comment 5 Kumar Pandit 2007-10-24 03:42:10 UTC
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.

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.
Comment 6 Sandy Gao 2007-10-25 17:52:29 UTC
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?
Comment 7 Kumar Pandit 2007-10-26 04:37:06 UTC
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.
Comment 8 Pratul Dublish 2007-11-03 20:27:43 UTC
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?

The validator MUST implement the deref() XPath extension
Comment 9 Kumar Pandit 2007-11-03 20:51:42 UTC
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.
Comment 10 Pratul Dublish 2007-11-06 16:33:02 UTC
pls fix as per Comment #9
Comment 11 Kumar Pandit 2007-11-06 18:57:38 UTC
-----Original Message-----
From: Kumar Pandit
Sent: Monday, November 05, 2007 9:46 AM
To: Smith, Virginia (HP Software);
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) []
Sent: Saturday, November 03, 2007 3:46 PM
To: Kumar Pandit;
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.
Comment 12 Kumar Pandit 2007-11-06 19:02:44 UTC
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