Home. 
.

transparent

transparent

transparent

Altova Mailing List Archives


RE: implementing redefinitions

From: Kasimier Buchcik <kbuchcik@---------.-->
To: Michael Kay <mike@--------.--->
Date: 8/15/2005 3:12:00 PM
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

From mike@s... Mon Aug 15 16:52:55 2005
Received: from lisa.w3.org ([128.30.52.41])
	by frink.w3.org with esmtp (Exim 4.50)
	id 1E4iCl-0006Pq-NE
	for


transparent
Print
Mail
Digg
delicious
Disclaimer
.

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.

.
.

transparent

transparent