Re: Feedback on candidate recommendation

Philip Wadler writes:

>> Doing this in a functional way means forgetting everything about
>> the surrounding schema 1 until the validator leaves
>> <element ref="B:B1"/>. Thus the declaration of
>> <element name="A1" equivClass="B:B1">
>> is not available when processing the data inside the "start" elements
>> (<A:A1>...</A:A1>)!!!

I am not 100% sure I follow your concern, but I think your propsal to 
"forget about surrounding schema 1" conflicts with the requirements that 
[1]: 

*  The processor succeed in locating the schema components transitively 
required to complete an assessment (note that components derived from 
schema documents can be integrated with components obtained through other 
means); 
* no definition or declaration changes once it has been established; 
* if the processor chooses to acquire declarations and definitions 
dynamically, that there be no side effects of such dynamic acquisition 
that would cause the results of assessment to differ from that which would 
have been obtained from the same schema components acquired in bulk. 

First of all, it is known and intentional that equivalence classes (now 
called substitution groups) do support interactions across namespaces.  It 
is further known, and I _think_ this is the essence of your concern, that 
a reference to the head of such a group represents a disjunction (a 
choice) across all the elements in the group, and that the content model 
can therefore be seen to "change" as you dynamically aquire schemas.  I 
think you will find that the rules above require you to (1) produce 
consistent results in any given validation...the same reference doesn't 
fail validate content at the beginning of a document that would later be 
accepted and (2) if you choose to create DFA's for content models 
aggressively, and you also choose to acquire schema documents dynamically, 
then a consequence is that you may have to recompute such DFA as new 
substitution group members are acquired.  This was a conscious design 
decision.  An alternative that some schema processors will choose to 
pursue is to identify all schema documents before beginning, either by 
getting them from a command line or by prescanning the instance for 
schemaLocation hints (if you're not streaming); if you know all schemas in 
advance you can build each DFA once.

In general, your suggestion that one might tentatively "forget" schema 1 
seems to conflict with the 2nd requirement above.  Our model is that the 
entire schema as stable throughout the validation, except insofar as you 
may choose to dynamically assemble the pieces up to the time they are 
first needed.  Think of it more like paging in pieces of a conceptually 
static set, rather than dynamically changing or deleting definitions or 
declarations.

I hope I have correctly understood your concerns and that this explanation 
is useful.

[1] http://www.w3.org/TR/xmlschema-1/#layer1

------------------------------------------------------------------------
Noah Mendelsohn                                    Voice: 1-617-693-4036
Lotus Development Corp.                            Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------------







Philip Wadler <wadler@research.bell-labs.com>
Sent by: www-xml-schema-comments-request@w3.org
01/16/01 01:55 PM

 
        To:     ht@cogsci.ed.ac.uk (Henry S. Thompson)
        cc:     Philip Wadler <wadler@research.bell-labs.com>, 
www-xml-schema-comments@w3.org, (bcc: Noah Mendelsohn/CAM/Lotus)
        Subject:        Re: Feedback on candidate recommendation


Henry requested more details on the problem with the interaction
between import and substitution.  Volker's response follows.  -- P

  Date: Tue, 16 Jan 2001 19:18:06 +0100
  From: Volker Renneberg <volker.renneberg@acm.org>

The problem is how to check the document. The element tagged with
"start" can be found in schema 1 (uri_for_A). Afterwards the validator
steps down into "complextype" where the it finds a reference to
element B1 which resides in schema 2 (uri_for_B).

Now it depends on the validator implementation. My first version had a
_current_ schema (containing all the imported and included schemas)
which was passed to all methods. While stepping into an import (like
<element ref="B:B1"/>) it extracted the new "current" schema,
i. e. schema 2 (uri_for_B).

Doing this in a functional way means forgetting everything about
the surrounding schema 1 until the validator leaves
<element ref="B:B1"/>. Thus the declaration of
<element name="A1" equivClass="B:B1">
is not available when processing the data inside the "start" elements
(<A:A1>...</A:A1>)!!!

My solution for this problem means getting away from the hierarchical
view towards a plain list of all known schemas (1 -> schema 1 | 2 ->
schema 2 | ...). Additionally the number of the current schema and a
list of numbers describing the way down to the current schema are
provided. For example, while checking <A:A1>...</A:A1>, the current
schema number would be 2 and the list would be [1], because the
validator stepped from schema 1 to schema 2.

This solution allows to step back through all schemas and to look for
existing equivClass-declarations.

I hope this helps although it's a little bit difficult to describe.

> I passed on to the Schema working group your comments about
> difficulties you encountered implementing Schema.
> They asked for more details on the following comment:
> 
>   - interaction between equivalence classes and import:
>
>   <schema targetNamespace="uri_for_A" xmlns:B="uri_for_B">
>     <import targetNamespace="uri_for_B"/>
>     <element name="start">
>       <complextype>
>                <element ref="B:B1"/>
>       </complextype>
>     </element>
> 
>     <element name="A1" equivClass="B:B1">
>       ...
>     </element >
>   </schema>
> 
>   <schema targetNamespace="uri_for_B">
>     <element name="B1">
>       ...
>     </element >
>   </schema>
> 
>   document:
>   <A:start xmlns:A="uri_for_A">
>     <A:A1>...</A:A1>
>   </A:start>

Received on Wednesday, 17 January 2001 17:34:57 UTC