Re: [Bug 12184] Circularity in xs:override

On Mar 10, 2011, at 8:38 AM, Henry S. Thompson wrote:

> ...

> I think I have an algorithm in mind, aimed at replacing the one at
> the beginning of appendix F.2.  Attached is a preliminary step
> towards specifying that algorithm, which _just_ addresses the
> include issue.


One small point:

The attached description of the algorithm says among other things:

> If there exists m in P such that m.uri = n.uri and m.markers =
> n.markers, then

>   • Remove n from G
>   • For all edges e such that e.to = n, remove e from G

If the nodes we are processing of schema documents, and if schema
documents are uniquely identified by their URIs, then it would seem
that the proposition 'n.uri = m.uri' implies that n = m.

Wouldn't it be simpler to say "if n is in P, then ..."?

It rather looks as if the nodes of G cannnot be schema documents
identified by URIs, but must be tuples of the form (U,M) where U is a
URI and M is a set of markers.  

We might avoid introducing the new construct of (U,M) pairs by
agreeing that a schema document can be denoted in several ways:

  - If U is a URI, then deref(U) denotes the schema document (if any)
    obtained by dereferencing U.
  - If expression S denotes a schema document and E denotes an
    xsd:override element, then override(E,S) denotes a schema document.
  - If expression S denotes a schema document and N denotes a
    namespace name, then chameleon(N,S) denotes a schema document.

This notation also has the advantage that the second and third forms
given use the notation defined in the XSD spec.

And a few larger points:

It may just be me, but I find it easier to follow declarative
descriptions of things rather than procedural ones, so I find the
style of this account difficult and it rubs me a little bit the wrong
way.  Because the account is not explicit about what we are trying to
accomplish, as a reader I don't have a strong understand of why a
particular step reads (for example)

  For all edges e such that e.to = n, remove e from G

instead of

  For all edges e such that e.to = n, flip a coin.  If the coin comes
  up heads, remove e from G; if it comes up tails, add e to Q.

Again, it may just be me, but I think it may be easier to understand
an account of how to handle inter-schema-document references if we
start with the graph of schema documents and their inter-document
references as a given rather than trying to construct it piecemeal.
The question I think our schema construction story needs to answer is
not: how do we construct a given data structure, but what is the
meaning of a given include or override element, given a particular
graph of documents and references?

In general, I think an account of schema construction might usefully
start by providing some clearly identified primitive notions, whose
meaning we all agree on, and then define other constructs in terms of
those primitive notions.  Doing that for XSD would involve ripping up
pretty much all of our existing section 4 and starting over, so I
don't think it's feasible for us at the moment. Instead, I think the
best we can do is to try to provide more explicit accounts for some of
the notions currently appealed to by the spec.

The notion most regularly appealed to by the status quo in describing
schema construction is that of "the schema corresponding to D", or
schema(D), where D is some schema document.  In principle, it ought to
be possible to define this clearly and explicitly at least for a
schema document with no references to other schema document, and for a
set of such 'solipsistic' schema documents, and to prove that it
suffices to consider a set, because the sequence in which we consider
such documents has no effect.  In practice, the spec assumes the
existence of such a definition without actually going to the bother of
providing one, which is a risky thing to do in any case and which in
the case of XSD has proven to be problematic.  But unless we want to
throw section 4 away and start over, I think we have no choice but to
wave our hands and pretend we believe the definition is obvious and
need not be spelled out.

It then remains to define the meaning of schema(D) for non-solipsistic
schema documents.

So what I miss most immediately in the sketch provided is any
statement that we are calculating schema(D) for some particular schema
document D.  Perhaps it's intended to be obvious that we are
calculating schema(D) where D is the schema document whose uri is
'root', in which case this is a stylistic remark, not a substantive
one:  it was not obvious to this reader.

But perhaps the most important is: what bug are you trying to resolve?
Your mail suggests there is an open issue that requires us to revisit,
revise, or replace the description of the override transform given in
appendix F.2; which issue is that?

Or are you operating on the assumption that (a) we need to re-open 
issue 6021, and (b) that in fact we have already agreed to re-open it?  


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

Received on Thursday, 10 March 2011 19:07:58 UTC