Greg-

Jitesh said "Actually I do not wish to prefix my elements as this file is manually updated by user.", so in (admittedly screwy) mapping, I was attempting to accommodate that wish. So now on to the other topics raised...

First, I found you do have to define your namespaces in the mapping file if you have namespaces support and validation turned on. If you don't, one of two things will happen: one, the class descriptors will get created with the castor namespace, and thus not match when unmarshalling (there is a check after getting an element level match that checks the namespaces, and if they don't match, ignore that descriptor), or two, the validator will complain about the <bind-xml> name attribute not being a QName.

Second, this is probably a semantic argument, but in this situation (now this is my opinion, I don't know how it applies to Jitesh's real needs) I don't think the use of noNamespaceSchemaLocation is the best way to go. The elements used in the xml belong to a namespace, but they all belong to the same namespace, so just make it the default one and run with it (I don't remember, but I think the XML spec defines specifically what the noNamespace namespace is). Really, if this were my project, I would probably slap prefixes on everything and call it good, but I understand Jitesh's desire to simplify user editing of the file. OH! And looking back through comments I now remember, the reason I had to be screwy with the mapping file namespaces is to get the mapped attributes into the right namespace. Otherwise when marshalling, Castor would put the elements in the correct namespace, but put the attributes back in the castor namespace... It was weird... There's probably a better way to do that.

I thought there was more to comment on there, but I can't really find anything... I have to admit, it has been a LONG time since I've really written schemas, so I'm very rusty, and some of the oddities I experienced might come from badly written schemas (so instead of changing the schema -- since XMLBuddy seemed to like it -- I attacked the error message Castor gave me, and that lead to a slightly different mapping).

*shrug* Sorry for all the confusion, it may just be my ignorance more than anything. Hope a little discussion can clear everything up.

Thanks,
Stephen




Gregory Block wrote:
I don't get this personally...


<?xml version="1.0" encoding="UTF-8"?>
<wow-feeds:article
    xmlns:wow-type="http://xml.whatsonwhen.com/schemas/1.0/wow- types.xsd"
    xmlns:wow-feeds="http://xml.whatsonwhen.com/schemas/1.0/wow- feeds.xsd"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://xml.whatsonwhen.com/schemas/1.0/wow- feeds.xsd http://xml.whatsonwhen.com/schemas/1.0/wow-feeds.xsd";
    id="136677" ongoing="false">
    <wow-type:article-date tbc="false">
<wow-type:start-date>2005-07-29T11:28:55.313+01:00</wow- type:start-date> <wow-type:end-date>2008-07-29T11:28:55.313+01:00</wow- type:end-date>
    </wow-type:article-date>
    <wow-type:title>Club Shelter</wow-type:title>
<wow-type:description>&lt;p&gt;House-heads flock to this old- school disco. The big draw is the "Saturday Night Shelter Party," when late '80s house music takes over. The crowd is racially and sexually diverse and dress is not fancy; wear whatever is comfortable for doing some heavy sweating on the dance floor. At press time, live acts such as Patti LaBelle were set to be added. &lt;/p&gt; &lt;p&gt;Transportation: Subway: B, D, F, Q, V, 7 to 42nd St&lt;/ p&gt;</wow-type:description>
[...]


But I've got the main node namespaced, and declare the two namespaces it belongs to with it.

  <?xml version="1.0" encoding="UTF-8"?>
  <tmsettings xmlns="http://www.ne.jp/method";
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
    xsi:schemaLocation="http://www.ne.jp/method method_settings.xsd">
    <logging>
      <logger xmlns:ns1="http://www.ne.jp/method";
        ns1:name="tmcompiler" ns1:boundrylevel="10"/>
      <logger xmlns:ns2="http://www.ne.jp/method"; ns2:name="tmwebapp"
        ns2:boundrylevel="10"/>
      <logger xmlns:ns3="http://www.ne.jp/method"; ns3:name="tmclient"
        ns3:boundrylevel="10"/>
      </logging>
  </tmsettings>


Question, from memory: If you want a document-level namespace, shouldn't you be using setNoNamespaceSchemaLocation()?

Also...

And finally, just in case, here's the mapping file:

  <ca:mapping xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
    xmlns:ca="http://castor.exolab.org/";
    xmlns="http://www.ne.jp/method";
    xsi:schemaLocation="http://castor.exolab.org/ mapping.xsd">
    <ca:class name="TMSettings">
      <ca:map-to xml="tmsettings" ns-uri="http://www.ne.jp/method"/>
      <ca:field name="loggerList" collection="map"
        get-method="getLoggerList" set-method="addLogger"
        type="castor.kalyani.two.TMLogger">
        <ca:bind-xml name="logger" location="logging"/>
      </ca:field>
    </ca:class>

    <ca:class name="TMLogger">
      <ca:field name="name" type="string">
        <ca:bind-xml name="name" node="attribute"/>
      </ca:field>
      <ca:field name="boundryLevel" type="string">
        <ca:bind-xml name="boundrylevel" node="attribute"/>
      </ca:field>
    </ca:class>
  </ca:mapping>


Personally, I tend to have mappings that look more like...

<mapping
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://xml.whatsonwhen.com/schemas/1.0/ wow-feeds.xsd http://xml.whatsonwhen.com/schemas/1.0/wow-feeds.xsd"; xmlns:wow-feeds="http://xml.whatsonwhen.com/schemas/1.0/wow- feeds.xsd" xmlns:wow-type="http://xml.whatsonwhen.com/schemas/1.0/wow- types.xsd"> <class name="com.wow.webapp.pageComponents.xml.XmlLocationWriter $XMLLocation" access="read-only">
                <map-to xml="wow-feeds:location" />
                <field name="location.ID" type="integer">
<bind-xml name="id" node="attribute" type="wow-type:location-id-type"/>
                </field>
                <field name="location.displayLevel" type="string">
<bind-xml name="level" node="attribute" type="wow-type:location-level-type"/>
                </field>
[...]

Note that I'm setting the type to the namespaced version of what I want to appear; I don't think that declaring the namespaces in the mapping is necessary - I do so mostly for the purposes of documenting intent.

Anyways, with the above, I get exactly what I expect: A top-level node with the bits I expected to have set, etc.

I can go back and dig out the calls that are used to generate that, but as I've said before, it's all framework stuff on our side - we define feeds as a runtime config on a particular mapping item with a set of associated attributes that looks something like...

<config name="xml.mapper" value="@[EMAIL PROTECTED]"/>
    <config name="xml.cache" value="false"/>
    <config name="xml.validate" value="false"/>
    <config name="xml.namespaces">
<config name="wow-type" value="http://xml.whatsonwhen.com/ schemas/1.0/wow
-types.xsd"/>
<config name="wow-feeds" value="http://xml.whatsonwhen.com/ schemas/1.0/wo
w-feeds.xsd"/>
    </config>
    <config name="xml.extendedtypes" value="false"/>
    <config name="xml.rootelement" value="wow-feeds:highlights"/>
<config name="xml.schemalocation" value="http:// xml.whatsonwhen.com/schemas/1.0/w
ow-feeds.xsd http://xml.whatsonwhen.com/schemas/1.0/wow-feeds.xsd"/>
    <config name="xml.charset" value="UTF-8"/>
    <config name="xml.document" value="true"/>

Now, ignore the hideous XML format for config - that's historical. This particular feed uses that mapper, with caching and validation disabled (caching is an outside-of-castor thing here; it caches the resulting XML from the operation and stores it in memcached.), disables extended types, sets the root element to wow- feeds:highlights, marks the schema location, sets a charset, and tells it to marshal a document header into the results.

So to generate my feed, it looks like I'm just setting a schema location as above, including both namespaces in the calls, and running the mapping through it.

It does work here - your mileage may of course vary.


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