On 27 Apr 2009, at 10:03 , Costello, Roger L. wrote:

>
>> Making the 'available documents' property be the empty set helps
>> ensure (a) better interoperability between validators, and (b) the
>> context-independence of schema-validity assessment of an element
>> or attribute against a declaration or type definition.  The
>> context-independence of validation against a type is important to
>> many users of XSD (although not, I suspect, to all).
>
> I'm not clear on (b) but (a) certainly sounds like the decision to  
> disallow doc() for cross-document validation was done to make it  
> easier to implement 1.1 schema validators. Validators are built  
> once, but used many times. Disallowing doc() seems to sacrifice XSD  
> 1.1 usability in favor of ease of validator implementations.

Er, not necessarily, no.  Ensuring better interoperability is not
the same as ensuring easier implementability (although they are
also connected).

XPath 2.0 says the set of available documents is to be "initialized
by mechanisms defined by the host language".  In XSLT 2.0 and XQuery
1.0, it is implementation-defined what documents are available.
(Actually, I'm not entirely clear whether in XQuery it's
implementation-defined or implementation-dependent -- but it's
certainly not defined by the spec.)

XSD 1.1 thus faces the choice:

   - Define a fixed non-empty value for 'available documents'?
     (How? What documents should be included?)
   - Make the set implementation-defined?  (So your proposed
     assertion would make country code 'France' valid in one
     processor, which included 'countries.xml' in its set of
     available documents, and make it invalid in a different
     processor which chose to make 'available documents' the
     empty set.  Having different processors produce different
     validation results for the same inputs is something some
     people would incline to regard as an interoperability
     problem.
   - Specify that the set is empty.

If ease of implementation were the main criterion, I think the
WG might have chosen to make the property implementation-defined;
that way an XSD implementor could use an off-the-shelf
XPath 2.0 implementation and let it do whatever it wanted to
do about the 'available documents' property.

Different people may well prefer different tradeoffs here.
Those in the WG who might have preferred that the available
documents component of the dynamic context be
implementation-defined will have seen, if they had eyes to
see, that others in the WG would be adamantly opposed to
that decision.  Which would they rather have?  Assertions
without implementation-defined 'available documents'? Or
no assertions at all?  From the presence of assertions in
the spec in their current form, you can infer the choice
those members of the WG made on that question.

As I've illustrated in other mail this morning, I don't think
XSD's decision in this area actually prevents anyone from
checking the values of 'country' elements in one document
against the values of 'country' elements in another document;
it just means they won't do it via an assertion.
So the usability of the spec in actual situations does not seem
to me to take too big a hit from this particular decision.

So it says here that it's better to have assertions in their
current form than no assertions at all.  YMMV.

-- 
****************************************************************
* C. M. Sperberg-McQueen, Black Mesa Technologies LLC
* http://www.blackmesatech.com
* http://cmsmcq.com/mib
* http://balisage.net
****************************************************************





From rjelliffe@a... Tue Apr 28 07:56:03 2009
Received: from maggie.w3.org ([193.51.208.68])
	by frink.w3.or