The terms 'implementation-defined' and 'implementation-dependent' are
both used in the current version of the spec.  They need to be
defined, and I think they could usefully be used more consistently.
This bug report makes several proposals in this connection.

1) Adopt the distinction between implementation-defined and -dependent
used in the QT and XSD specs.

In the XSLT / XPath / XQuery (aka QT) specs, the two terms are used to
make an important and useful distinction, and I propose that we should
follow their usage and make a similar distinction.  The terms are
defined in XPath 2.0 thus:

    Certain aspects of language processing are described in this
    specification as implementation-defined or
    implementation-dependent.

        - [Definition: Implementation-defined indicates an aspect
          that may differ between implementations, but must be
          specified by the implementor for each particular
          implementation.]  *

        - [Definition: Implementation-dependent indicates an aspect
          that may differ between implementations, is not specified by
          this or any W3C specification, and is not required to be
          specified by the implementor for any particular
          implementation.]

XPath 2.0 adds:

    A language aspect described in this specification as
    implementation-defined or implementation dependent may be further
    constrained by the specifications of a host language in which
    XPath is embedded.

If we expect SML to be embedded in, or referred to normatively by
other specs, we might want to say something similar to that last.

XSLT 2.0 uses different words but makes the same essential
distinction:

    [Definition: In this specification, the term
    implementation-defined refers to a feature where the
    implementation is allowed some flexibility, and where the choices
    made by the implementation must be described in documentation that
    accompanies any conformance claim.]

    [Definition: The term implementation-dependent refers to a feature
    where the behavior may vary from one implementation to another,
    and where the vendor is not expected to provide a full
    specification of the behavior.] (This might apply, for example, to
    limits on the size of source documents that can be transformed.)

    In all cases where this specification leaves the behavior
    implementation-defined or implementation-dependent, the
    implementation has the option of providing mechanisms that allow
    the user to influence the behavior.


2) Retain the term 'implementation-defined' in some places

We use the term 'implementation-defined' in several places where it
seems to me to be the right one to use:

  - SML 4.2.3 Identical Targets, bullet 3
  - SML 4.2.7 deref() XPath Extension Function, bullet 1.b
  - SML-IF 5.4.3 Schema Bindings, bullet 2.d
  - SML-IF 5.4.3 Schema Bindings 3.c


3) Change from 'implementation-dependent' to 'implementation-defined' 
w.r.t the base URI used in absolutizing relative references

There are several places where we currently use the term
'implementation-dependent', but mean (or I think should mean)
'implementation-defined', if we adopt the usage of QT.  Two of them
relate to base URI choice.

SML 4.3 SML Reference Schemes, bullet 3.b, says

  b. If these references are allowed to be relative references,
     i.e. they are not already target-complete, then some
     implementation-dependent base URI or IRI is used to resolve them
     to URIs or IRIs. (See section 5 of [IETF RFC 3986] and section
     6.5 of [IETF RFC 3987].)

SML 4.3.1 SML URI Reference Scheme, bullet 2.a, says

  a. If the URI is a relative reference, then use an
     implementation-dependent base URI to resolve it to an URI.

Personally, I agree with Henry Thompson's position (bug 5542) that we
should use xml:base to specify the base URI, and that there should be
nothing implementation-defined or -dependent about it.  But even if we
don't do that, we should not specify that a processor is allowed to
use any base URI it likes and is not required to tell the user how the
base URI is chosen, or to choose it the same way from moment to
moment.

(Also, w.r.t. 4.3.1, I think that the phrase "an URI" should probably
be "an absolute URI", but I have not checked the RFCs for
terminology.)


4) Change rule binding descriptions from 'implementation-dependent' to
'-defined'.

SML 6.1 Informal Description [of rules] (Non-Normative), final
paragraph says

  The binding of the rule document containing the StudentPattern
  pattern to documents that may contain instances of StrictUniversity
  element is implementation-dependent and hence outside the scope of
  this specification.

SML 6.4.1 Rule Binding, last sentence of para

  The mechanism for binding rule documents to a set of documents in a
  model is implementation-dependent and hence outside the scope of
  this specification.

In order to be usable, an implementation is going to have to tell
users how to arrange for rule documents to be bound to other
documents; that means 'implementation-dependent' is not sufficient.


5) Consider whether behavior when documents are unreachable is
implementation-defined or implementation-dependent.

There is one place where we currently use the term
'implementation-dependent' where it is not obviously wrong, but where
we should probably consider explicitly whether we should say
'-dependent' or '-defined'.

SML 8. Conformance Criteria says

  If any model document is not reachable, then the model validator's
  behavior is implementation-defined.

I'm not sure what the pros and cons on either side of the choice are.