RE: implementing redefinitions

Hi,

On Sat, 2005-08-13 at 09:36 +0100, Michael Kay wrote:

[...]
> > 
> > Validation of instance.xsd with final.xsd
> > --------------------------------------------
> > Xerces-J:
> > base.xsd:3,29: (Error) sch-props-correct.2: A schema cannot 
> > contain two
> > global components with the same name; this schema contains two
> > occurrences of ',base_fn3dktizrknc9pi'.
> > 
> > XSV: no errors
> > 
> > This would fall into the category: first apply redefinitions, then
> > include the components. Looks like this should not fail.
> 
> Saxon says: Error on line 3 of file:/c:/temp/derived.xsd:
>   Duplicate type {base} - previously defined on line 2 of
> file:/c:/temp/base.xsd
> 
> If you include two schema documents and they contain different schema
> components with the same name, then you get an error. That's what's
> happening here, and I believe this error message is reasonable.

Ah, so probably my assumption was wrong, that redefinitions are
applied before any addition of components to parent schemas.

The picture I had here was the following:

"final.xsd" --includes--> "base.xsd" <---------------
"final.xsd" --includes--> "derived.xsd" --redefines--

There's only one schema for "base.xsd", which is first redefined,
after this all inclusions/imports of this schema will result in addition
of the redefined component, rather than the original one.
In src-expredef we have:
"Corresponding to each non-<annotation> member of the [children] of a
<redefine> there are one or two schema components in the <redefine>ing
schema:"
which seems to leave out to say _how_ it comes that there are those
component in the redefining schema:
1. is the redefined component created in the redefining schema only?
2. or is it created in the redefined schema, and then added to the
   redefining schema?
Further src-expredef.1 talks about the unnamed component: first
I thought it would be a copy of the original component, with a
name of "absent"; but I didn't see the sense of this mechanism.
Now I tend to think that the we are talking about the original
component, which name has to be set to "absent" - and probably to 
remove it from the list of toplevel components - in order to avoid
reference resolution to it.
So this all would boil down to a mechanism, where the original
component is never included twice into a schema - due to
overlapping of inclusions/imports with redefinitions - since
the redefined component would _completely_ take over the original
component's seat.

Please stop me from wandering in the swamp of possibilities and
clarify this.

 
> > Validation of instance.xsd with final5.xsd
> > ------------------------------------------
> > Xerces-J:
> > base.xsd:3,29: (Error) sch-props-correct.2: A schema cannot 
> > contain two
> > global components with the same name; this schema contains two
> > occurrences of ',base_fn3dktizrknc9pi'.
> > 
> > XSV: no errors
> 
> Saxon:
> Error on line 2 of file:/c:/temp/base.xsd:
>   Duplicate type {base} - previously defined on line 4 of
> file:/c:/temp/final5.xsd
> Error on line 4 of file:/c:/temp/final5.xsd:
>   Duplicate type {base} - previously defined on line 2 of
> file:/c:/temp/base.xsd
> Error on line 4 of file:/c:/temp/final5.xsd:
>   Duplicate type (NULL) - previously defined on line 2 of
> file:/c:/temp/base.xsd
> Error on line 4 of file:/c:/temp/final5.xsd:
>   Duplicate type (NULL) - previously defined on line 2 of
> file:/c:/temp/base.xsd
> 
> The multiple error messages are clumsy, but the meaning is fairly clear.
> > 
> > Validation of instance.xsd with final6.xsd
> > ------------------------------------------
> > Xerces-J: no errors
> > XSV: no errors
> > 
> 
> Saxon: no errors.

How does it happen that "final5.xsd" and "final6.xsd" are processed
so differently here?
When constructed, the "chain-dummy.xsd" schema should hold the
type "base" as well, as it includes "base.xsd". How does it come
that we get duplicate-component errors with "final5.xsd" and not
in "final6.xsd"? If this behaviour is expected, then why was
a mechanism chosen, which relies on using dummy schemas, in order
to make things work?

I seem to be missing a some stuff here and hope for clarification
from the schema WG.

Regards,

Kasimier

Received on Monday, 15 August 2005 11:12:18 UTC