Re: [Bug 12184] Circularity in xs:override

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

C. M. Sperberg-McQueen writes:

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

> 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.

Yes, for sure -- it's just I wanted to be clear that I wasn't
depending on any _other_ approach to determining schema doc. identity.

> 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.  

I thought I had made that clear --- yes, that's the intention.
> 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)

I sympathise -- bear with me, if you can.  I'm starting from something
I know works, namely the xs:include/xs:import processing in XSV, and
trying to abstract away from that to get to a solution to the circular
override problem and the accompanying raw/cooked schemata problem.

First an algorithm, then, with luck, a declarative statement.

> 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.

That ( computing schema(r.sd) ) is indeed the goal.  The statements 

 [T]he result of the above is a tree rooted at r [whose] leaves are
 unique. Representation checking and schema construction can then
 proceed bottom-up with respect to that tree.

are intended to indicate how a processor can use the resulting tree to
complete that task.

> 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?

12184 and 11354. I know 12184 is officially CLOSED, but I'm not
convinced the proposed fix is either complete or correct.

ht
- -- 
       Henry S. Thompson, School of Informatics, University of Edinburgh
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 651-1426, e-mail: ht@inf.ed.ac.uk
                       URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFNeUkykjnJixAXWBoRAuhCAJ4hIVWh9LPVhEp3Hu/mJELmKAlgDgCfcqtt
zS8RHP7zn66IIOJ5tZwpblE=
=GiHg
-----END PGP SIGNATURE-----

Received on Thursday, 10 March 2011 21:57:38 UTC