RE: Including schemata with duplicate referents

> -----Original Message-----
> From: xmlschema-dev-request@w3.org 
> [mailto:xmlschema-dev-request@w3.org] On Behalf Of Michael Kay
> Sent: Friday, November 05, 2004 15:56
> To: 'Alessandro Triglia'; xmlschema-dev@w3.org
> Subject: RE: Including schemata with duplicate referents
> 
> 
> 
> > Yes, but you are saying "from" a component.  When a <schema> 
> > includes another <schema>, there must be a valid Schema 
> > corresponding to the included <schema>.  Unless there are 
> > circular includes/imports, it must be possible to resolve all 
> > the references in the included <schema> before doing the 
> > inclusion, otherwise you won't have a "valid schema".
> 
> No, we had a discussion on that point on this list a few 
> weeks ago. Section
> 4.2.1 says:
> 
> <quote>
> As discussed in Missing Sub-components (§5.3), ˇQNameˇs in XML
> representations may fail to ˇresolveˇ, rendering components 
> incomplete and
> unusable because of missing subcomponents. During schema construction,
> implementations must retain ˇQNameˇ values for such 
> references, in case an
> appropriately-named component becomes available to discharge 
> the reference
> by the time it is actually needed.
> </quote>
> 
> Despite various other phrases that appear to contradict this, 
> it seems that
> the intent of the spec is that when <schema> A includes 
> <schema>s B and C,
> you can have references from components in B to components in 
> C, and from B
> to A.


I had missed that discussion.  I have gone quickly through it now.

If that's the intent, I think it is a mistake to specify inclusion in terms
of a "valid schema", corresponding to a <schema>, whose components must be
part of the new schema.

Delayed resolution of QNames has a temporal dimension, and therefore
inclusion (which is affected by that) should be specified as a process, not
as a constraint.  The specification of that process should explicitly say
how and when QNames are to be resolved.

In other words, I think the problem with the current text is the separation
between a static (time-less) specification of the "inclusion semantics" (the
numbered clauses) and an subsequent statement saying that, by the way, you
can resolve QNames later during schema construction (but what is "schema
construction"?  it is not defined anywhere, and like some other key concepts
- like "valid schema" -, it is used only once).

I think a reformulation of 4.2.1 to properly support delayed resolution of
Qnames should *not* use the concept that the schema corresponding to a
<schema> provides the components to be included in the new schema.  It seems
more correct to say that the <schema> provides information items from which
a set of components can be built incrementally during the process.  In other
words, if inclusion cannot be completely specified in terms of schema
components (and it can't, given the interference from the late resolution of
QNames), it should be expressed in terms of the XML representation.  In some
cases, the final set of components will be available only at the end of the
process.   

At the end of the process, it is still possible that some components have
missing subcomponents, but those subcomponents are just "missing", not "to
be provided later".

Alessandro Triglia


> 
> Michael Kay
> 
> 
>

Received on Friday, 5 November 2004 23:15:42 UTC