java and XML

java-programmer, java and XML Hi

I have the following bit of Java code:

//Use JTidy implementation to create an empty Document object
Document doc = tidy.createEmptyDocument();
//bodyElement is the body element in an HTML Document
Node first = bodyElement.getFirstChild();
Node top = doc.getDocumentElement();
top.appendChild(first);

which produces unexpected results. Basically, all I am trying to do is
retrieve the first child node contained in the body element and copy it to
the new document element. But what I get is the required element AND every
element after it - every one of the first elements siblings! I have tried so
many variations of the above, using DocumentFragments etc, but with no joy.
In order to preserve the little hair I have left, I would be grateful for
any help

Tony

java-programmer >> java and XML Hard to do, as most HTML is so rotten it can't be parsed without a lot of
outside interference.
You can try XSLT (look at Xalan from the Apache project), but you'll likely
be unable to get it to work well unless your HTML now is almost valid XHTML
as it is.

"Tony" <email***@***.com> wrote in message
news:kKdPa.256$email***@***.com...
> Hi
>
> Are there any open source Java tools that I can use to parse HTML into the
> more
> strict format of XHTML? Basically, I need to convert HTML into an XML
> format.
>
> Thanks
>
> Tony
>
>

java-programmer >> java and XML Tony wrote:
> Are there any open source Java tools that I can use to parse HTML into the
> more
> strict format of XHTML? Basically, I need to convert HTML into an XML
> format.

Googling gave at least some hits that looked promising:

http://www.google.com/search?hl=en&ie=UTF-8&oe=UTF-8&q=html+xhtml+translate&btnG=Google+Search

You may also wish to look at HTML Tidy, which is reputed to be able to
do the job:

http://tidy.sourceforge.net/

In general, the World Wide Web Consortium is an excellent source for all
kinds of useful information including many standards ("recommendations")
defining web formats and protocols, tools and tool references,
tutorials, and much more.

http://www.w3.org

John Bollinger
email***@***.com

Posted: 2003-10-22 19:33:00

java-programmer >> java and XML Hello,

I'd like store all constants in my java-Application in an XML-file.
e.g.
<constant>
<name>con</name>
<type>long</type>
<value>10</value>
</constant>

After starting the application, the java class should be able to
create a variable with the name, the type and the value.

In this example, the java class should call the line at runtime:
long con = 10;

Has anyone an idea?

Thanks

Lucia

Posted: 2003-10-22 19:54:00

java-programmer >> java and XML Lucia wrote:
> Hello,
>
> I'd like store all constants in my java-Application in an XML-file.
> e.g.
> <constant>
> <name>con</name>
> <type>long</type>
> <value>10</value>
> </constant>
>
> After starting the application, the java class should be able to
> create a variable with the name, the type and the value.
>
> In this example, the java class should call the line at runtime:
> long con = 10;
>
> Has anyone an idea?

Does the XMLEncoder/XMLDecoder in the java.beans package help you?

f'up2 cjlp
--
Johannes Koch
In te domine speravi; non confundar in aeternum.
(Te Deum, 4th cent.)

Posted: 2003-10-22 20:13:00

java-programmer >> java and XML Lucia wrote:
> I'd like store all constants in my java-Application in an XML-file.
> e.g.
> <constant>
> <name>con</name>
> <type>long</type>
> <value>10</value>
> </constant>
>
> After starting the application, the java class should be able to
> create a variable with the name, the type and the value.
>
> In this example, the java class should call the line at runtime:
> long con = 10;
>
> Has anyone an idea?

In full generality: impossible. You could set the values via the reflection
API, but you'd still have the names and types fixed in the java classes.
You could generate the classes via a custom class loader, but then you
couldn't refer to the variables except via reflection, which would be
a really dumb and unnecessarily complex way to access config data.

All in all, it's simply a very bad idea: lots and lots of complexity
for practically no gain. Why not use a .properties file?

Posted: 2003-10-22 21:24:00

java-programmer >> java and XML Lucia wrote:
> Hello,
>
> I'd like store all constants in my java-Application in an XML-file.
> e.g.
> <constant>
> <name>con</name>
> <type>long</type>
> <value>10</value>
> </constant>
>
> After starting the application, the java class should be able to
> create a variable with the name, the type and the value.
>
> In this example, the java class should call the line at runtime:
> long con = 10;
>
> Has anyone an idea?

It wouldn't work exactly as you describe, but you could achieve a similar
effect with JAXB. Using JAXB you can easily convert an XML file into a
configuration object, and then you could get your "constants" from that
object.

java-programmer >> java and XML I'm getting very interested in XML, especially in using Java to create and
update XML files. However, the documents I'm reading about XML at IBM
Developer Works are, for the most part, quite dated with dates in 2002 and
earlier being typical.

How do I find out what the current practices are on XML and how to work with
it in Java? I don't want to waste a lot of time trying to figure out how to
use tools and techniques that have long since been replaced by far better
techniques. For example, having to use DOM to read an entire XML document in
order to insert a single element seems like a pretty dubious way of doing
something. It reminds me of storing data on magnetic tape and having to read
through most of the tape to add information to it. This seems more like the
1960s than the first decade of the 21st century. I have to assume that
someone has come up with better approaches by now.

I was also intrigued by Xindice but I'm not clear if this is a popular
approach or just an idea that never really amounted to anything.

Does anyone have any insights for me? Or suggestions on where to get good
information on this subject?

java-programmer >> java and XML rhino wrote:
> I'm getting very interested in XML, especially in using Java to create and
> update XML files. However, the documents I'm reading about XML at IBM
> Developer Works are, for the most part, quite dated with dates in 2002 and
> earlier being typical.

The JAXP interface has not changed much since then. It is fine.

Since then StAX and JAXB has been added, but you probably want plain
JAXP.

> How do I find out what the current practices are on XML and how to work with
> it in Java? I don't want to waste a lot of time trying to figure out how to
> use tools and techniques that have long since been replaced by far better
> techniques. For example, having to use DOM to read an entire XML document in
> order to insert a single element seems like a pretty dubious way of doing
> something. It reminds me of storing data on magnetic tape and having to read
> through most of the tape to add information to it. This seems more like the
> 1960s than the first decade of the 21st century. I have to assume that
> someone has come up with better approaches by now.

Reading the entire document into memory is by far the easiest.

A W3C document and then pick data with XPath is a piece of cake. And
absolutely the modern way of doing it.

If your XML files are too big for the approach, then you can look
at SAX. SAX is as old as W3C DOM in Java - and I really think it
is a better fit for your tape analogy than W3C DOM !

Arne

java-programmer >> java and XML Arne Vajh酶j wrote:
> If your XML files are too big for the approach, then you can look
> at SAX. SAX is as old as W3C DOM in Java - and I really think it
> is a better fit for your tape analogy than W3C DOM !

SAX, and its new cousin StAX, can be blazingly fast and memory efficient for
XML processing. They support and promote a strategy of single-pass
processing, where DOM approaches tend to be memory intensive with a multi-pass
sensibility. Where the streaming parser approach applies, it can really
perform very well.

--
Lew

java-programmer >> java and XML Lew wrote:
> Arne Vajh酶j wrote:
>> If your XML files are too big for the approach, then you can look
>> at SAX. SAX is as old as W3C DOM in Java - and I really think it
>> is a better fit for your tape analogy than W3C DOM !
>
> SAX, and its new cousin StAX, can be blazingly fast and memory efficient
> for XML processing. They support and promote a strategy of single-pass
> processing, where DOM approaches tend to be memory intensive with a
> multi-pass sensibility. Where the streaming parser approach applies, it
> can really perform very well.

Yes - they perform well.

But they do have the same sequential processing characteristics
as tapes unlike DOM and XPath which is more like random access on
disk files.

Arne

java-programmer >> java and XML Arne Vajh酶j wrote:
> Lew wrote:
>> Arne Vajh酶j wrote:
>>> If your XML files are too big for the approach, then you can look
>>> at SAX. SAX is as old as W3C DOM in Java - and I really think it
>>> is a better fit for your tape analogy than W3C DOM !
>>
>> SAX, and its new cousin StAX, can be blazingly fast and memory
>> efficient for XML processing. They support and promote a strategy of
>> single-pass processing, where DOM approaches tend to be memory
>> intensive with a multi-pass sensibility. Where the streaming parser
>> approach applies, it can really perform very well.
>
> Yes - they perform well.
>
> But they do have the same sequential processing characteristics
> as tapes unlike DOM and XPath which is more like random access on
> disk files.

Indeed. This is part of the tradeoff in the decision of "[w]here the
streaming parser approach applies".

Even when one needs random access, one might still use a streaming approach to
load the InputSource. java.util.Properties is an example -
<http://java.sun.com/javase/6/docs/api/java/util/Properties.html>
it could (and likely does) use a streaming parser to implement loadFromXML(),
then it provides random access for its clients from an in-memory structure
that is not a DOM tree.

--
Lew

java-programmer >> java and XML Lew wrote:
> Even when one needs random access, one might still use a streaming
> approach to load the InputSource. java.util.Properties is an example -
> <http://java.sun.com/javase/6/docs/api/java/util/Properties.html>
> it could (and likely does) use a streaming parser to implement
> loadFromXML(), then it provides random access for its clients from an
> in-memory structure that is not a DOM tree.

A quick glance in the source code seems to indicate that it uses
W3C DOM.

And considering that properties files usually are KB not MB, then
it is should be OK.

Arne