Francesco,
please see inline.
Regards
Werner
Francesco Vivoli wrote:
Ciao Werner:)
thanks for your reply.
I've tried some combinations but I have some trouble understanding
how this is supposed to work.
The first thing is, I've written a binding file like this:
<elementBinding name="/Benchmark">
<attributeBinding name="Id">
<member name="id2"/>
</attributeBinding>
</elementBinding>
A binding such as follows should be sufficient:
<elementBinding name="/Benchmark/@Id">
<member name="id2" />
</elementBinding>
Equally, ...
<attributeBinding name="/Benchmark/Id">
<member name="id2" />
</attributeBinding>
should achieve the same. If you provided me with a minimal XML schema
(fragment), I could test this myself.
but, I don't know whether it works or not because I haven't found a way of
telling
the maven plugin to use it...
I've tried using a <binding/> or <bindingFile/> into the <configuration/>
section
of the plugin but I still get the same error of my first post.
According to
http://mojo.codehaus.org/castor-maven-plugin/generate-mojo.html
the element to be used to point to source generator to a binding file
from the maven plugin for Castor should be
<bindingfile>....</bindingfile>
I've tried looking at the test suite, but there is no attributeElement
example so I couldn't
verify my binding file. As for the maven plugin, could you maybe give me
some hint?
thansk a lot
Francesco
Werner Guttmann wrote:
Ciao Francesco,
as per default naming conventions applied during XML code generation,
Castor will create the following Java members for both of the attribute
definitions:
private String _id;
Please note that this is top of my head, as I will have to verity this
later on (where it is the String return type where I might be wrong).
As such, one attribute would clearly overwrite the other one, and as
such produce incorrect code. IN order to avoid this, an error message is
emitted, signalling this abnormality to you.
Having said that, you should be able to resolve this naming collision by
using a binding file, and specifying that e.g. the Java member generated
for the second attribute definition should be named 'secondId'. Have you
tried that already ?
Regards
Werner
Francesco Vivoli wrote:
Follow up, sorry for the duplication.
In fact the schema has these two definitions:
<xsd:attribute name="id" type="xsd:NCName" use="optional"/>
<!-- the 'Id' attribute is needed for XML-Signature -->
<xsd:attribute name="Id" type="xsd:ID" use="optional"/>
for the same complex type...
Is there a way I could override the default behavior and have a valid
mapping?
F
Francesco Vivoli wrote:
Hi
I've been trying to use Castor to generate java bindings for this
schema:
http://nvd.nist.gov/scap/xccdf/docs/xccdf-1.0.xsd.txt
The problem is, I get the following output:
Embedded error: An Exception occurred processing
/Users/villo/Documents/projects/atalaya/trunk/atalaya-web/src/main/xsd/xccdf-1.0.xsd
duplicate name found: _id
In fact the schema has these two definitions:
<xsd:attribute name="id" type="xsd:NCName" use="optional"/>
<!-- the 'Id' attribute is needed for XML-Signature -->
<xsd:attribute name="Id" type="xsd:ID" use="optional"/>
for the same complex type...
I'm using Castor-1.1.M3 with the maven plugin with these properties (I
used the last two in the hope to solve the problem but I admit I don't
know their effect too much)
org.exolab.castor.builder.javaVersion=5.0
org.exolab.castor.builder.automaticConflictResolution=true
I have read http://www.mattpayne.org/blog/category/programming/xml/
here
that people have been using xmlbeans to generate java bindings for this
schema, but I'd like to use Castor, as I have just to make data
binding...
Is there a way I could override the default behavior and have a valid
mapping?
thanks a lot
F
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
