Mesut and Keith-

I've been trying to wrap my brain around this problem during your discussion, and while it may or may not be helpful, I'd like to explain my take on the standard. How I read the document is that all globally defined elements, attributes, attribute sets, and types are added to the schema's target namespace (I don't think there is any disagreement there). Local definitions on the other hand are controlled by the form attribute (qualified/unqualified). In the unqualified case, all local elements, attributes, types, etc. are added to the null namespace (I believe this is equivalent to the "" namespace?). In the qualified case, all local elements etc. are added to the target namespace. Quick experimentation with some validating parsers implies this interpretation matches the interpretation of the parser implementors.

To get back to the more specific case being discussed, Keith is right, whether an element has a namespace prefix or not makes little difference, it is the actual namespace it is associated with that matters. So in this case, since the locally defined elements are supposed to be in the null namespace (and a quick check of the XML Namespace standard states one cannot define a prefix for the null namespace), I think the correct solution is to define a namespace prefix for the target namespace, qualify all the globally defined elements, and not qualify the locally defined elements. That should result in the correct allocation of elements to namespaces.

Now let me step back and say I have NO idea how easy or hard that solution is in Castor :) I hope my $0.02 adds something to the discussion.

Thanks!
Stephen


Mesut Celik wrote:
hi Keith,
please have a look at this example.
http://www.w3.org/TR/xmlschema-0/#po2.xml
that's a qualified message. Every element implicitly belongs to
default namespace.
what i did not understand is the namespaces of local elements.

say you add a top level element "name"  to qualified po2.xsd and also
you have a subelement "name" in both "shipTo" and "billTo". can you
tell me your opinion on which "name" element belongs to which
namespace. what resolves this conflict?
I think the top level "name" will be in default namespace but what
about the subelement?

I think the answer for the question above gonna make me clear on this
subject because apparently my namespace understanding causes the
confusion.

thanks in advance
mesut


On 9/28/05, Keith Visco <[EMAIL PROTECTED]> wrote:

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]
-------------------------------------------------




-------------------------------------------------
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]
-------------------------------------------------

Reply via email to