XOM API for Processing XML with Java

[luca <passani AT eunet.no>]

I have the impression that we are talking about different things here.
I see your point about XML and DTDs, but please try to see mine.

http://www.w3.org/XML/ reads (first line):

"Extensible Markup Language (XML) is a simple, very flexible text format derived 
from SGML"

XOM homepage (http://www.cafeconleche.org/XOM/) reads (first lines)

"XOM is a new XML object model. It is an open source (LGPL), tree-based API 
for
processing XML with Java that strives for correctness and simplicity."

now, I am trying to do something that is achieveble with 5 lines
of Perl code totally (a guru can probably do it from the command line)
using regular expressions.

Seen another way, I am trying a use a simple API to do something simple
with a tiny file which uses a simple text format. Yet, it doesn't work.

Where is the disconnect?

Luca

Elliotte Harold wrote:

> luca wrote:
>
>
> > mmmm, I don't get it. How hard could it be to have
> >
> >   Builder builder = new Builder();
> >   builder.ignoreDtdNoMatterWhat();
>
> But what do you do when you then encounter an entity reference to an 
> entity whose replacement text is not available?
>
> I really think it's safer (if not necessarily faster) to always read the 
> external DTD subset. I wrote about this in Item 18 of Effective XML, 
> which if somebody asks nicely I may put online, but here's the relevant 
> part:
>
> Consumers cannot assume that documents are self-contained. In the spirit 
> of being liberal in what you accept but conservative in what you 
> produce, when receiving a document from a third party you should do your 
> utmost to read the external DTD subset, resolve all external entity 
> references, and apply all default attribute values. You should only use 
> parsers that can do this, especially for DTDs. While most APIs allow you 
> to turn off resolution of external entity references and ignore the 
> external DTD subset, you should almost never do so. Reading the external 
> DTD subset will cost you little in the case where it isn’t necessary and 
> may save your bacon in the case where it is. Programs that repeatedly 
> read the same external DTD subsets can use the public identifiers, 
> catalogs, and various caching strategies to cache the DTDs so repeated 
> trips back to a server are not necessary. (See Item 47.)
>
> This is especially useful with web browsers and XHTML, and indeed it’s 
> sanctioned by the XHTML specification. Web browsers that support XHTML 
> have, for practical intents and purposes, internally cached the XHTML 
> DTD. Thus when they encounter a document whose public ID labels it as 
> XHTML, they do not need to read the DTD. They already know how to 
> resolve entity references like Θ and α. However, this option 
> is not available to a general purpose XML parser that does not know 
> which specific XML applications it will encounter. Such a processor must 
> read the external DTD subset before it can confidently replace all 
> entities.