XOM API for Processing XML with Java

["Orenchak, James" <James.Orenchak AT norcom.de>]

Hi,

I just tried compiling XOM Version 1-0a2 under Windows2000 using Java
Version 1.4.2_03, but I get this error message:
[javac] symbol : method resetCommon ()
[javac] location: class nu.xom.xerces.XML1_0ParserConfiguration
[javac]              resetCommon();
[javac]               ^
[javac] C:\XOM\build\src\nu\xom\exerces\XML1_0ParserConfiguration.java:69:
cannot resolve symbol
[javac] symbol : variable fConfigUpdated
[javac] location : class nu.xom.xerces.XML1_0ParserConfiguration
[javac]              fConfigUpdated = false;
[javac]              ^             
[javac] C:\XOM\build\src\nu\xom\exerces\XML1_0ParserConfiguration.java:71:
cannot resolve symbol
[javac] symbol : variable fCurrentScanner
[javac] location: class.nu.xom.xerces.XML1_0ParserConfiguration
[javac]              (XMLEntityHandler) fCurrentScanner, version);
[javac] C:\XOM\build\src\nu\xom\exerces\XML1_0ParserConfiguration.java:75:
cannot resolve symbol
[javac] symbol : variable fCurrentScanner
[javac] location: class.nu.xom.xerces.XML1_0ParserConfiguration
[javac]         return fCurrentScanner.scanDocumnet(complete);
[javac]                ^
[javac] 4 errors

My classpath is set to
C:\xom\xom-1.0a2.jar;C:\xom\lib\dtd-xercesImpl.jar;C:\xom\lib\junit.jar;C:\x
om\lib\normalizer.jar;C:\xom\lib\servlet.jar;C:\xom\lib\xalan.jar;C:\xom\lib
\xercesImpl.jar;C:\xom\lib\xmlParserAPIs.jar;C:\ant\lib\ant.jar;C:\ant\lib\o
ptional.jar;.;

I didn't have any problems compiling the same version of XOM and running the
tests under Linux.  Could this be a problem with Xerces?  Are some sort of
configuration values for Xerces set under Linux, but not under Windows?  Any
help would be appreciated!

Mit freundlichen Grüßen / Best Regards

i.A. James Orenchak 
NorCom Information Technology AG
Solmsstraße 18
D-60486 Frankfurt
Fon +49 (0) 69 589 96 199, Fax +49(0) 69 589 96 111
Mobil +49 (0)178 809 5216  
<mailto:james.orenchak AT norcom.de> 
<http://www.norcom.de> 

"This e-mail, including attachments, contains privileged and confidential
information intended only for the use of the addressee(s). If you are not an
intended recipient of this email, you are hereby notified that any
dissemination, copying or use of information within it is strictly
prohibited. If you received this email in error or without authorisation,
please notify us immediately by reply e-mail and delete the e-mail from your
system. If you need any further assistance, please contact us at
webmaster AT norcom.de!"


-----Ursprüngliche Nachricht-----
Von: xom-interest-request AT lists.ibiblio.org
[mailto:xom-interest-request AT lists.ibiblio.org]
Gesendet: Donnerstag, 24. Juni 2004 18:11
An: xom-interest AT lists.ibiblio.org
Betreff: XOM-interest Digest, Vol 17, Issue 12


Send XOM-interest mailing list submissions to
        xom-interest AT lists.ibiblio.org

To subscribe or unsubscribe via the World Wide Web, visit
        http://lists.ibiblio.org/mailman/listinfo/xom-interest
or, via email, send a message with subject or body 'help' to
        xom-interest-request AT lists.ibiblio.org

You can reach the person managing the list at
        xom-interest-owner AT lists.ibiblio.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of XOM-interest digest..."


Today's Topics:

   1. problem with latest alpha (luca)
   2. East Asian Character Sets (Elliotte Harold)
   3. Re: problem with latest alpha (Elliotte Rusty Harold)
   4. Re: East Asian Character Sets (John Cowan)
   5. Re: problem with latest alpha (luca)
   6. Re: problem with latest alpha (luca)
   7. Re: problem with latest alpha (Elliotte Rusty Harold)
   8. Re: problem with latest alpha (Elliotte Rusty Harold)
   9. Re: problem with latest alpha (luca)
  10. XOM 1.0 alpha 3 (Elliotte Rusty Harold)


----------------------------------------------------------------------

Message: 1
Date: Wed, 23 Jun 2004 23:45:30 +0200
From: luca <passani AT eunet.no>
Subject: [XOM-interest] problem with latest alpha
To: xom-interest AT lists.ibiblio.org
Message-ID: <40D9F9FA.20908 AT eunet.no>
Content-Type: text/plain; charset=us-ascii; format=flowed


I am about to ship a new version of the WURFL library. Before
I did that, I thought it was a good idea to upgrade from
xom-1.0d25.jar to xom-1.0a2.jar

I also assumed this to be safe. Unfortunately, here is what I get:

compileapi:
     [javac] Compiling 8 source files to C:\projects\wurfl\antbuild\build
     [javac]
C:\projects\wurfl\antbuild\src\net\sourceforge\wurfl\wurflapi\Wurfl.
java:320: cannot resolve symbol
     [javac] symbol  : class ParseException
     [javac] location: class net.sourceforge.wurfl.wurflapi.Wurfl
     [javac]     } catch (ParseException ex) {
     [javac]                  ^
     [javac]
C:\projects\wurfl\antbuild\src\net\sourceforge\wurfl\wurflapi\Wurfl.
java:579: cannot resolve symbol
     [javac] symbol  : method preserveBaseURI (boolean)
     [javac] location: class nu.xom.Serializer
     [javac]     serializer.preserveBaseURI(false);
     [javac]                   ^
     [javac] 2 errors

Can someone tell me what's wrong and which changes are impacting my build?

I saw all the discussion about the baseURI, but I have to confess
I didn't pay it much attention.  Can I remove
the serializer.preserveBaseURI(false) line without problems?

What about ParseException?

thanks

Luca






------------------------------

Message: 2
Date: Wed, 23 Jun 2004 20:39:24 -0400
From: Elliotte Harold <elharo AT metalab.unc.edu>
Subject: [XOM-interest] East Asian Character Sets
To: xom-interest <xom-interest AT lists.ibiblio.org>
Message-ID: <40DA22BC.5050905 AT metalab.unc.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

I had planned to add support for several East Asian character sets to 
XOM, including Big5, SJIS, and a few others. In fact, I've actually 
added EUC-JP and Big5 to CVS. However in doing so I've discovered that 
this is quite a bit trickier than I thought. In particular, there is no 
1-1 mapping between these character sets and Unicode. It is not always 
obvious (or even decidable) which Unicode code point matches which SJIS 
code point. The problems are elaborated in detail in the W3C Note "XML 
Japanese Profile" <http://www.w3.org/TR/2000/NOTE-japanese-xml-20000414> 
by Murata Makoto et al. The bottom line is that "This technical report 
recommends the use of UTF-8 (or UTF-16)."; and since the authors 
certainly know a lot more about Japanese than I ever will, I'm inclined 
to follow their lead.

I haven't found anything that lays out the issues quite so clearly for 
Chinese character sets such as Big5 but reading between the lines of 
various specs, I suspect the same issues apply. Most of the specs of 
interest (except GB18030)  predate Unicode and do not have clear and 
unambiguous mappings to Unicode characters in all cases.

Therefore, in keeping with XOM's principle of making it easy to do the 
right thing and hard to do the wrong thing, and trusting Muratasan's 
judgement that the right thing for Japanese XML is UTF-8 or UTF-16, my 
current plan is not to do any further work on supporting these legacy 
character sets for East Asian characters. Furthermore I plan to remove 
the explicit support I've recently added for EUC-JP and Big5.

I should add that I have recently hacked together a GenericWriter class 
outside the public API that works for any character set the local VM 
recognizes, irrespective of whether XOM has explicit support for it. 
Thus it will still be possible for the Serializer to output characters 
in SJIS, Big5, EUC-JP and other non-supported encodings such as MacRoman 
and Cp1252; and such output shouldn't produce any unnecessary numeric 
character references at least to the limit of what the VM understands. 
(One thing I've noticed in all this work is that Java's built in mapping 
tables are often quite buggy.) However, using an unsupported character 
set carries a lot of extra overhead and is likely to be quite a bit 
slower than using a supported encoding such as UTF-8 or ISO-8859-1. (I 
haven't yet measured exactly how much slower it actually is. I could be 
pleasantly surprised. Eyeballing it's probably not more than one order 
of magnitude and maybe less.) But it will still be possible to use 
Big5/SJIS/EUC-JP etc. if someone really wants to do that.

Comments? Thoughts? Suggestions? I'd be particularly interested in 
hearing from anyone who knows if these issues really do apply to Chinese 
and/or Korean character sets. I'm guessing the same issues arise, but I 
could be wrong about that, especially for Korean which I haven't looked 
into yet.

--
Elliotte Rusty Harold



------------------------------

Message: 3
Date: Wed, 23 Jun 2004 21:37:44 -0400
From: Elliotte Rusty Harold <elharo AT metalab.unc.edu>
Subject: Re: [XOM-interest] problem with latest alpha
To: luca <passani AT eunet.no>
Cc: xom-interest AT lists.ibiblio.org
Message-ID: <p06010200bcffe0bbcda1@[192.168.254.88]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

I didn't change anything that should have affected that. It should 
work. Is it possible you have some sort of CLASSPATH issue?

-- 

   Elliotte Rusty Harold
   elharo AT metalab.unc.edu
   Effective XML (Addison-Wesley, 2003)
   http://www.cafeconleche.org/books/effectivexml
 
http://www.amazon.com/exec/obidos/ISBN%3D0321150406/ref%3Dnosim/cafeaulaitA


------------------------------

Message: 4
Date: Thu, 24 Jun 2004 01:17:44 -0400
From: John Cowan <cowan AT ccil.org>
Subject: Re: [XOM-interest] East Asian Character Sets
To: Elliotte Harold <elharo AT metalab.unc.edu>
Cc: xom-interest AT lists.ibiblio.org
Message-ID: <20040624051744.GM3054 AT ccil.org>
Content-Type: text/plain; charset=us-ascii

Elliotte Harold scripsit:

> Comments? Thoughts? Suggestions? I'd be particularly interested in 
> hearing from anyone who knows if these issues really do apply to Chinese 
> and/or Korean character sets. I'm guessing the same issues arise, but I 
> could be wrong about that, especially for Korean which I haven't looked 
> into yet.

They apply to all of the CJK encodings.  There are two main issues:

1) ASCII variants.  ISO 646 used to allow the creation of national
variants by reassigning certain characters (IIRC they were #@[\]^_{|}~).
the CJK encodings exploited this opportunity by doing things like
putting YEN SIGN in the place of \.  Localizations of DOS and other
operating systems tended to ignore this, however, so Japanese DOS users
saw pathnames separated by YEN SIGNs instead of \s, and C programmers
saw escapes starting with YEN SIGNs as well.  Therefore, the same byte
can represent either of two Unicode characters.  AFAIK Chinese was not
affected by this.

2) Definition-by-glyph.  There are no definitive mappings for Western
characters included in the CJK encodings, because characters were
defined in those standards by specifying normative glyphs.  The Han
unification effort nailed down for all Han characters exactly what
corresponds to which Unicode value (the results of which are available
in http://www.unicode.org/Public/UNIDATA/Unihan.txt (warning: 26 MB).
The other characters, however, have to be mapped by common sense, and
intelligent people can disagree about the most appropriate mappings.

-- 
John Cowan  cowan AT ccil.org  www.ccil.org/~cowan  www.reutershealth.com
"In the sciences, we are now uniquely privileged to sit side by side
with the giants on whose shoulders we stand."
        --Gerald Holton


------------------------------

Message: 5
Date: Thu, 24 Jun 2004 08:51:01 +0200
From: luca <passani AT eunet.no>
Subject: Re: [XOM-interest] problem with latest alpha
To: xom-interest AT lists.ibiblio.org
Message-ID: <40DA79D5.9080002 AT eunet.no>
Content-Type: text/plain; charset=us-ascii; format=flowed



Elliotte Rusty Harold wrote:
 > I didn't change anything that should have affected that. It should work.
 > Is it possible you have some sort of CLASSPATH issue?
 >

unlikely, I am using a pretty simple ANT build.xml
file. Right after I replaced the jars, I had not
fixed this line:

      <property name="xomlib" value="xom-1.0a2.jar" />

so I got one zilion errors. Once I did, it went down to the
2 errors I reported.

      <target name="compileapi" depends="prepare">
           <javac srcdir="${srcapi}" destdir="${build}">
             <classpath>
               <pathelement location="lib/${xomlib}" />
               <pathelement location="lib/xercesImpl.jar" />
               <pathelement location="lib/xmlParserAPIs.jar" />
               <pathelement location="lib/junit.jar" />
               <pathelement location="lib/servlet.jar" />
             </classpath>
           <include name="net/sourceforge/wurfl/wurflapi/" />
           </javac>
      </target>

I also noted that the d25 jar was over 200 Kb. The a2 is down to 100....

I'll see if I can figure out something by myself and let you know

thanks

Luca



------------------------------

Message: 6
Date: Thu, 24 Jun 2004 09:04:50 +0200
From: luca <passani AT eunet.no>
Subject: Re: [XOM-interest] problem with latest alpha
To: xom-interest AT lists.ibiblio.org
Message-ID: <40DA7D12.60900 AT eunet.no>
Content-Type: text/plain; charset=us-ascii; format=flowed



commenting out the line:

        //serializer.preserveBaseURI(false);

and changing the line:

        } catch (ParsingException ex) {

did the job.

I have a bunch of Unit tests failure now, but that might be a different
story :(

thank you and apologies for all this traffic

Luca

luca wrote:

> Elliotte Rusty Harold wrote:
>  > I didn't change anything that should have affected that. It should
work.
>  > Is it possible you have some sort of CLASSPATH issue?
>  >
> 
> unlikely, I am using a pretty simple ANT build.xml
> file. Right after I replaced the jars, I had not
> fixed this line:
> 
>      <property name="xomlib" value="xom-1.0a2.jar" />
> 
> so I got one zilion errors. Once I did, it went down to the
> 2 errors I reported.
> 
>      <target name="compileapi" depends="prepare">
>           <javac srcdir="${srcapi}" destdir="${build}">
>             <classpath>
>               <pathelement location="lib/${xomlib}" />
>               <pathelement location="lib/xercesImpl.jar" />
>               <pathelement location="lib/xmlParserAPIs.jar" />
>               <pathelement location="lib/junit.jar" />
>               <pathelement location="lib/servlet.jar" />
>             </classpath>
>           <include name="net/sourceforge/wurfl/wurflapi/" />
>           </javac>
>      </target>
> 
> I also noted that the d25 jar was over 200 Kb. The a2 is down to 100....
> 
> I'll see if I can figure out something by myself and let you know
> 
> thanks
> 
> Luca
> 
> _______________________________________________
> XOM-interest mailing list
> XOM-interest AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/xom-interest
> 



------------------------------

Message: 7
Date: Thu, 24 Jun 2004 06:54:49 -0400
From: Elliotte Rusty Harold <elharo AT metalab.unc.edu>
Subject: Re: [XOM-interest] problem with latest alpha
To: luca <passani AT eunet.no>
Cc: xom-interest AT lists.ibiblio.org
Message-ID: <p06010204bd0062fd685a@[192.168.254.88]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

At 9:04 AM +0200 6/24/04, luca wrote:
>commenting out the line:
>
>       //serializer.preserveBaseURI(false);
>
>and changing the line:
>
>       } catch (ParsingException ex) {
>

Are you sure you weren't a little further back than 1.0d25? 
preserveBaseURI was changed to setPreserveBaseURI and ParseERxception 
changed to ParsingException in 1.0d22.
-- 

   Elliotte Rusty Harold
   elharo AT metalab.unc.edu
   Effective XML (Addison-Wesley, 2003)
   http://www.cafeconleche.org/books/effectivexml
 
http://www.amazon.com/exec/obidos/ISBN%3D0321150406/ref%3Dnosim/cafeaulaitA


------------------------------

Message: 8
Date: Thu, 24 Jun 2004 06:55:54 -0400
From: Elliotte Rusty Harold <elharo AT metalab.unc.edu>
Subject: Re: [XOM-interest] problem with latest alpha
To: luca <passani AT eunet.no>
Cc: xom-interest AT lists.ibiblio.org
Message-ID: <p06010205bd0063868858@[192.168.254.88]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

At 8:51 AM +0200 6/24/04, luca wrote:

>I also noted that the d25 jar was over 200 Kb. The a2 is down to 100....

That's probably because I turned off debugging symbols. Code-wise 
there's very little that's in d25 that isn't in a2.
-- 

   Elliotte Rusty Harold
   elharo AT metalab.unc.edu
   Effective XML (Addison-Wesley, 2003)
   http://www.cafeconleche.org/books/effectivexml
 
http://www.amazon.com/exec/obidos/ISBN%3D0321150406/ref%3Dnosim/cafeaulaitA


------------------------------

Message: 9
Date: Thu, 24 Jun 2004 16:22:14 +0200
From: luca <passani AT eunet.no>
Subject: Re: [XOM-interest] problem with latest alpha
To: xom-interest AT lists.ibiblio.org
Message-ID: <40DAE396.6010003 AT eunet.no>
Content-Type: text/plain; charset=us-ascii; format=flowed


You are right. It was d21.  Sorry for the confusion and thanks for your
help.

Luca

Elliotte Rusty Harold wrote:

> Are you sure you weren't a little further back than 1.0d25? 
> preserveBaseURI was changed to setPreserveBaseURI and ParseERxception 
> changed to ParsingException in 1.0d22.



------------------------------

Message: 10
Date: Thu, 24 Jun 2004 10:50:29 -0400
From: Elliotte Rusty Harold <elharo AT metalab.unc.edu>
Subject: [XOM-interest] XOM 1.0 alpha 3
To: xom-interest AT lists.ibiblio.org
Message-ID: <p06010208bd009a1b5b64@[192.168.254.88]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

I have posted the third alpha release of XOM in the usual location:

http://cafeconleche.org/XOM/

1.0a3 makes no backwards incompatible changes to the published API. 
It adds one new protected method. Changes since the previous release 
include:

     * The Element copy constructor and copy methods are no longer 
recursive, so they shouldn't cause stack overflows in deep documents. 
This necessitated adding a protected shallowCopy() method that can be 
used to create an instance of a subclass of Element. Overriding this 
is preferred to overriding copy() when one wishes to maintain the 
objects' types after a copy.

     * The getBaseURI()  method is also no longer recursive.

     * The W3C XML Schema Language and WML and HTML DOMs have been 
removed from the bundled version of Xerces to save space.

     * XOM now uses character references only when necessary for all 
encodings supported by the local virtual machine. However, this may 
be quite a bit slower than the explicitly supported encodings like 
UTF-8 and the ISO-8859 character sets. Measurements remain to be 
performed.

    * XOM no longer uses its own custom parser configuration. This 
should make it more compatible with more versions of Xerces.

If noone notices any major problems with this release, I'll probably 
announce it on Cafe con Leche tomorrow.

-- 

   Elliotte Rusty Harold
   elharo AT metalab.unc.edu
   Effective XML (Addison-Wesley, 2003)
   http://www.cafeconleche.org/books/effectivexml            
 
http://www.amazon.com/exec/obidos/ISBN%3D0321150406/ref%3Dnosim/cafeaulaitA 


------------------------------

_______________________________________________
XOM-interest mailing list
XOM-interest AT lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/xom-interest


End of XOM-interest Digest, Vol 17, Issue 12
********************************************