[
https://issues.apache.org/jira/browse/WSCOMMONS-360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12612473#action_12612473
]
Rich Scheuerle commented on WSCOMMONS-360:
------------------------------------------
Takahide,
The implementation will be different from what you proposed above.
An OMNamespace object contains both the uri and the prefix. Thus if
constructors (1), (3), (4), (5) are used then no expansion is necessary when
"OMNamespace getOMNamespace()" is invoked.
Constructor (2) uses a QName. A QName stores the local name, namespace uri and
optionally the prefix. If the prefix is "", then the OM will be expanded when
the prefix is needed.
I am working on a solution now.
> Prefix mismatch of OMSourcedElement
> ------------------------------------
>
> Key: WSCOMMONS-360
> URL: https://issues.apache.org/jira/browse/WSCOMMONS-360
> Project: WS-Commons
> Issue Type: Improvement
> Components: AXIOM
> Reporter: Davanum Srinivas
> Assignee: Rich Scheuerle
> Priority: Critical
>
> Discussion here - http://markmail.org/message/ks7taa4upual3ufj
> ============== Text from initial email ==================
> Hi folks,
> I am facing prefix mismatch problem of OMSourcedElement. If we get a
> prefix from non-expanded OMSE by using OMSE.getNamespace().getPrefix(),
> the returned prefix is "". But if we get the prefix from expanded OMSE,
> then the returned prefix is "ns1". The first default OMNamespace is set by
> OMSE creater (can be outside of axiom and axis2) through constructor
> argument, The second OMNamespace is created from OMDatasource when it is
> expanded. Since these two OMNamespace are created by different ways, the
> prefixes can be mismatch.
> OMSourcedElement should return the same data regardless of whether it is
> expanded or not. I think the OMNamespace should not be provided by
> Constructor, but should be provided by OMDataSource to avoid such prefix
> mismatch, otherwise we have to expand OMSourcedElement when getNamespace()
> is invoked. I am not sure there are other ways to avoid this problem...
> ============== Text from initial email ==================
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
