[
https://issues.apache.org/jira/browse/WSCOMMONS-428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benson Margulies resolved WSCOMMONS-428.
----------------------------------------
Resolution: Fixed
Fix Version/s: XmlSchema 2.0
> Name-related functions are error prone and inconsistent
> -------------------------------------------------------
>
> Key: WSCOMMONS-428
> URL: https://issues.apache.org/jira/browse/WSCOMMONS-428
> Project: WS-Commons
> Issue Type: Bug
> Components: XmlSchema
> Affects Versions: XmlSchema 1.4.3
> Reporter: Benson Margulies
> Assignee: Benson Margulies
> Fix For: XmlSchema 2.0
>
>
> Several objects in Xml Schema are named: elements, attributes, types. They
> have slots for a QName and a plain String name.
> This leads to a lot of possibility for inconsistency and error.
> Roughly, the idea is this:
> <xs:element name="foo"/>
> That element has a qualified name, even if it is a nested element in a
> sequence and not a global element. The namespace is the TNS of the containing
> schema. For convenience, setting the name and not the qualified name
> indicates this situation. Type objects store a reference to the containing
> schema, so that it's not hard to determine the QName. Element objects do not.
> Nothing checks for or enforces consistency between the QName and the 'name'.
> Further, some of these things can be ref= to somewhere else. Nothing checks
> for or enforces consistency of the presence of a ref QName versus any of
> these names.
> I think that the solution here is (a) create an interface,
> XmlSchemaNamedObject, and (b) create a delegate class that stores these names
> and manages them. Force all such objects to be constructed against a specific
> schema, and then arrange consistency. Calling setName should set the QName.
> indeed, there should be no storage slot for the plain 'name'.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
