W3C home > Mailing lists > Public > xmlschema-dev@w3.org > October 2003

RE: [xmlschema-dev] <none>

From: Alessandro Triglia <sandro@mclink.it>
Date: Mon, 27 Oct 2003 16:50:44 -0500
To: "'Henry S. Thompson'" <ht@cogsci.ed.ac.uk>, "'Anli Shundi'" <ashundi@tibco.com>
Cc: <marktt@excite.com>, <xmlschema-dev@w3.org>
Message-ID: <002101c39cd4$631eab60$8b01a8c0@aldebaran>

Henry S. Thompson wrote:
> Anli Shundi <ashundi@tibco.com> writes:
> > Well, I think point 2 of #sch-props-correct [1]
> > excludes such multiple definitions.  From the semantics
> > of <include> [2] (point 3) both definitions of
> > such attribute are included -- they stem from two different 
> locations.
> Well, that's what I think the less-than-clear bit is -- it says:
>   "3.1 If clause 2.1 or clause 2.2 above is satisfied, then the schema
>   corresponding to SII' must include not only definitions or
>   declarations corresponding to the appropriate members of its own
>   [children], but also components identical to all the schema
>   components of I."
> Ah, right -- this example is less interesting than the one I 
> was thinking of -- I think you're right in this case there is 
> no doubt there is an error, because the base types of the two 
> attributes are clearly different:  one is xs:float, the other 
> an anonymous simple type defn.
> The case I was thinking of was where the included files are 
> different, but each contains the same XML infoset.  

Or different infosets that produce sets of components that are identical.

> In that 
> case it's open to processors to say on including the second 
> that no error occurs, because for each component in its 
> corresponding schema, there is _already_ "a component 
> identical" to it, as required by the prose above.

I don't think they should issue an error.  In an important case (clause 2.3
of  "Schema Representation Constraint: Inclusion Constraints and
Semantics"), the components that are added to the Schema are modified
versions (with their target namespace modified) of the corresponding
components of the  "valid schema I".  

This fact makes clause 3.1 a weak statement overall, in that it cannot
really mean "the same" components.  I think that all this statement can mean
is that the schema must contain components that are copies (possibly
modified if clause 2.3 applies) of the components of the "valid schema I".
In other words, the original components (those in the "valid schema I") and
the components eventually included in the schema cannot be the *same*
components, given that they sometimes differ (for the target namespace).

Are you saying that this idea of copying (possibly with modification) is not
sufficiently clear?  I see that it may be interpreted in two ways:

1) for each included schema, every component of the "valid schema I" is
copied (possibly with modification) into the final schema;  if this process
produces clashes, it is an error

2) for each included schema, every component of the "valid schema I" is
copied (possibly with modification) into the schema if and only if a
component that is identical to that component hasn't been already copied
into the schema

(1) arises from interpreting the "must include" in clause 3.1 as an action
("they must be added").  (2) arises from interpreting the "must include" in
clause 3.1 as a declaration ("they must be present").  I am inclined towards
the latter, where "include" is understood as a synonym of "contain".

Perhaps we would have no problem if clause 3.1 just said "must contain"
instead of "must include"?

Alessandro Triglia

> ht
> > [1] http://www.w3.org/TR/xmlschema-1/#sch-props-correct
> > [2] http://www.w3.org/TR/xmlschema-1/#src-include
> -- 
>   Henry S. Thompson, HCRC Language Technology Group, 
> University of Edinburgh
>                       Half-time member of W3C Team
>      2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 
> 131 650-4440
> 	    Fax: (44) 131 650-4587, e-mail: ht@cogsci.ed.ac.uk
> 		     URL: http://www.ltg.ed.ac.uk/~ht/
>  [mail really from me _always_ has this .sig -- mail without 
> it is forged spam]
Received on Monday, 27 October 2003 17:14:12 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:56:03 UTC