[
http://issues.apache.org/jira/browse/XERCESJ-1112?page=comments#action_12358687
]
Sandy Gao commented on XERCESJ-1112:
------------------------------------
> A) I moved the redefinition of the complex type ("contentType") into the
> first <redefine> element.
Actually, another evidence that the spec needs improvement. From the spec:
"The definitions within the <redefine> element itself are restricted to be
redefinitions of components from the <redefine>d schema document, in terms of
themselves."
where it clearly mentions "schema document". Also
"1.1 One component which corresponds to the top-level definition item with the
same name in the <redefine>d schema document, as defined in Schema Component
Details (ยง3), except that its {name} is - absent- ;"
where again, "schema document" is used. So at least parts of the spec indicate
that you can only redefine components in the redefined schema document, hence
you are *not* allowed to redefine "contentType" in a redefefinition of
"elementGroups.xsd".
But I do agree with you that it'd be helpful to allow this, which is why I
raised [1].
> B) I have replaced the <redefine> element by a simple <include> element
Yes, Xerces can handle it; and yes, Xerces should handle the one-redefine case
(note that this is different from your scenario #A).
> C) I have used the <redefine> with no redefinition in
Another fixable bug. Didn't want to give this one a high priority because
people don't typically have empty <redefine>s. Given that I'm already working
on the other fix, I'll take a stab at this one too.
Again, this is different from what you are asking for. To make you happy
(either by allowing your original redefinitions, or by allowing your #A), more
serious work needs to be done. I really want to defer that untill we get some
clear direction from the schema WG.
Unfortunately, given the size and workload of that group (of which I'm a
member), I don't see this as something that can be resolved quickly. I'll try
...
[1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=2330
> The parser do no support multiple inclusions of the same "sub"-schema
> ---------------------------------------------------------------------
>
> Key: XERCESJ-1112
> URL: http://issues.apache.org/jira/browse/XERCESJ-1112
> Project: Xerces2-J
> Type: Bug
> Components: XML Schema Structures
> Versions: 2.7.1
> Environment: Any platform. Problem exists on any version of Xerces
> Reporter: Jean-Jacques Thomasson
> Assignee: Sandy Gao
> Attachments: ParseWithXerces.zip, bugXercesStudy.zip, dm.zip,
> dmodule_descriptSchema_flat.xsd
>
> An example :
> In a schema named "complexTypes.xsd", we define the following inclusions :
> <xs:include schemaLocation="attributeGroups.xsd"/>
> <xs:include schemaLocation="simpleElements.xsd"/>
> <xs:include schemaLocation="complexElements.xsd"/>
> <xs:include schemaLocation="elementGroups.xsd"/>
> and, in "complexEelements.xsd", we use the following inclusions :
> <xs:include schemaLocation="complexTypes.xsd"/>
> (Since we need element definitions to define complexTypes and vice-versa).
> Most of the parsers (XSV, XMLSpy) are now supporting this kind of
> self-mirroring inclusions which is admitted by the W3C recommendation (Note
> 2 of section 4.2.1 "Schema Representation Constraint: Inclusion Constraints
> and Semantics ").
> But Xerces produces (a series of) the following sample message :
> "[Error] complexTypes.xsd:32:54: sch-props-correct.2: A schema cannot contain
> two global components with the same name; this schema contains two
> occurrences of ',contentType_fn3dktizrknc9pi'."
> It is an important matter of concern for industries wishinig to have a
> complex architecture of schemas such as the aeerospace industry.
> Please, could you look at this ?
> Jean-Jacques Thomasson
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
