Re: how to parse XML documents?

be careful of datatype conversion
sometimes its easier to convert all data to string datatype and once inside 
the receiving node depending on name of field
e.g. DateFieldForForm
THEN convert to the language specific datatype date, int, long, double, 
currency, date, time etc..
Anyone else ???
Martin
----- Original Message ----- 
From: "John D. Blair" <[email protected]>
To: <[email protected]>
Sent: Saturday, August 27, 2005 4:03 PM
Subject: Re: [JXTA user] how to parse XML documents?


> That makes a lot of sense.  I have one concern:
>
> The system I am writing in Java is very much a proof-of-concept.  I expect 
> that I will have to write a version (that will have less functionality, 
> but also a much smaller footprint) in C, using JXTA-C, to meet some future 
> hardware requirements.  See, some peers are "edge peers" and won't be 
> doing much local processing, while other peers will be quite sophisticated 
> and will remain implemented in Java.
>
> So, my question is: will my data be able to interoperate between the C 
> JXTA implementation and the Java JXTA implementation if I use the 
> technique you suggest?
>
> thanks!
>  -john.
>
> On Aug 27, 2005, at 12:56 PM, Sayed Hashimi wrote:
>
>> Hi,
>> What I would suggest doing is this:
>> Write a class that encapsulates all the data/methods that you need.
>> Make sure that all sender/receivers have this class, and also make
>> sure that it is serializable. Then when its time to create a message,
>> all you need to do is to add and element to the Jxta message, and
>> inside of that serialize that object to a byte array. On the receiver
>> side you'll need to reconstruct that object from the byte array. This
>> has many advantages over the XML technique you described. Because it
>> is easier to implement and you send much less data over the wire. And
>> the LiteXMLDocument is in the impl package so its could change, you
>> don't want to write your code against something tha can change like
>> that. You should try to avoid anywayz :)
>> Even though the Jxta uses XML messages, you should avoid doing so, you
>> simply send too much data over the wire. If you'd like to save these
>> documents to an XML file then all you have to do is create a method
>> that will handle writing to a file and initalizing from file (or
>> stream). To do that I would suggest using either JAXB
>> (http://java.sun.com/xml/jaxb/) if you have an XSD that will not
>> change and the XML file is complicated. If the file is likely to
>> change and pretty simple I'd suggest you to use Digester
>> (http://jakarta.apache.org/commons/digester/).
>>
>> Hope that helps,
>> Sayed
>>
>> On 8/27/05, John D. Blair <[email protected]> wrote:
>>> I have been experimenting with JXTA and, while the learning curve has
>>> been steep, I am quite impressed.
>>>
>>> However, I am having trouble working with XML documents.  I have
>>> created a document structure using the LiteXMLDocument which represents
>>> the data I want my peers to communicate with each other.  However, I
>>> cannot figure out how to parse these documents back into into
>>> LiteXMLDocuments.  I have been poring over the documentation, and as
>>> far as I can tell, there is no facility for doing this.
>>>
>>> I have explored using the javax.xml.parsers object which comes in the
>>> Java library, but there still seems no way to get an XML document back
>>> into a LiteXMLDocument.
>>>
>>> So, to be clear, my question is:
>>> Is there an existing way to parse an XML document and use it to
>>> populate a LiteXMLDocument (or a DOMXMLDocument)?
>>>
>>> Am I missing something obvious?  Or is this by design?
>>>
>>> Aside: I realize that it would be possible for me to construct my data
>>> structure using JXTA Message objects.  However, since the data has a
>>> life of its own outside of the JXTA context, I would like to keep the
>>> data encapsulated in a single format for its whole lifetime.
>>>
>>> Please help!  Thanks.
>>>
>>>   -john.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [email protected]
>>> For additional commands, e-mail: [email protected]
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>