Thanks for looking at the matter and thanks for the workaround; we will give it a try.
Here are some information on the Sync4j project. Sync4j has born in middle 2001 by Sean Sullivan. It was originally meant as a library implementing the SyncML representation protocol (http://www.openmobilealliance.org/syncml). After a while I and my company took over Sean in the management and development of the project, transforming it in a fully featured SyncML platform, with a real server and client APIs.
Recently I determined that having a parser to translate XML into Java objects makes little sense, since I am convinced that if you know the structure of the XML, there is no reason to every time reinvent the wheel: just use a tool that creates a dedicated parser for you. This also brings the advantage of separating the representation of the message in term of objects from the representation of the message in term of XML.
For this reason I came across JiBX. As already said on this list, I am very impressed by JiBX, particularly in comparison with the standard Java for Java-XML binding.
The way we use it is the following: when a SyncML message comes to the server, we unmarshal it in a tree of objects representing the message itself (we have basically an object for any element). Then the server creates a response message in terms of Java objects; this is marshalled before sending it to the client.
Here are the key aspects I like most:
1) Code enhancing -> performance and easy to use 2) Do not impose too many restriction on the objects you want to map 3) Easy of use in general 4) Quite flexible
However, we found some flaws. Actually, they are not strictly related to XML and JiBX, since JiBX works well with messages that perfectly follow the XML specs. But since clients may be out of our control, they can send us pretty bad XML and we have to be flexible on supporting them. Plus, SyncML messages are mandated to be well-formed XML messages, but not necessarily valid. Therefore, along with enforcing the standards when possible, we would really need the flexibility to relax basically any constraint.
This is the case of namespaces and ordering. We have solved the problem of namespaces hacking the code as suggested on the list (it would be nice if it was a configurable option): on unmarshalling we ignore them, on marshalling we insert them as the standard dictates.
The ordering issue is still open and we look forward to your new release. Would you need more imput/feedback from us, do not hesitate to contact us.
I hope that this application of JiBX is of your interest too, as SyncML is getting everyday more popular.
All the best, Stefano
Dennis Sosnoski wrote:
I am restructuring the code generation for beta 4, and in the process I'm trying to loosen up the restrictions on using unordered lists of elements. This is really going against the grain of JiBX, though, and I'm not sure how far I'll be able to push it.
For the specific case we're discussing here, where there's a collection with no wrapper element (in other words, the elements representing items from the collection can appear anywhere in the list of children) as part of the unordered list I can offer one solution that should work fine for unmarshalling with the existing code. That is to include the child elements representing items from the collection directly in the unordered list, and use a set-method that actually adds the item to the internal collection - so rather than exposing the collection directly to JiBX just expose the items and let the collection operate behind the scenes. That's not going to work for marshalling, though. If you need to marshal the objects back out you'd need to define a separate binding for that purpose. This works fine with JiBX, but means you'd need to maintain the two bindings (one input only and unordered as much as possible, one output only and use the appropriate order).
Aside from that, I don't know how this is being used with the Sync4J project and what the implications are for everything. If you want to explain that in more detail I'd love to know what's going on.
- Dennis
Stefano Fornari wrote:
Hi dennis,
I tell you a nice story: in Milan, theare are traffic lights like in any other town in the world. People stop when it is red, and go on when it is green. In Naples, there are traffic lights like in any other town in the world. People should stop when it is red.... but usually they go on, because the red light is just an "advice".... :))
That is a paradox (and not completely true :-) ), but it is exactly what happens with XML: somebody follows it strictly, somebody not... And try to tell Nokia they are sending a wrong XML! :-)
In short, the plain question is: would you be interested in having GiBX more flexible? We can have a look at the code and see if it is fixable. If it is, would you include the fix in the base code?
Thanks in advance.
Stefano
Dennis Sosnoski wrote:
You may just be trying to go beyond the limits of the unordered support in the current JiBX code. Looking at your binding I see that you've got collections with no associated element name included in the unordered lists. I'm not sure what would happen with this, but I wouldn't be suprised if this is broken. JiBX is designed primarily for ordered lists of elements, and trying to push the unordered support probably won't work well at present.
From a quick look at the SyncML DTDs, though, I don't think you really need to be doing unordered lists at all - the child elements appear to be ordered, meaning you can use that order in your bindings. I'd suggest you try changing to an ordered approach - you should find this is much easier to work with and less confusing when something goes wrong.
- Dennis
Xin Liu wrote:
Hi:
Thank you for your kind reply. I changed the binding.xml file as you told me, however, problem remains.
It seems that the problem is not caused by SourceRef. Even if I delete the SourceRef from the DataStore, programme will tell me : org.jibx.runtime.JiBXException: Expected end tag, found start tag "{syncml:devinf}DisplayName".
Below I will paste the xml file and the binding.xml to make things clear:
xml file:
.........................................................
<DevInf xmlns='syncml:devinf'>
<VerDTD>1.1</VerDTD>
<Man>Big Factory, Ltd.</Man>
<Mod>4119</Mod>
<OEM>Jane's phones</OEM>
<FwV>2.0e</FwV>
<SwV>2.0</SwV>
<HwV>1.22I</HwV>
<DevID>1218182THD000001-2</DevID>
<DevTyp>phone</DevTyp>
<DataStore>
<SourceRef>./contacts</SourceRef>
<DisplayName>Phonebook</DisplayName>
<MaxGUIDSize>32</MaxGUIDSize>
<Rx-Pref>
<CTType>text/x-vcard </CTType>
<VerCT>2.1</VerCT>
</Rx-Pref>
<Tx-Pref>
<CTType>text/x-vcard</CTType>
<VerCT>2.1</VerCT>
</Tx-Pref>
</DataStore>
<CTCap>
<CTType>text/x-vcard</CTType>
<PropName>BEGIN</PropName>
<ValEnum>VCARD</ValEnum>
<PropName>END</PropName>
<ValEnum>VCARD</ValEnum>
<PropName>VERSION</PropName>
<ValEnum>2.1</ValEnum>
<PropName>N</PropName>
<PropName>TEL</PropName>
<ParamName>VOICE</ParamName>
<ParamName>CELL</ParamName>
</CTCap>
<SyncCap>
<SyncType>01</SyncType>
<SyncType>02</SyncType>
</SyncCap>
</DevInf>
.............................................................
The binding.xml file:
.............................................................
<mapping name="DevInf" field="devInf" class="com.syncml.framework.core.DevInf" ordered="false">
<namespace uri="syncml:devinf" default="elements"/>
<structure field="verDTD" class="com.syncml.framework.core.VerDTD" usage="optional">
<value name="VerDTD" field="value" usage="optional"/>
</structure>
<value name="Man" field="man" usage="optional"/>
<value name="Mod" field="mod" usage="optional"/>
<value name="OEM" field="oem" usage="optional"/>
<value name="FwV" field="fwV" usage="optional"/>
<value name="SwV" field="swV" usage="optional"/>
<value name="HwV" field="hwV" usage="optional"/>
<value name="DevID" field="devID" usage="optional"/>
<value name="DevTyp" field="devTyp" usage="optional"/>
<value name="UTC" field="utc" format="formatBoolean" usage="optional"/>
<value name="SupportLargeObjs" field="supportLargeObjs" format="formatBoolean" usage="optional"/>
<value name="SupportNumberOfChanges" field="supportNumberOfChanges" format="formatBoolean" usage="optional"/>
<collection field="datastores" item-type="com.syncml.framework.core.DataStore" usage="optional"/>
<collection field="ctCap" item-type="com.syncml.framework.core.CTCap" usage="optional"/>
<collection field="ext" item-type="com.syncml.framework.core.Ext" usage="optional"/>
</mapping>
..........................................................................
<mapping name="DataStore" field="datastores" class="com.syncml.framework.core.DataStore" ordered="false">
<structure field="sourceRef" class="com.syncml.framework.core.SourceRef" usage="optional">
<value name="SourceRef" field="value" usage="optional"/>
</structure>
<value name="DisplayName" field="displayName" usage="optional"/>
<value name="MaxGUIDSize" field="maxGUIDSize" usage="optional"/>
<structure name="Rx-Pref" field="rxPref" class="com.syncml.framework.core.ContentTypeInfo">
<value name="CTType" field="ctType"/>
<value name="VerCT" field="verCT" />
</structure>
<collection field="rx" usage="optional">
<structure name="Rx" value-style="element" type="com.syncml.framework.core.ContentTypeInfo" usage="optional">
<value name="CTType" field="ctType"/>
<value name="VerCT" field="verCT" />
</structure>
</collection>
<structure name="Tx-Pref" field="txPref" class="com.syncml.framework.core.ContentTypeInfo" usage="optional">
<value name="CTType" field="ctType"/>
<value name="VerCT" field="verCT" />
</structure>
<collection field="tx" usage="optional">
<structure name="Tx" value-style="element" type="com.syncml.framework.core.ContentTypeInfo">
<value name="CTType" field="ctType"/>
<value name="VerCT" field="verCT" />
</structure>
</collection>
<structure name="DSMem" field="dsMem" class="com.syncml.framework.core.DSMem" usage="optional">
<value name="SharedMem" field="sharedMem" format="formatBoolean" usage="optional"/>
<value name="MaxMem" field="maxMem" usage="optional"/>
<value name="MaxID" field="maxID" usage="optional"/>
</structure>
<structure name="SyncCap" field="syncCap" class="com.syncml.framework.core.SyncCap" usage="optional">
<collection field="syncTypes" item-type="com.syncml.framework.core.SyncType"/>
</structure>
</mapping>
......................................................................................
If, in the xml file, I cut alll the DataStore out, errors would go to the CTType, the same error, asking for end tag, found start tag. When I cut the xml file to :
<DevInf xmlns='syncml:devinf'>
<VerDTD>1.1</VerDTD>
<Man>Big Factory, Ltd.</Man>
<Mod>4119</Mod>
<OEM>Jane's phones</OEM>
<FwV>2.0e</FwV>
<SwV>2.0</SwV>
<HwV>1.22I</HwV>
<DevID>1218182THD000001-2</DevID>
<DevTyp>phone</DevTyp>
</DevInf>
The problem can go.
So I guess the problem lies in the binding.xml of:
<collection field="datastores" item-type="com.syncml.framework.core.DataStore" usage="optional"/>
<collection field="ctCap" item-type="com.syncml.framework.core.CTCap" usage="optional"/>
<collection field="ext" item-type="com.syncml.framework.core.Ext" usage="optional"/>
It seems that the collections caused the problem. So What changes can I make? And how the problem is arised?
I am almost mad at this, please help me!! Best regards. Liu Xin
_________________________________________________________________
The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail
------------------------------------------------------- This SF.Net email is sponsored by the new InstallShield X.
From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 _______________________________________________ jibx-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jibx-users
------------------------------------------------------- This SF.Net email is sponsored by the new InstallShield X.
From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 _______________________________________________ jibx-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jibx-users
------------------------------------------------------- This SF.Net email is sponsored by the new InstallShield X.
From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 _______________________________________________ jibx-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jibx-users
