My comments inline...
Mesut Celik wrote:
Hi Keith,
answers below...
On 9/27/05, Keith Visco <[EMAIL PROTECTED]> wrote:
As far as I understand it, qualified and unqualified indicate which
namespace an element belongs to, not whether or not it should have a
prefix.
that's not completely correct. "Qualified" means every subelement must
have a namespace prefix. "Unqualified" means no subelement is allowed
to have a namespace prefix which relatively indicates that subelement
belongs to the namespace of its parent.
I disagree. And I have read the link you provided below. When you
qualify and element, you are specifying which target namespace the
element belongs in. A namespace prefix by itself is essentially
meaningless. It's what the prefix maps to that matters.
So you can have an unprefixed element which is still qualified
with the default namespace declaration.
if you have an unprefixed local element, not parent, this says your
xml is unqualified.
You can also have a prefixed
element which is unqualified by having a prefix which maps to an empty
namespace.
each subelement which is prefixed by a namespace refers to an qualified message.
here the critical part is we only focus on subelements so that we make
a conclusion if an xml is qualified.
Again, it's my understanding that qualification refers to what target
namespace the element (or attribute) belongs and I've re-read the schema
spec and I don't see anything in there to the contrary. I could be
wrong, but I don't see any clear cut data in the recommendation that
indicates that.
please look at this document from w3c.org to get familiar with this issues.
http://www.w3.org/TR/xmlschema-0/#NS
I have and it doesn't change my view on the subject. The following is a
qualified element in my opinion:
<foo xmlns="http://foo.org/namespace">
</foo>
what amazes me is that no one else was concerned about this issue before.
before sending the complete case I just wanna learn how castor handles
this qualification/unqualification issue.
It should handle it as specified in XML Schema 1.0 Recommendation. If it
doesn't then it's a bug and should be reported in the Castor JIRA.
--Keith
In any case, it sounds like there may be a bug here. Can you provide a
small, but complete example which I could look at further.
Thanks,
--Keith
Mesut Celik wrote:
Thats the root element:
<xs:schema xmlns:xs=http://www.w3.org/2001/XMLSchema
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/
xmlns:soapenc=http://schemas.xmlsoap.org/soap/encoding/
xmlns:tns="urn:dslforum-org:cwmp-1-0"
xmlns:cwmp="urn:dslforum-org:cwmp-1-0"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
targetNamespace="urn:dslforum-org:cwmp-1-0"
elementFormDefault="unqualified"
attributeFormDefault="unqualified">
That's my element definition:
<xs:element name="Inform">
<xs:complexType>
<xs:sequence>
<xs:element name="Event" type="tns:Event"/>
</xs:sequence>
</xs:complexType>
</xs:element>
thats a complextype for the Event:
<xs:complexType name="Event">
<xs:sequence>
<xs:element name="EventStruct" type="tns:EventStruct" minOccurs="1"
maxOccurs="16"/>
</xs:sequence>
<xs:attribute ref="soapenc:arrayType" /> //This part added
</xs:complexType>
Normally I would expect that serialized form of Inform Element is
unqualified which means that all the subelements of Inform element
must not have namespace prefix. however castor puts this namespace
prefix always in front of the for example Event element.
<cwmp:Inform >
<cwmp:Event soap:arrayType="EventStruct[2]">
<cwmp:EventStruct>
<EventCode>4 VALUE CHANGE</EventCode>
<CommandKey></CommandKey>
</cwmp:EventStruct>
</cwmp:Event>
</cwmp:Inform>
Maybe the reason is Event has a global complex type definition which
conflicts with Event element definition inside the Inform complex-type
definition.
I hope everything is clear. I can give more information in case of confusion...
On 9/26/05, Werner Guttmann <[EMAIL PROTECTED]> wrote:
Mesut,
can you please include the relevant parts of the XML Schema instance you
are using, i.e. at least the root element ?
Thanks
Werner
________________________________
From: Mesut Celik [mailto:[EMAIL PROTECTED]
Sent: Monday, September 26, 2005 4:39 PM
To: [email protected]
Subject: [castor-user] Re: elementFormDefault is not working in
unqualified mode
please respond your opinions.
any idea would be appreciated.
regards,
mesut
On 9/16/05, Mesut Celik <[EMAIL PROTECTED]> wrote:
Hi all,
I have a xml schema in which i defined
"elementFormDefault" as "unqualified". I use this schema to generate
java object model which we use in our protocol layer.
however, I saw that after marshalling operation, castor
qualifies all the local elements although elementFormDefault is
unqualified.
what can be the cause of the problem? Im using a binding
file but I didnt see anything accidently change the default behaviour.
any help appreciated!...
mesut
-------------------------------------------------
If you wish to unsubscribe from this list, please
send an empty message to the following address:
[EMAIL PROTECTED]
-------------------------------------------------
-------------------------------------------------
If you wish to unsubscribe from this list, please
send an empty message to the following address:
[EMAIL PROTECTED]
-------------------------------------------------
-------------------------------------------------
If you wish to unsubscribe from this list, please
send an empty message to the following address:
[EMAIL PROTECTED]
-------------------------------------------------
-------------------------------------------------
If you wish to unsubscribe from this list, please
send an empty message to the following address:
[EMAIL PROTECTED]
-------------------------------------------------
-------------------------------------------------
If you wish to unsubscribe from this list, please
send an empty message to the following address:
[EMAIL PROTECTED]
-------------------------------------------------