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><p>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. </p>
<p>Transportation: Subway: B, D, F, Q, V, 7 to 42nd St</
p></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]
-------------------------------------------------