|
| Re: suggestion to use namespace prefix for nsPrefix in XSD2eCore mapping [message #69372 is a reply to message #69348] |
Sun, 20 August 2006 14:33   |
Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Matthew,
I had considered this at the time XSDEcoreBuilder was first created but
I decided against for a couple of reasons. One is that a schema can
consist of multiple <include>d documents and each could use a different
prefix for the target namespace. Since the EPackage is demand created
as a side-effect of asking a component for its package
(XSDEcoreBuilder.getEPackage), the containing schema of the first
component that's visited would be used to determine the nsPrefix value,
and should the schemas change over time, that first component
(alphabetically first) could change resulting in a different result,
i.e., I'm concerned about the stability of the result in general. The
second reason is that it's also fairly common to use the default/null
prefix for the target namespace, which leaves us a very poor choice.
The obstacle to change now is that changing the behavior will run the
risk of upsetting existing clients with a change in behavior that would
require them to add an nsPrefix annotation or change the xmlns:xyz
declaration's xyz value.
What I've thought about doing is providing an extension point by which
it's possible to register a name mangling algorithm that would be used
by XSDEcoreBuilder to produce its results. This could take the form of
an extensible drop down combo box of name mangling styles in the
importer which any client could extend to better meet their needs. Feel
free to open a bugzilla feature request for that.
Matthew Rawlings wrote:
> This is a suggestion to map the namespace prefix in the XML Schema to the
> nsPrefix in eCore.
>
> Section 1.2, "Schema with Target Namespace", of the document
> "XMLSchemaToEcoreMapping"
> http://www.eclipse.org/emf/docs/overviews/XMLSchemaToEcoreMa pping.pdf states
> that the nsPrefix is derived from the targetNamespace. I suggest that the
> nsPrefix is instead derived from the XML Schema namespace prefix instead
> whenever it is present. This is a proposed to change to this specification.
>
> Using this example:
> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
> xmlns:fpml="http://www.fpml.org/2005/FpML-4-2"
> targetNamespace=http://www.fpml.org/2005/FpML-4-2>
>
> Today this correctly creates from the targetNamespace a nsPrefix of: "_2"
> according to the algorithm.
>
> In cases where the namespace has a defined prefix in the schema the
> algorithm is redundant because the namespace name is already defined. For
> the above example it can be seen that the namespace prefix defined in the
> schema is "fpml". The use of "fpml" in the eCore is consistent with the XSD,
> much more so than "_2".
>
> Today I achieve this workaround with schema annotations. I believe that the
> specification should be emended to make use of predefined prefixes where
> they exist.
>
> - Matthew
>
>
>
|
|
|
|
| Re: suggestion to use namespace prefix for nsPrefix in XSD2eCore mapping [message #598596 is a reply to message #69348] |
Sun, 20 August 2006 14:33 |
 Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
Matthew,
I had considered this at the time XSDEcoreBuilder was first created but
I decided against for a couple of reasons. One is that a schema can
consist of multiple <include>d documents and each could use a different
prefix for the target namespace. Since the EPackage is demand created
as a side-effect of asking a component for its package
(XSDEcoreBuilder.getEPackage), the containing schema of the first
component that's visited would be used to determine the nsPrefix value,
and should the schemas change over time, that first component
(alphabetically first) could change resulting in a different result,
i.e., I'm concerned about the stability of the result in general. The
second reason is that it's also fairly common to use the default/null
prefix for the target namespace, which leaves us a very poor choice.
The obstacle to change now is that changing the behavior will run the
risk of upsetting existing clients with a change in behavior that would
require them to add an nsPrefix annotation or change the xmlns:xyz
declaration's xyz value.
What I've thought about doing is providing an extension point by which
it's possible to register a name mangling algorithm that would be used
by XSDEcoreBuilder to produce its results. This could take the form of
an extensible drop down combo box of name mangling styles in the
importer which any client could extend to better meet their needs. Feel
free to open a bugzilla feature request for that.
Matthew Rawlings wrote:
> This is a suggestion to map the namespace prefix in the XML Schema to the
> nsPrefix in eCore.
>
> Section 1.2, "Schema with Target Namespace", of the document
> "XMLSchemaToEcoreMapping"
> http://www.eclipse.org/emf/docs/overviews/XMLSchemaToEcoreMa pping.pdf states
> that the nsPrefix is derived from the targetNamespace. I suggest that the
> nsPrefix is instead derived from the XML Schema namespace prefix instead
> whenever it is present. This is a proposed to change to this specification.
>
> Using this example:
> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
> xmlns:fpml="http://www.fpml.org/2005/FpML-4-2"
> targetNamespace=http://www.fpml.org/2005/FpML-4-2>
>
> Today this correctly creates from the targetNamespace a nsPrefix of: "_2"
> according to the algorithm.
>
> In cases where the namespace has a defined prefix in the schema the
> algorithm is redundant because the namespace name is already defined. For
> the above example it can be seen that the namespace prefix defined in the
> schema is "fpml". The use of "fpml" in the eCore is consistent with the XSD,
> much more so than "_2".
>
> Today I achieve this workaround with schema annotations. I believe that the
> specification should be emended to make use of predefined prefixes where
> they exist.
>
> - Matthew
>
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
|
Powered by
FUDForum. Page generated in 0.02378 seconds
] 
Search
Help
Register
Login
Home
