From wanja@inzen.com  Sun Jun  2 22:49:02 2002
From: wanja@inzen.com (jhlee)
Date: Sun Jun  2 21:49:02 2002
Subject: [Expat-discuss] Solaris 64bit Compile
Message-ID: <000601c20ab9$f50c5990$0149030a@WANJA>

This is a multi-part message in MIME format.

---------------------- multipart/alternative attachment
Hi,

I'm new to this list and I'm having problems compiling expat on a

Ultrasparc2 (64bit) Solaris2.8 machine.

I tried compiling with gcc -mcpu=v9 -Wa,--xarch=v9a

(the -Wa option is needed to tell the assembler the architecture
otherwise I get assembler errors)

There aren't any problems compiling .c files.

But I'm having errors with ld.

 

...

...

gcc -DHAVE_CONFIG_H -DPACKAGE=\"expat\" -DVERSION=\"expat_1.95.2\" -I.
-I. -I.. -mcpu=v9 -Wa,--xarch=v9a -g -O2 -Wall -Wmissing-prototypes
-Wstrict-prototypes -fexceptions -c xmltok.c  -fPIC -DPIC -o
.libs/xmltok.lo

gcc -DHAVE_CONFIG_H -DPACKAGE=\"expat\" -DVERSION=\"expat_1.95.2\" -I.
-I. -I.. -mcpu=v9 -Wa,--xarch=v9a -g -O2 -Wall -Wmissing-prototypes
-Wstrict-prototypes -fexceptions -c xmltok.c -o xmltok.o >/dev/null 2>&1

mv -f .libs/xmltok.lo xmltok.lo

/bin/sh ../libtool --mode=link  gcc -version-info 1:0:1 -mcpu=v9
-Wa,--xarch=v9a -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes
-fexceptions  -o libexpat.la -rpath /usr/local/lib  xmlparse.lo
xmltok.lo xmlrole.lo

rm -fr .libs/libexpat.la .libs/libexpat.* .libs/libexpat.*

/usr/ccs/bin/ld -G -h libexpat.so.0 -o .libs/libexpat.so.0.1.0
xmlparse.lo xmltok.lo xmlrole.lo  -lc 

ld: fatal: file xmltok.lo: wrong ELF class: ELFCLASS64

 

Does anyone how I can solve this?

 

Thanks ahead~!

 

-Jh Lee

 


---------------------- multipart/alternative attachment
An HTML attachment was scrubbed...
URL: http://mail.libexpat.org/pipermail-21/expat-discuss/attachments/20020602/ca460a60/attachment.html

---------------------- multipart/alternative attachment--



From fdrake@acm.org  Mon Jun  3 23:14:01 2002
From: fdrake@acm.org (Fred L. Drake, Jr.)
Date: Mon Jun  3 22:14:01 2002
Subject: [Expat-discuss] Expat 1.95.3 is available!
Message-ID: <15612.19549.858547.240505@grendel.zope.com>

We've just released Expat 1.95.3, which continues our traditional for
frequent, seriously delayed releases which mostly fix small problems.

Unlike the last seriously delayed release which mostly fixed small,
annoying problems, this release has some more substantial
improvements, in part due to a new developer on the project.

In particular, we've made the following changes:

- Changed the name of the Windows DLLs from expat.dll to libexpat.dll;
  this fixes SF bug #432456.  This is a problem only known to affect
  the Perl XML::Parser::Expat extension, but is very important for
  that extension.

- Added a project to the MSVC workspace to create a wchar_t version of
  the library; the DLLs are named libexpatw.dll.  (Note the addition
  of the "w" character in the file name.)

- Added the XML_ParserReset() API function.  This allows a parser to
  be re-used, reducing the number of memory allocations needed to set
  up a parser.  This can be a substantial benefit when parsing a large
  number of small documents.

- Fixed XML_SetReturnNSTriplet() to work for element names.  This is
  now a usable feature.

- Made the XML_UNICODE builds usable (thanks, Karl!).

- Allow xmlwf to read from standard input.

- Install a man page for xmlwf on Unix systems.

- Fixed many bugs; see SF bug reports 231864, 461380, 464837, 466885,
  469226, 477667, 484419, 487840, 494749, 496505, 547350.  Other bugs
  which we can't test as easily may also have been fixed, especially
  in the area of build support.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at acm.org>
PythonLabs at Zope Corporation


From Josh.Martin@abq.sc.philips.com  Wed Jun  5 18:01:07 2002
From: Josh.Martin@abq.sc.philips.com (Josh Martin)
Date: Wed Jun  5 17:01:07 2002
Subject: [Expat-discuss] Solaris 64bit Compile
Message-ID: <200206060000.SAA12744@abqn42.abq.sc.philips.com>

My first thought is that you aren't using the 64-bit linker.  However the sparc 
linker is both 32-bit and 64-bit.  Since there is no option to specify which 
mode to use, the linker uses the mode of the first object listed, in which case 
you may want to try the linking command with xmltok.lo listed first.

My second thought is that gcc might not be generating 64-bit code.  Since the 
linker seems to think the object file is ELFCLASS64, this seems unlikely, 
however you may want to add the SPARC V9 specific gcc option -m64 to ensure that 
it is generating code for a 64-bit environment.

Unfortunately all of the sparcs I work on either aren't 64-bit machines, or they 
refuse to run in 64-bit mode (long story), I cannot claim that either of these 
thoughts may be helpful.  Let me know if you figure out a way to get this to 
work for you.  Also do yourself a favor and make sure that the information 
displayed by 'ld -V' is the information you think it should be; it wouldn't be 
the first time someone forgot to update the linker when a file system was 
migrated to a different machine.

 - Josh Martin
 

> Hi,
> 
> I'm new to this list and I'm having problems compiling expat on a
> 
> Ultrasparc2 (64bit) Solaris2.8 machine.
> 
> I tried compiling with gcc -mcpu=v9 -Wa,--xarch=v9a
> 
> (the -Wa option is needed to tell the assembler the architecture
> otherwise I get assembler errors)
> 
> There aren't any problems compiling .c files.
> 
> But I'm having errors with ld.
> 
>  
> 
> ...
> 
> ...
> 
> gcc -DHAVE_CONFIG_H -DPACKAGE=\"expat\" -DVERSION=\"expat_1.95.2\" -I.
> -I. -I.. -mcpu=v9 -Wa,--xarch=v9a -g -O2 -Wall -Wmissing-prototypes
> -Wstrict-prototypes -fexceptions -c xmltok.c  -fPIC -DPIC -o
> .libs/xmltok.lo
> 
> gcc -DHAVE_CONFIG_H -DPACKAGE=\"expat\" -DVERSION=\"expat_1.95.2\" -I.
> -I. -I.. -mcpu=v9 -Wa,--xarch=v9a -g -O2 -Wall -Wmissing-prototypes
> -Wstrict-prototypes -fexceptions -c xmltok.c -o xmltok.o >/dev/null 2>&1
> 
> mv -f .libs/xmltok.lo xmltok.lo
> 
> /bin/sh ../libtool --mode=link  gcc -version-info 1:0:1 -mcpu=v9
> -Wa,--xarch=v9a -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes
> -fexceptions  -o libexpat.la -rpath /usr/local/lib  xmlparse.lo
> xmltok.lo xmlrole.lo
> 
> rm -fr .libs/libexpat.la .libs/libexpat.* .libs/libexpat.*
> 
> /usr/ccs/bin/ld -G -h libexpat.so.0 -o .libs/libexpat.so.0.1.0
> xmlparse.lo xmltok.lo xmlrole.lo  -lc 
> 
> ld: fatal: file xmltok.lo: wrong ELF class: ELFCLASS64
> 
>  
> 
> Does anyone how I can solve this?
> 
>  
> 
> Thanks ahead~!
> 
>  
> 
> -Jh Lee
> 
>  
> 



From Josh.Martin@abq.sc.philips.com  Wed Jun  5 18:07:06 2002
From: Josh.Martin@abq.sc.philips.com (Josh Martin)
Date: Wed Jun  5 17:07:06 2002
Subject: [Expat-discuss] Compile error using cc
Message-ID: <200206060006.SAA12752@abqn42.abq.sc.philips.com>

You are using the C compiler that comes bundled with HPUX.  This compiler is 
only meant to be used to re-compile the kernel, and isn't really ANSI standard.  
You either need to contact HP and have them send you the HP ANSI C compiler 
package (I forget what the product name is, but that should be close enough), or 
use the GNU C compiler (gcc), which _can_ be successfully built with the bundled 
compiler.

 - Josh Martin

> hi,
> 
> I am trying to compile on HP UX 11i, it gives following error for make
> 
> Entering directory `/home/ritesh/expat-1.95.2/lib'
> /bin/sh ../libtool --mode=compile cc -DHAVE_CONFIG_H -DPACKAGE='"expat"' 
-DVERSION='"expat_1.95.2"' -I. -I. -I..   -c xmlparse.c
> cc -DHAVE_CONFIG_H -DPACKAGE=\"expat\" -DVERSION=\"expat_1.95.2\" -I. -I. -I.. 
-c xmlparse.c -o xmlparse.o
> (Bundled) cc: "expat.h", line 80: error 1000: Unexpected symbol: "XML_Char".
> (Bundled) cc: "expat.h", line 81: error 1000: Unexpected symbol: "*".
> (Bundled) cc: error 2017: Cannot recover from earlier errors, terminating.
> 
> Any help is highly appreciated.
> 
> Thanx
> Ritesh Garodia



From Josh.Martin@abq.sc.philips.com  Wed Jun  5 18:35:02 2002
From: Josh.Martin@abq.sc.philips.com (Josh Martin)
Date: Wed Jun  5 17:35:02 2002
Subject: [Expat-discuss] Looking for sample code using ExternalEntityRefHandler
Message-ID: <200206060034.SAA12762@abqn42.abq.sc.philips.com>

Since I'm not sure that you've had a chance to read this, I'll just quote the 
documentation for the XML_ExternalEntityRefHandler handler.  If you'd like more, 
or different information, let me know.  If, however, you do understand the 
meaning of the properties that are passed to the handler, but are not sure what 
should be done with them, I'll discuss that after the documentation block.

 - Josh Martin

****************************************

XML_SetExternalEntityRefHandler(XML_Parser p,
                                      XML_ExternalEntityRefHandler hndl)

      typedef int
      (*XML_ExternalEntityRefHandler)(XML_Parser p,
                                      const XML_Char *context,
                                      const XML_Char *base,
                                      const XML_Char *systemId,
                                      const XML_Char *publicId);

        Set an external entity reference handler. This handler is also called 
for processing an external DTD subset if parameter entity parsing is in effect. 
(See XML_SetParamEntityParsing.)

        The base parameter is the base to use for relative system identifiers. 
It is set by XML_SetBase and may be null. The public id parameter is the public 
id given in the entity declaration and may be null. The system id is the system 
identifier specified in the entity declaration and is never null.

        There are a couple of ways in which this handler differs from others. 
First, this handler returns an integer. A non-zero value should be returned for 
successful handling of the external entity reference. Returning a zero indicates 
failure, and causes the calling parser to return an 
XML_ERROR_EXTERNAL_ENTITY_HANDLING error.

        Second, instead of having userData as its first argument, it receives 
the parser that encountered the entity reference. This, along with the context 
parameter, may be used as arguments to a call to XML_ExternalEntityParserCreate. 
Using the returned parser, the body of the external entity can be recursively 
parsed.

        Since this handler may be called recursively, it should not be saving 
information into global or static variables.
        
****************************************

The handler should open the file that is referenced by the 'base' and 'systemId' 
properties, and create a new XML_Parser object from the old one by calling 
XML_ExternalEntityParserCreate with the 'p' and 'context' properties and the 
desired encoding mode.  This new parser will inherit state information such as 
handlers, user data, and namespace processing from the old parser.  It should 
then proceed to parse this new parser buffer just like any other buffer, using 
the XML_Parse or XML_ParseBuffer methods.
 
> Hi,
> I'm using the expat parser for a Pocket PC app developed using MS emBedded C++ 
and the std
> XML_ParserCreate doesn't work very well for the following tag:
> <Description>Anything containing encoded data such as 
&amp;&lt;96D&gt;Accepted</Description>
> 
> I beleive I need to set entity parsing to XML_PARAM_ENTITY_PARSING_NEVER .  
The function is not
> available to me which probably means my compilation of expat is missing 
something.  It's not clear to
> me what should be in the ExternalEntityRefHandler callback function.
> 
> Any help is appreciated.
> 
> Thanks
> Tom
> 
> 	g GE Global Research Center
> 	
> 
________________________________________________________________________________
_____________________
> __________________________________________________________
> 	Tom St.Louis
> 	Computer Scientist
> 	Advanced Computing Technologies
> 	One Research Circle, K1-5B32	
> 	Niskayuna, NY  12309
> 	8*833-4900
> 	stlouis@crd.ge.com
> 
> 
> _______________________________________________________________
> 
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
> 
> _______________________________________________
> Expat-discuss mailing list
> Expat-discuss@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/expat-discuss



From YTian@cya.com  Thu Jun  6 08:12:04 2002
From: YTian@cya.com (YTian@cya.com)
Date: Thu Jun  6 07:12:04 2002
Subject: [Expat-discuss] How to handle predefined entities?
Message-ID: <OFF0D79FFA.C9C74AB1-ON85256BD0.004C3F43@cya.com>

Hi, all,

How to handle prededined entities in Expat? (like >, <, & ...) I am using
Expat-1.95.2.

In my xml file, there is an element looks like:
      <eleOne>id &lt; 123</eleOne>
I expected to get "id < 123", but the result was "id ". Seems expat
couldn't go through the &*; .
So, which handler should I use? Do you have any experience about this?


Thank you.


Yuqian.



From Josh.Martin@abq.sc.philips.com  Thu Jun  6 11:58:05 2002
From: Josh.Martin@abq.sc.philips.com (Josh Martin)
Date: Thu Jun  6 10:58:05 2002
Subject: [Expat-discuss] How to handle predefined entities?
Message-ID: <200206061757.LAA13098@abqn42.abq.sc.philips.com>

I hate to be obtuse, but are you sure you didn't get the whole string?  Expat 
can hand you the text inside and element in seemingly random sized chunks.  Did 
you continue to build up the string inside of your character data handler until 
the end-element handler was called?

 - Josh Martin

> Hi, all,
> 
> How to handle prededined entities in Expat? (like >, <, & ...) I am using
> Expat-1.95.2.
> 
> In my xml file, there is an element looks like:
>       <eleOne>id &lt; 123</eleOne>
> I expected to get "id < 123", but the result was "id ". Seems expat
> couldn't go through the &*; .
> So, which handler should I use? Do you have any experience about this?
> 
> 
> Thank you.
> 
> 
> Yuqian.
> 
> 
> _______________________________________________________________
> 
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
> 
> _______________________________________________
> Expat-discuss mailing list
> Expat-discuss@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/expat-discuss



From nvtek@yahoo.com  Thu Jun  6 13:32:36 2002
From: nvtek@yahoo.com (Naveen Viswanatha)
Date: Thu Jun  6 12:32:36 2002
Subject: [Expat-discuss] Encoding problems on Mac OS X
Message-ID: <20020606191318.81341.qmail@web14305.mail.yahoo.com>

I am parsing xml encoded in ISO-8859-1 charset on Mac
OS 10.1 using expat v1.95.1 and v1.95.3.  On some XML
files everything works ok, however, on others, the
CharacterDataHandler seems to parse garbage (wierd
unrecognizable characters). 

When I look at the actual XML file in vi, I see the
correct characters, but once I print these characters
out using the CharacterDataHandler, I get the garbage.

I have tried creating a parser with
CreateParser("ISO-8859-1") and I get the best results,
but still some garbage.  I have also tried converting
the XML file to UTF-8, but that doesn't seem to work
either.  Needless to say, I have tried different
combinations of converting XML files to different
encodings and crating parsers with NULL, UTF-8,
ISO-8859-1, but to no avail.

any help would be appreciated.
nv



__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com


From karl@waclawek.net  Thu Jun  6 13:38:57 2002
From: karl@waclawek.net (Karl Waclawek)
Date: Thu Jun  6 12:38:57 2002
Subject: [Expat-discuss] Encoding problems on Mac OS X
References: <20020606191318.81341.qmail@web14305.mail.yahoo.com>
Message-ID: <001601c20d91$5e0f5f80$9e539696@citkwaclaww2k>

> I am parsing xml encoded in ISO-8859-1 charset on Mac
> OS 10.1 using expat v1.95.1 and v1.95.3.  On some XML
> files everything works ok, however, on others, the
> CharacterDataHandler seems to parse garbage (wierd
> unrecognizable characters). 

Please post an example file.

Karl



From nvtek@yahoo.com  Fri Jun  7 00:45:02 2002
From: nvtek@yahoo.com (Naveen Viswanatha)
Date: Thu Jun  6 23:45:02 2002
Subject: [Expat-discuss] Encoding problems on Mac OS X
In-Reply-To: <001601c20d91$5e0f5f80$9e539696@citkwaclaww2k>
Message-ID: <20020607064443.74906.qmail@web14304.mail.yahoo.com>

--- Karl Waclawek <karl@waclawek.net> wrote:
> 
> > I am parsing xml encoded in ISO-8859-1 charset on
> Mac
> > OS 10.1 using expat v1.95.1 and v1.95.3.  On some
> XML
> > files everything works ok, however, on others, the
> > CharacterDataHandler seems to parse garbage (wierd
> > unrecognizable characters). 
> 
> Please post an example file.
> 
> Karl
> 

Here is a full file where I am parsing for characters
within the <dc:title> tag.  (Here they are music
artist names).  When these characters are printed
through the CharacterDataHandler (via printf's), I can
make out some of the titles, but most are garbled.

thanks.

********** Begin

<?xml version="1.0" encoding="ISO-8859-1"?>
<rdf:RDF xmlns:rdf =
"http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:dc  =
"http://purl.org/dc/elements/1.1/"
         xmlns:mq  =
"http://musicbrainz.org/mm/mq-1.0#"
         xmlns:mm  =
"http://musicbrainz.org/mm/mm-2.0#">
  <mq:Result>
    <mq:status>OK</mq:status>
    <mm:artistList>
      <rdf:Bag>
        <rdf:li
rdf:resource="http://musicbrainz.org/artist/9481010a-db23-469d-87df-b04118850efb"/>
        <rdf:li
rdf:resource="http://musicbrainz.org/artist/39c2a93d-9afa-4a22-9bba-c087ab056e1c"/>
        <rdf:li
rdf:resource="http://musicbrainz.org/artist/21091760-3b04-48ca-9aa4-40ab0eb29f5a"/>
        <rdf:li
rdf:resource="http://musicbrainz.org/artist/ffc48cf9-bb16-42d4-b37f-e46a3438312c"/>
        <rdf:li
rdf:resource="http://musicbrainz.org/artist/4854429b-66f7-41c0-a89c-030bb7ccf958"/>
        <rdf:li
rdf:resource="http://musicbrainz.org/artist/1b90728d-a656-41eb-bc98-144336ecf68b"/>
        <rdf:li
rdf:resource="http://musicbrainz.org/artist/93938558-9a84-4a7f-a15c-6f145100ff5c"/>
        <rdf:li
rdf:resource="http://musicbrainz.org/artist/42355982-7f15-4200-925b-e6dd9f451776"/>
      </rdf:Bag>
    </mm:artistList>
  </mq:Result>

  <mm:Artist
rdf:about="http://musicbrainz.org/artist/9481010a-db23-469d-87df-b04118850efb">
    <dc:title>Blind Lemon Jefferson</dc:title>
    <mm:sortName>Jefferson, Blind Lemon</mm:sortName>
    <mm:albumList>
      <rdf:Bag>
        <rdf:li
rdf:resource="http://musicbrainz.org/album/9d78fc3c-09ea-4be7-ba3d-481839c45c07"/>
        <rdf:li
rdf:resource="http://musicbrainz.org/album/9d1982f6-5d1b-4e3b-bf6a-92617e35b01a"/>
        <rdf:li
rdf:resource="http://musicbrainz.org/album/3b4fe7ef-8fd7-4737-a652-db041c0ae558"/>
      </rdf:Bag>
    </mm:albumList>
  </mm:Artist>

  <mm:Artist
rdf:about="http://musicbrainz.org/artist/39c2a93d-9afa-4a22-9bba-c087ab056e1c">
    <dc:title>Jefferson Airplane</dc:title>
    <mm:sortName>Jefferson Airplane</mm:sortName>
    <mm:albumList>
      <rdf:Bag>
        <rdf:li
rdf:resource="http://musicbrainz.org/album/f1928c62-8696-4b4c-bea8-551dc8682c1a"/>
        <rdf:li
rdf:resource="http://musicbrainz.org/album/1795f5d7-024d-4bc6-9fc2-e9b500582309"/>
        <rdf:li
rdf:resource="http://musicbrainz.org/album/00f6a973-6a84-4704-8cef-b0424bc73db7"/>
        <rdf:li
rdf:resource="http://musicbrainz.org/album/d037d75c-a3c7-4e21-89c0-ef6a27060ffe"/>
        <rdf:li
rdf:resource="http://musicbrainz.org/album/a4089c08-8f3b-4a44-ac9b-03829daab5b6"/>
        <rdf:li
rdf:resource="http://musicbrainz.org/album/3e2ce1f4-c01c-4363-a93b-07b8058814d8"/>
        <rdf:li
rdf:resource="http://musicbrainz.org/album/8fcaa436-861d-4f93-a670-9388f12c424a"/>
        <rdf:li
rdf:resource="http://musicbrainz.org/album/7056ed23-a14c-4840-bbf9-8835e3b6c8a5"/>
        <rdf:li
rdf:resource="http://musicbrainz.org/album/86abf559-dec6-4f40-a0bc-b240875aa8e2"/>
        <rdf:li
rdf:resource="http://musicbrainz.org/album/ab3cf2b4-b68c-40d3-84af-f1aaa13bba2e"/>
        <rdf:li
rdf:resource="http://musicbrainz.org/album/653edd70-af03-4935-9832-f518f9560f53"/>
        <rdf:li
rdf:resource="http://musicbrainz.org/album/c4700f76-84e0-4714-9a13-6d87d920f0fc"/>
        <rdf:li
rdf:resource="http://musicbrainz.org/album/59dc60f0-58fd-4ae4-82ce-d7585f3055dc"/>
        <rdf:li
rdf:resource="http://musicbrainz.org/album/b3a40fec-d72a-42b1-92a2-83b6ec788736"/>
        <rdf:li
rdf:resource="http://musicbrainz.org/album/352c8972-f644-442c-a09e-b348b4c9c65d"/>
        <rdf:li
rdf:resource="http://musicbrainz.org/album/c9795844-0c1b-48a9-8322-fa36874af6cb"/>
        <rdf:li
rdf:resource="http://musicbrainz.org/album/7465e82d-b54d-460b-98b5-5fdc79e956a4"/>
        <rdf:li
rdf:resource="http://musicbrainz.org/album/edc0393d-c294-4bcb-a7ee-293d9365824f"/>
        <rdf:li
rdf:resource="http://musicbrainz.org/album/76d22827-b560-413c-9695-29627a1e26ee"/>
        <rdf:li
rdf:resource="http://musicbrainz.org/album/5d78a362-2c47-4e5d-bd2f-fd449c5b5909"/>
        <rdf:li
rdf:resource="http://musicbrainz.org/album/ff0c705b-809b-4396-8b24-872b529f4592"/>
        <rdf:li
rdf:resource="http://musicbrainz.org/album/df0189f5-ca27-4beb-a67c-b0cf151260b1"/>
        <rdf:li
rdf:resource="http://musicbrainz.org/album/408552cb-76e2-44dc-8625-2780b93d326a"/>
        <rdf:li
rdf:resource="http://musicbrainz.org/album/4ff395d0-9857-408a-925c-fd67761ec2d8"/>
        <rdf:li
rdf:resource="http://musicbrainz.org/album/62ffd92d-75a7-42e1-9cb1-382a79a24e0c"/>
        <rdf:li
rdf:resource="http://musicbrainz.org/album/bf025ee9-cd21-42b1-bad6-1ae66bb92a3f"/>
        <rdf:li
rdf:resource="http://musicbrainz.org/album/cb26cf72-d58f-4ddd-a857-33131cb125c0"/>
        <rdf:li
rdf:resource="http://musicbrainz.org/album/8e9a0a54-e363-4c9f-b863-31b63d4693a6"/>
        <rdf:li
rdf:resource="http://musicbrainz.org/album/6294f6e6-a52c-4516-95a0-23ea2837a133"/>
        <rdf:li
rdf:resource="http://musicbrainz.org/album/a4cfdb89-7a4e-4edc-a2a8-664800c14504"/>
        <rdf:li
rdf:resource="http://musicbrainz.org/album/613ee773-34c0-4e24-8683-a4fed2e340a5"/>
      </rdf:Bag>
    </mm:albumList>
  </mm:Artist>

  <mm:Artist
rdf:about="http://musicbrainz.org/artist/21091760-3b04-48ca-9aa4-40ab0eb29f5a">
    <dc:title>Jefferson Airplane - Jefferson Starship
- Starship</dc:title>
    <mm:sortName>Jefferson Airplane - Jefferson
Starship - Starship</mm:sortName>
    <mm:albumList>
      <rdf:Bag>
        <rdf:li
rdf:resource="http://musicbrainz.org/album/a45642dd-62c6-4b94-aca2-53fdaa5597d9"/>
        <rdf:li
rdf:resource="http://musicbrainz.org/album/84bb84cd-7dd3-4d49-a537-8f78f95207de"/>
      </rdf:Bag>
    </mm:albumList>
  </mm:Artist>

  <mm:Artist
rdf:about="http://musicbrainz.org/artist/ffc48cf9-bb16-42d4-b37f-e46a3438312c">
    <dc:title>Jefferson Crocker</dc:title>
    <mm:sortName>Jefferson Crocker</mm:sortName>
    <mm:albumList>
      <rdf:Bag>
        <rdf:li
rdf:resource="http://musicbrainz.org/album/f0e45eed-1bbe-4c77-83cb-3d69537fc7f4"/>
      </rdf:Bag>
    </mm:albumList>
  </mm:Artist>

  <mm:Artist
rdf:about="http://musicbrainz.org/artist/4854429b-66f7-41c0-a89c-030bb7ccf958">
    <dc:title>Jefferson Starship</dc:title>
    <mm:sortName>Jefferson Starship</mm:sortName>
    <mm:albumList>
      <rdf:Bag>
        <rdf:li
rdf:resource="http://musicbrainz.org/album/1e9e813b-01e7-4c03-98c6-32a5ebb7979f"/>
        <rdf:li
rdf:resource="http://musicbrainz.org/album/fd3157b2-7c48-4ca2-80bb-2e1ad0276f2e"/>
        <rdf:li
rdf:resource="http://musicbrainz.org/album/1147b846-55d5-47bf-b7c3-18232d71224d"/>
        <rdf:li
rdf:resource="http://musicbrainz.org/album/60b8106b-2db4-4370-a94d-e6310ba48b74"/>
        <rdf:li
rdf:resource="http://musicbrainz.org/album/71932b1f-63a5-4834-893d-3c936f8abcb5"/>
        <rdf:li
rdf:resource="http://musicbrainz.org/album/39532911-5b97-4623-8145-6c3023976908"/>
        <rdf:li
rdf:resource="http://musicbrainz.org/album/d8214d17-ffd5-4756-bd59-7cb2ad35fe68"/>
      </rdf:Bag>
    </mm:albumList>
  </mm:Artist>

  <mm:Artist
rdf:about="http://musicbrainz.org/artist/1b90728d-a656-41eb-bc98-144336ecf68b">
    <dc:title>LaMarquis Jefferson</dc:title>
    <mm:sortName>LaMarquis Jefferson</mm:sortName>
    <mm:albumList>
      <rdf:Bag>
        <rdf:li
rdf:resource="http://musicbrainz.org/album/c00efcaa-2ba6-45d6-92f7-7e24c2130950"/>
      </rdf:Bag>
    </mm:albumList>
  </mm:Artist>

  <mm:Artist
rdf:about="http://musicbrainz.org/artist/93938558-9a84-4a7f-a15c-6f145100ff5c">
    <dc:title>Marshall Jefferson</dc:title>
    <mm:sortName>Jefferson, Marshall</mm:sortName>
    <mm:albumList>
      <rdf:Bag>
        <rdf:li
rdf:resource="http://musicbrainz.org/album/c20834c3-6e90-482e-98dc-0e566621bec9"/>
      </rdf:Bag>
    </mm:albumList>
  </mm:Artist>

  <mm:Artist
rdf:about="http://musicbrainz.org/artist/42355982-7f15-4200-925b-e6dd9f451776">
    <dc:title>Paul Kantner - Jefferson
Stars</dc:title>
    <mm:sortName>Paul Kantner - Jefferson
Stars</mm:sortName>
    <mm:albumList>
      <rdf:Bag>
        <rdf:li
rdf:resource="http://musicbrainz.org/album/bfeb8e16-b8be-4a6d-9b6b-adb323f9123c"/>
      </rdf:Bag>
    </mm:albumList>
  </mm:Artist>

</rdf:RDF>

******* End






__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com


From karl@waclawek.net  Fri Jun  7 06:57:02 2002
From: karl@waclawek.net (Karl Waclawek)
Date: Fri Jun  7 05:57:02 2002
Subject: [Expat-discuss] Encoding problems on Mac OS X
References: <20020607064443.74906.qmail@web14304.mail.yahoo.com>
Message-ID: <001101c20e22$b6f9b410$9e539696@citkwaclaww2k>

> Here is a full file where I am parsing for characters
> within the <dc:title> tag.  (Here they are music
> artist names).  When these characters are printed
> through the CharacterDataHandler (via printf's), I can
> make out some of the titles, but most are garbled.

Works fine for me on Expat 1.95.3.
Maybe a platform issue - but I am not familiar with Expat on the Mac.

Btw, did you compile Expat for UTF-8 or UTF-16 output?

Karl



From fdrake@acm.org  Fri Jun  7 10:35:08 2002
From: fdrake@acm.org (Fred L. Drake, Jr.)
Date: Fri Jun  7 09:35:08 2002
Subject: [Expat-discuss] How to handle predefined entities?
In-Reply-To: <OFF0D79FFA.C9C74AB1-ON85256BD0.004C3F43@cya.com>
References: <OFF0D79FFA.C9C74AB1-ON85256BD0.004C3F43@cya.com>
Message-ID: <15616.53904.245797.13887@grendel.zope.com>

YTian@cya.com writes:
 > In my xml file, there is an element looks like:
 >       <eleOne>id &lt; 123</eleOne>
 > I expected to get "id < 123", but the result was "id ". Seems expat
 > couldn't go through the &*; .
 > So, which handler should I use? Do you have any experience about this?

You should expect to get three calls to your character data handler;
these will provide the chunks "id ", "<", and " 123", in that order.
Your character data handler should simply accumulate data, and then
you process it in the element-end handler.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at acm.org>
PythonLabs at Zope Corporation


From gp@familiehaase.de  Sun Jun  9 07:34:02 2002
From: gp@familiehaase.de (Gerrit P. Haase)
Date: Sun Jun  9 06:34:02 2002
Subject: [Expat-discuss] ITP: expat-1.95.3 for Cygwin
Message-ID: <3971854641.20020609153357@familiehaase.de>

Hallo,

I intent to provide Expat as a new Cygwin package, though
with the released Expat version 1.95.3 it is a mess.
The provided libtool is version 1.4.  This is too old to
build DLL's on Cygwin.

We have a special version on Cygwin, that works, but it
should also work with libtool-1.4.2 which is the latest
release, though I used the libtool-devel that comes with
the Cygwin net release.

What is the problem with libtool 1.4.2?
Why is libtool 1.4 used?

The problem with installing when building outside the
sourcedir is still not completly resolved.  I sent
some patches which were *partially* applied?
So still expat.h isn't found during install if building
outside the sourcedir (also the manfile).

Also I wonder what is this in configure.in:

define([expat_version], ifdef([__gnu__],
                              [esyscmd(conftools/get-version.sh lib/expat.h)],
                              [1.95.x]))

there is no get-version.sh in the package included?


I relibtoolized with the Cygwin devel version.

I have packaged tarballs ready for use/review/upload.

The source includes a buildscript and the patch (5k),
just unpack it and run './expat-1.95.3-1.sh all'

This results in two tarballs, one with the source
and script and patch, one with the binaries, ready
to install them from / to prefix=/usr.

http://koeln.convey.de/cywgin/expat/expat-1.95.3-1-src.tar.bz2
http://koeln.convey.de/cywgin/expat/expat-1.95.3-1.tar.bz2
http://koeln.convey.de/cywgin/expat/setup.hint

For cygwin-apps, the setup.hint:
# Expat XML Parser
category: Doc Libs Text Devel Interpreters
requires: cygwin
sdesc: "XML parser library written in C"
ldesc: "Expat is an XML parser library written in C. 
It is a stream-oriented parser in which an application 
registers handlers for things the parser might find in 
the XML document (like start tags).
More details are available at http://www.libexpat.org/"


Gerrit
-- 
=^..^=



From freeweb@nyckelpiga.de  Mon Jun 10 05:25:02 2002
From: freeweb@nyckelpiga.de (Gerrit P. Haase)
Date: Mon Jun 10 04:25:02 2002
Subject: [Expat-discuss] Re: ITP: expat-1.95.3 for Cygwin
Message-ID: <142273620164.20020610132245@familiehaase.de>

Gerrit schrieb:

> Hallo,

> I intent to provide Expat as a new Cygwin package, though
> with the released Expat version 1.95.3 it is a mess.
> The provided libtool is version 1.4.  This is too old to
> build DLL's on Cygwin.

> We have a special version on Cygwin, that works, but it
> should also work with libtool-1.4.2 which is the latest
> release, though I used the libtool-devel that comes with
> the Cygwin net release.

> What is the problem with libtool 1.4.2?
> Why is libtool 1.4 used?

> The problem with installing when building outside the
> sourcedir is still not completly resolved.  I sent
> some patches which were *partially* applied?
> So still expat.h isn't found during install if building
> outside the sourcedir (also the manfile).

> Also I wonder what is this in configure.in:

> define([expat_version], ifdef([__gnu__],
>                               [esyscmd(conftools/get-version.sh lib/expat.h)],
>                               [1.95.x]))

> there is no get-version.sh in the package included?


I have also my patch online for review.
Any chance to include this tweaks so building outside the sourcedir
would work?

http://koeln.convey.de/cywgin/expat/expat-1.95.3-1.patch


> http://koeln.convey.de/cywgin/expat/expat-1.95.3-1-src.tar.bz2
> http://koeln.convey.de/cywgin/expat/expat-1.95.3-1.tar.bz2
> http://koeln.convey.de/cywgin/expat/setup.hint

-- 
=^..^=



From fdrake@acm.org  Mon Jun 10 10:34:04 2002
From: fdrake@acm.org (Fred L. Drake, Jr.)
Date: Mon Jun 10 09:34:04 2002
Subject: [Expat-discuss] Encoding problems on Mac OS X
In-Reply-To: <20020606191318.81341.qmail@web14305.mail.yahoo.com>
References: <20020606191318.81341.qmail@web14305.mail.yahoo.com>
Message-ID: <15620.54495.198843.226561@grendel.zope.com>

Naveen Viswanatha writes:
 > I am parsing xml encoded in ISO-8859-1 charset on Mac
 > OS 10.1 using expat v1.95.1 and v1.95.3.  On some XML
 > files everything works ok, however, on others, the
 > CharacterDataHandler seems to parse garbage (wierd
 > unrecognizable characters). 

Is the encoding properly specified in the XML declaration at the top
of the file?

Do you realize that the text passed to the character data handler will
always be encoded in UTF-8 in the default build of Expat, regardless
of the input encoding?


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at acm.org>
PythonLabs at Zope Corporation


From William.Bug@drexel.edu  Mon Jun 10 11:47:05 2002
From: William.Bug@drexel.edu (Bill Bug)
Date: Mon Jun 10 10:47:05 2002
Subject: [Expat-discuss] Problems with test suite for eXpat source installation - Newbie
 question
Message-ID: <FCC0FF3F-7C97-11D6-9BF4-0003931DC29E@drexel.edu>

Hi All,

Many thanks to all those who have contributed to the eXpat code base.  I 
can't wait to get to use it!

Right now, I'm having trouble confirming my eXpat build installed 
correctly.

I'd like to use the 'tests' included with the eXpat source distribution.

I've installed the latest version of the CHECK unit testing library.  
I'm running under Mac OS X v10.1.5.

Am I correct in assuming I can compile and execute the tests by running 
'make check' from the eXpat distro base path, after first having run 
through the './configure - make - make install' process?

Upon running 'make check', I receive the following error messages:
	tests/runtests
	tests/runtests: error: /usr/local/src/expat-1.95.3/tests
	/usr/local/src/expat-1.95.3/tests/.libs/runtests does not exist
	This script is just a wrapper for runtests.
	See the libtool documentation for more information.
	make: *** [check] Error 1

My knowledge of make is limited & my knowledge of libtool is nil, so I 
could be missing something very obvious.  The error as given implies to 
me there is some library file the runtest object code needs to link to, 
yet cannot find at the specified path.

I'd really appreciate any help folks can offer on this issue.  I have 
quite a few packages I need to install, and eXpat is an important XML 
parser framework used by several of these other packages.  I want to 
make certain the eXpat installation gets done correctly.

Has anyone used the code in the 'tests' directory to successfully check 
their eXpat binary installation?

Thanks ahead of time for your help.

Cheers,
Bill Bug

Bill Bug
Senior Analyst/Ontological Engineer
Computer Vision Laboratory for Vertebrate Brain Mapping
MCP/Hahnemann University
2900 Queen Lane
Philadelphia, PA  19129
William.Bug@drexel.edu



From karl@waclawek.net  Tue Jun 11 14:15:06 2002
From: karl@waclawek.net (Karl Waclawek)
Date: Tue Jun 11 13:15:06 2002
Subject: [Expat-discuss] Discussion: InternalEntityRefHandler
Message-ID: <001401c21184$9200b3b0$9e539696@citkwaclaww2k>

We plan to add an InternalEntityRefHandler for release 1.95.4.
Among other reasons, such a handler would make Expat more fully
SAX compliant.

If you have any ideas about it, please say so.

Here is what we have so far:

An internal entity reference handler should probably
do two things:

1) pass name, entity value and entity type (PE or GE)
2) allow the application to return a value that
   indicates if the entity should be expanded or not

The second one is necessary, since - contrary
to the external entity ref handler - the entity value
is already determined, whereas in the external
entity ref handler it is the handler that "creates"
that data, so by doing nothing it achieves the
effect of ignoring the entity automatically.

Here are a few problems that need to be resolved:

1) There is possible interference with the SetDefaultHandler
and SetDefaulthandlerExpand functions. The former will
turn off expansion of internal general entities.
However, this could now also be done with the InternalEntityRefHandler.
So, what happens when expansion is turned off?

Personally, I don't like to have such a feature as a side-effect
of setting a handler. My vote would go for having only
one function - SetDefaultHandler - *and* removing the influence
it has on internal entity expansion completely.
The InternalEntityRefHandler could deal with that on a per-call basis.

2) How does that work with the skippedEntityHandler if
the InternalEntityRefHandler returns with a value indicating
that the entity reference should be ignored?

To be consistent with the ExternalEntityRefhandler, it should
 be the application's job to deal with it, since this handler
has no way of telling the parser that the external entity has been skipped.
In other words - we should not delegate the skipped entity notification
back to Expat, if we are the ones generating the event in the first place.

The skippedEntityHandler should only be invoked when the parser
comes across an undefined entity and this is *not* an error
(which can only happen for non-validating parsers).

Comments welcome,

Karl



From rolf@pointsman.de  Wed Jun 12 20:45:03 2002
From: rolf@pointsman.de (rolf@pointsman.de)
Date: Wed Jun 12 19:45:03 2002
Subject: [Expat-discuss] Discussion: InternalEntityRefHandler
In-Reply-To: <001401c21184$9200b3b0$9e539696@citkwaclaww2k>
Message-ID: <200206130237.EAA17190@pointsman.pointsman.de>

(I'm a bit shy to answer, because I mostly have some minor objections,
but no clear counter proposal. The reason to follow up is the hope,
that some of my doubts and questions may help to keep the discussion
roll.)

On 11 Jun, Karl Waclawek wrote:
> We plan to add an InternalEntityRefHandler for release 1.95.4.
> Among other reasons, such a handler would make Expat more fully
> SAX compliant.

I think this would be a valuable addition to the expat API. For
example, to build some XML editor application, that aims to preserve
the internal entities of the document throu the editing with expat as
parser is really hard - it may not impossible, using
XML_EntityDeclHandler() and listen at the defaultHandler, plus a lot
of fuzz, but it's much to hard. An InternalEntityRefHandler could be a
lot of help here.

> Here is what we have so far:
> 
> An internal entity reference handler should probably
> do two things:
> 
> 1) pass name, entity value and entity type (PE or GE)

I guess, with entity value you mean "replacement text" (in the sense
of the first paragraph of XML rec 4.5), since even the
XML_EntityDeclHandler() gives that, right? With an
XML_EntityDeclHandler(), that stores the entity name/value pairs in a
lookup table and the name passed, it isn't strictly necessary also to
pass the value, but it's fine with me, if expat does this work as a
service.

> 2) allow the application to return a value that
>    indicates if the entity should be expanded or not

I've mixed emotions about that. What exactly should this return value
control? For a GE, if the return value is true, the replacement text
is reported again throu the characterDataHandler? There may be sense
in this, but what's the sense in returning false for a PE? Can't
imagin a sensible reason, does anybody else?

> The second one is necessary, since - contrary
> to the external entity ref handler - the entity value
> is already determined, whereas in the external
> entity ref handler it is the handler that "creates"
> that data, so by doing nothing it achieves the
> effect of ignoring the entity automatically.

Ignoring an internal entity completely may probably not the best of
all ideas. The question is: are there reasons (and may it be
convenience) to report the entity value twice (first throu the
InternalEntityRefHandler and, if that has returned true, throu the
characterDataHandler)? 

I think an InternalEntityRefHandler could simply return void. Just see
the InternalEntityRefHandler as a variant of the
characterDataHandler. The document data, reported throu the
InternalEntityRefHandler is special only in that it has two different
forms: the 'reference form' of the entity name and the 'expanded form'
replacement text. Both forms are reported throu the planned
InternalEntityRefHandler, so I don't see the point of reporting the
replacement text again (depending of the return value of the
InternalEntityRefHandler).

> Here are a few problems that need to be resolved:
> 
> 1) There is possible interference with the SetDefaultHandler
> and SetDefaulthandlerExpand functions. The former will
> turn off expansion of internal general entities.
> However, this could now also be done with the InternalEntityRefHandler.
> So, what happens when expansion is turned off?

Without InternalEntityRefHandler set, let it, as it is (it's not
perfect, I agree). That warrantees backward compatibility (I'm
personllay not very keen about that in this area, but some may be).

If the proposed InternalEntityRefHandler is set, it depends on the
answer of the question what InternalEntityRefHandler should return, if
ever. With a void InternalEntityRefHandler, I would say, doesn't
report either entity name nor replacement text, regardless if
SetDefaultHandler or SetDefaulthandlerExpand is set (because there is
a handler for this data, so why should it be reported also throu the
default handler, which reports (in theory, counter example is some DTD
data) only all data, for which is no handler registered). A bit
clumsy, yes, but it doesn't feel better, if InternalEntityRefHandler
returns a value. The reason is:

> Personally, I don't like to have such a feature as a side-effect
> of setting a handler.

I second this. 
 
 My vote would go for having only
> one function - SetDefaultHandler - *and* removing the influence
> it has on internal entity expansion completely.
> The InternalEntityRefHandler could deal with that on a per-call basis.

Yes.

> 2) How does that work with the skippedEntityHandler if
> the InternalEntityRefHandler returns with a value indicating
> that the entity reference should be ignored?

Let me first ask the question, what the InternalEntityRefHandler
should return for an entity, that also triggers the
skippedEntityHandler? Entity value could only be NULL, in this case,
yes? There are some ways, and I'm not completely sure. I would say
just don't call the InternalEntityRefHandler at all, for undeclared
entities (and this isn't an error), if a skippedEntityHandler is
set. Call it with entity value NULL, if skippedEntityHandler isn't
set. (Well, this way an InternalEntityRefHandler could supersede the
skippedEntityHandler..).

rolf




From karl@waclawek.net  Wed Jun 12 22:19:01 2002
From: karl@waclawek.net (Karl Waclawek)
Date: Wed Jun 12 21:19:01 2002
Subject: [Expat-discuss] Discussion: InternalEntityRefHandler
References: <200206130237.EAA17190@pointsman.pointsman.de>
Message-ID: <003301c21293$c8049070$0207a8c0@karl>

> I think this would be a valuable addition to the expat API. For
> example, to build some XML editor application, that aims to preserve
> the internal entities of the document throu the editing with expat as
> parser is really hard - it may not impossible, using
> XML_EntityDeclHandler() and listen at the defaultHandler, plus a lot
> of fuzz, but it's much to hard. An InternalEntityRefHandler could be a
> lot of help here.
> 
> > Here is what we have so far:
> > 
> > An internal entity reference handler should probably
> > do two things:
> > 
> > 1) pass name, entity value and entity type (PE or GE)
> 
> I guess, with entity value you mean "replacement text" (in the sense
> of the first paragraph of XML rec 4.5), since even the
> XML_EntityDeclHandler() gives that, right? With an
> XML_EntityDeclHandler(), that stores the entity name/value pairs in a
> lookup table and the name passed, it isn't strictly necessary also to
> pass the value, but it's fine with me, if expat does this work as a
> service.

Yes, I mean replacement text.
And if the information is already there, it may help reduce some overhead,
if you want to examine the entity before making a decision whether it should
be expanded or not.
 
> > 2) allow the application to return a value that
> >    indicates if the entity should be expanded or not
> 
> I've mixed emotions about that. What exactly should this return value
> control? For a GE, if the return value is true, the replacement text
> is reported again throu the characterDataHandler? There may be sense
> in this, but what's the sense in returning false for a PE? Can't
> imagin a sensible reason, does anybody else?

Good points, but it isn't the character handler, it's potentially all content
handlers. For GEs there have been requests to suppress expansion of certain
types of entities, e.g. predefined ones. For PEs - I don't know.
However, I am also missing a good argument for *not* wanting
to ever ignore/suppress them.
 
> > The second one is necessary, since - contrary
> > to the external entity ref handler - the entity value
> > is already determined, whereas in the external
> > entity ref handler it is the handler that "creates"
> > that data, so by doing nothing it achieves the
> > effect of ignoring the entity automatically.
> 
> Ignoring an internal entity completely may probably not the best of
> all ideas. The question is: are there reasons (and may it be
> convenience) to report the entity value twice (first throu the
> InternalEntityRefHandler and, if that has returned true, throu the
> characterDataHandler)? 

If we return "False" the character handler simply returns the unexpanded
reference, so that makes sense, but if we return "True", then we report
it twice. However, the parser will not just report it through the character
handler, it will parse it like any other XML input - generating various callbacks.
So, the parser is still doing something we can't do (easily).
So, we really are not reporting it twice the same way.
 
> I think an InternalEntityRefHandler could simply return void. Just see
> the InternalEntityRefHandler as a variant of the
> characterDataHandler. The document data, reported throu the
> InternalEntityRefHandler is special only in that it has two different
> forms: the 'reference form' of the entity name and the 'expanded form'
> replacement text. Both forms are reported throu the planned
> InternalEntityRefHandler, so I don't see the point of reporting the
> replacement text again (depending of the return value of the
> InternalEntityRefHandler).

See above.
 
> > Here are a few problems that need to be resolved:
> > 
> > 1) There is possible interference with the SetDefaultHandler
> > and SetDefaulthandlerExpand functions. The former will
> > turn off expansion of internal general entities.
> > However, this could now also be done with the InternalEntityRefHandler.
> > So, what happens when expansion is turned off?
> 
> Without InternalEntityRefHandler set, let it, as it is (it's not
> perfect, I agree). That warrantees backward compatibility (I'm
> personllay not very keen about that in this area, but some may be).

Even with the InternalEntityRefHandler we might leave both in,
but declare one of them as deprecated (and possibly make them
behave the same - but that might break some apps).
 
> If the proposed InternalEntityRefHandler is set, it depends on the
> answer of the question what InternalEntityRefHandler should return, if
> ever. With a void InternalEntityRefHandler, I would say, doesn't
> report either entity name nor replacement text, regardless if
> SetDefaultHandler or SetDefaulthandlerExpand is set (because there is
> a handler for this data, so why should it be reported also throu the
> default handler, which reports (in theory, counter example is some DTD
> data) only all data, for which is no handler registered). A bit
> clumsy, yes, but it doesn't feel better, if InternalEntityRefHandler
> returns a value. The reason is:

I am not sure I understand exactly what you mean?
 
> Let me first ask the question, what the InternalEntityRefHandler
> should return for an entity, that also triggers the
> skippedEntityHandler? Entity value could only be NULL, in this case,
> yes? There are some ways, and I'm not completely sure. I would say
> just don't call the InternalEntityRefHandler at all, for undeclared
> entities (and this isn't an error), if a skippedEntityHandler is
> set.

Yes, that would be what I had in mind.

> Call it with entity value NULL, if skippedEntityHandler isn't
> set. (Well, this way an InternalEntityRefHandler could supersede the
> skippedEntityHandler..).

That's an interesting idea - only have an InternalEntityRefHandler,
and set entityValue = NULL if skipped (when not an error, of course).

Anyway, you have raised doubts in my mind if it makes sense to
report the entity value at all. What does it mean examining it?
Isn't that what the parser does?

Karl



From rolf@pointsman.de  Thu Jun 13 11:16:07 2002
From: rolf@pointsman.de (rolf@pointsman.de)
Date: Thu Jun 13 10:16:07 2002
Subject: [Expat-discuss] Discussion: InternalEntityRefHandler
In-Reply-To: <200206131016.MAA00546@titan.pointsman.de>
Message-ID: <200206131708.TAA18982@pointsman.pointsman.de>


>> > 2) allow the application to return a value that
>> >    indicates if the entity should be expanded or not
>>=20
>> I've mixed emotions about that. What exactly should this return value
>> control? For a GE, if the return value is true, the replacement text
>> is reported again throu the characterDataHandler? There may be sense
>> in this, but what's the sense in returning false for a PE? Can't
>> imagin a sensible reason, does anybody else?
>=20
> Good points, but it isn't the character handler, it's potentially all c=
ontent
> handlers. For GEs there have been requests to suppress expansion of cer=
tain
> types of entities, e.g. predefined ones. For PEs - I don't know.
> However, I am also missing a good argument for *not* wanting
> to ever ignore/suppress them.

Don't see, how any handler beside the characterDataHandler could be
able to handle not expanded entities in a sensible way.

Maybe a few examples could make things a bit clearer. Consider
a document like this:

<?xml version=3D"1.0" encoding=3D"UTF-8" ?>
<!DOCTYPE foo SYSTEM "1.ent">
<foo/>


with 1.ent:

<!-- 1 -->
<!ENTITY % draft 'INCLUDE' >
<![%draft;[
<!ELEMENT book (comments*, title, body, supplements?)>
]]>

<!-- 2 -->
<!ENTITY % someElement  "<!ELEMENT element ANY>">
%someElement;

<!-- 3 -->
<!ENTITY % fooContent "EMPTY" >
<!ELEMENT foo %fooContent;>

<!-- 4 -->
<!ENTITY % someBarChilds "boo,baz">
<!ELEMENT bar (foe,%someBarChilds;,bom)>

<!-- 5 -->
<!ENTITY % pub    "&#xc9;ditions Gallimard" >
<!ENTITY   rights "All rights reserved" >
<!ENTITY   book   "La Peste: Albert Camus, &#xA9; 1947 %pub; &rights;" >


What should happen in examples 1 if the
InternalEntityRefHandler return 0? Skip the hole conditional section??
Completely skipping the PE as well as leaving the PE in unexpanded
form results in not wellformed XML, in this case.

Example 2 is probably the least critical. If InternalEntityRefHandler
returns 0, the unexpanded PE goes throu defaultHandler?

In Example 3 and 4 I guess the InternalEntityRefHandler must be called
befor the elementDeclHandler. If the InternalEntityRefHandler returns
0, what should the elementDeclHandler return: how does the
%fooContent; fit into a XML_Content, same Question for the bar
content?

Even example 5 doesn't looks like a sensible case. Sure,
InternalEntityRefHandler should be called befor the
EntityDeclHandler. If it returns 0, the replacement text reported
throu the EntityDeclHandler would be "La Peste: Albert Camus, =A9 1947
%pub; &rights;"? But the XML rec says clearly in 4.5: "The replacement
text is the content of the entity, after replacement of character
references and parameter-entity references."

Still, this optional not expanding of PE's feels to me like a can of
worms. But OK, do it, I have no problem to let the
InternalEntityRefHandler return always 1 for PE's. There may be
valuable use cases for this, that I just don't see at the moment.

> If we return "False" the character handler simply returns the unexpande=
d
> reference, so that makes sense, but if we return "True", then we report
> it twice. However, the parser will not just report it through the chara=
cter
> handler, it will parse it like any other XML input - generating various=
 callbacks.
> So, the parser is still doing something we can't do (easily).
> So, we really are not reporting it twice the same way.

Yes. You're right.

>> > 1) There is possible interference with the SetDefaultHandler
>> > and SetDefaulthandlerExpand functions. The former will
>> > turn off expansion of internal general entities.
>> > However, this could now also be done with the InternalEntityRefHandl=
er.
>> > So, what happens when expansion is turned off?
> [..]
> Even with the InternalEntityRefHandler we might leave both in,

Yes. And without InternalEntityRefHandler set, let them behave as
now. Easiest way for backward compatibility.

> but declare one of them as deprecated (and possibly make them
> behave the same - but that might break some apps).

Yes, get rid of one of them, on the long run. But make them only
behave the same way, if InternalEntityRefHandler is set.=20


Call InternalEntityRefHandler
>> with entity value NULL, if skippedEntityHandler isn't
>> set. (Well, this way an InternalEntityRefHandler could supersede the
>> skippedEntityHandler..).
>=20
> That's an interesting idea - only have an InternalEntityRefHandler,
> and set entityValue =3D NULL if skipped (when not an error, of course).

Suddenly, I feel happy about that the skippedEntityHandler hasn't made
it into 1.95.3. But I'm not perfect sure. Let's hear other opinions.

> Anyway, you have raised doubts in my mind if it makes sense to
> report the entity value at all. What does it mean examining it?
> Isn't that what the parser does?

Depends. For sure, the parser will not be able to examining the
semantic of the replacement text, this could only be done by the
application. But the application could always manage his own entity
value lookup table (using entityDeclHandler etc.), if needed.  There
may be a minimal speed penalty, if the InternalEntityRefHandler
returns 0 (do not expand), because of the in this case 'unnecessary'
entity value lookup, but this may only be measurable in extrem
cases. On the other hand it would be a nice service, to get the entity
value without managing an own lookup table. Could live with both.

rolf




From karl@waclawek.net  Thu Jun 13 11:26:08 2002
From: karl@waclawek.net (Karl Waclawek)
Date: Thu Jun 13 10:26:08 2002
Subject: [Expat-discuss] Discussion: InternalEntityRefHandler
References: <200206130237.EAA17190@pointsman.pointsman.de> <003301c21293$c8049070$0207a8c0@karl>
Message-ID: <001201c212ff$485844e0$9e539696@citkwaclaww2k>

> That's an interesting idea - only have an InternalEntityRefHandler,
> and set entityValue = NULL if skipped (when not an error, of course).

Correcting myself:
We don't know if it is an internal entity if we have to skip,
since there is no declaration! So this  doesn't make much sense.

 > Anyway, you have raised doubts in my mind if it makes sense to
> report the entity value at all. What does it mean examining it?
> Isn't that what the parser does?

In addition, I just realized that in order to be SAX compliant,
I would need a StartInternalEntityHandler and an EndInternalEntityHandler.
In some cases this doesn't make sense, i.e. for the predefined entities,
in other cases it should be possible to do.

The SAX specs state that 
  a.. general entities within attribute values 
  b.. parameter entities within declarations 
are not reported.

Food for thought.

Karl




From karl@waclawek.net  Thu Jun 13 12:08:04 2002
From: karl@waclawek.net (Karl Waclawek)
Date: Thu Jun 13 11:08:04 2002
Subject: [Expat-discuss] Discussion: InternalEntityRefHandler
References: <200206131708.TAA18982@pointsman.pointsman.de>
Message-ID: <002901c21305$23f5f100$9e539696@citkwaclaww2k>

> >> > 2) allow the application to return a value that
> >> >    indicates if the entity should be expanded or not
> >> I've mixed emotions about that. What exactly should this return value
> >> control? For a GE, if the return value is true, the replacement text
> >> is reported again throu the characterDataHandler? There may be sense
> >> in this, but what's the sense in returning false for a PE? Can't
> >> imagin a sensible reason, does anybody else?
> >
> > Good points, but it isn't the character handler, it's potentially all content
> > handlers. For GEs there have been requests to suppress expansion of certain
> > types of entities, e.g. predefined ones. For PEs - I don't know.
> > However, I am also missing a good argument for *not* wanting
> > to ever ignore/suppress them.
>
> Don't see, how any handler beside the characterDataHandler could be
> able to handle not expanded entities in a sensible way.

Well, you said "... the replacement text is reported again through
the character data handler". I understood this as meaning: when expanded,
since otherwise - IMO - just the reference itself should be reported as
character data, but not the replacement text - that one is ignored.
This applies to a GE. For a PE nothing will be reported, unless
the default handler is set.

> Maybe a few examples could make things a bit clearer. Consider
> a document like this:
>
> <?xml version="1.0" encoding="UTF-8" ?>
> <!DOCTYPE foo SYSTEM "1.ent">
> <foo/>
>
>
> with 1.ent:
>
> <!-- 1 -->
> <!ENTITY % draft 'INCLUDE' >
> <![%draft;[
> <!ELEMENT book (comments*, title, body, supplements?)>
> ]]>
>
> <!-- 2 -->
> <!ENTITY % someElement  "<!ELEMENT element ANY>">
> %someElement;
>
> <!-- 3 -->
> <!ENTITY % fooContent "EMPTY" >
> <!ELEMENT foo %fooContent;>
>
> <!-- 4 -->
> <!ENTITY % someBarChilds "boo,baz">
> <!ELEMENT bar (foe,%someBarChilds;,bom)>
>
> <!-- 5 -->
> <!ENTITY % pub    "&#xc9;ditions Gallimard" >
> <!ENTITY   rights "All rights reserved" >
> <!ENTITY   book   "La Peste: Albert Camus, &#xA9; 1947 %pub; &rights;" >
>
>
> What should happen in examples 1 if the
> InternalEntityRefHandler return 0? Skip the hole conditional section??
> Completely skipping the PE as well as leaving the PE in unexpanded
> form results in not wellformed XML, in this case.

I would say that this is simply a risk one has to take.
I am not sure that there is a skipping algorithm that will always
preserve wellformedness. I would say: returning 0 means
"skip the PE" no matter what the consequences.

> Example 2 is probably the least critical. If InternalEntityRefHandler
> returns 0, the unexpanded PE goes throu defaultHandler?

Yes.

> In Example 3 and 4 I guess the InternalEntityRefHandler must be called
> befor the elementDeclHandler.

Yes.

> If the InternalEntityRefHandler returns
> 0, what should the elementDeclHandler return: how does the
> %fooContent; fit into a XML_Content, same Question for the bar
> content?

This will generate a WF error, I would assume.
As above - IMO a skipped PE amounts to "nothing".

> Even example 5 doesn't looks like a sensible case. Sure,
> InternalEntityRefHandler should be called befor the
> EntityDeclHandler. If it returns 0, the replacement text reported
> throu the EntityDeclHandler would be "La Peste: Albert Camus, =A9 1947
> %pub; &rights;"? But the XML rec says clearly in 4.5: "The replacement
> text is the content of the entity, after replacement of character
> references and parameter-entity references."

I don't think the InternalEntityRefhandler should concern itself with
character references at all, since they are not entities.
About the other two entites: &rights; is a GE and not recogized here,
so it won't be reported as GE and become part of the stored entity value.
%pub; is a PE, and if skipped, will simply be replaced with "nothing".
Therefore, we can only skip %pub; and the literal entity value
(not the replacement text!) will be "La Peste: Albert Camus, © 1947 &rights;"
Note: the spec says in Appendix D:
...
the XML processor will recognize the character references when it parses
the entity declaration, and resolve them before storing the following
string as the value of the entity
...

> Still, this optional not expanding of PE's feels to me like a can of
> worms. But OK, do it, I have no problem to let the
> InternalEntityRefHandler return always 1 for PE's. There may be
> valuable use cases for this, that I just don't see at the moment.

If one could alter the replacement text...

> >> > 1) There is possible interference with the SetDefaultHandler
> >> > and SetDefaulthandlerExpand functions. The former will
> >> > turn off expansion of internal general entities.
> >> > However, this could now also be done with the InternalEntityRefHandl=
> er.
> >> > So, what happens when expansion is turned off?
> > [..]
> > Even with the InternalEntityRefHandler we might leave both in,
>
> Yes. And without InternalEntityRefHandler set, let them behave as
> now. Easiest way for backward compatibility.

Yes, I just wanted to get rid of the extra data member, but I see
that could break some apps.

> > but declare one of them as deprecated (and possibly make them
> > behave the same - but that might break some apps).
>
> Yes, get rid of one of them, on the long run. But make them only
> behave the same way, if InternalEntityRefHandler is set.

Sounds reasonable.

> Call InternalEntityRefHandler
> >> with entity value NULL, if skippedEntityHandler isn't
> >> set. (Well, this way an InternalEntityRefHandler could supersede the
> >> skippedEntityHandler..).
> >
> > That's an interesting idea - only have an InternalEntityRefHandler,
> > and set entityValue = NULL if skipped (when not an error, of course).
>
> Suddenly, I feel happy about that the skippedEntityHandler hasn't made
> it into 1.95.3. But I'm not perfect sure. Let's hear other opinions.

Check my other message - maybe not such a good idea.

> > Anyway, you have raised doubts in my mind if it makes sense to
> > report the entity value at all. What does it mean examining it?
> > Isn't that what the parser does?
>
> Depends. For sure, the parser will not be able to examining the
> semantic of the replacement text, this could only be done by the
> application. But the application could always manage his own entity
> value lookup table (using entityDeclHandler etc.), if needed.  There
> may be a minimal speed penalty, if the InternalEntityRefHandler
> returns 0 (do not expand), because of the in this case 'unnecessary'
> entity value lookup, but this may only be measurable in extrem
> cases. On the other hand it would be a nice service, to get the entity
> value without managing an own lookup table. Could live with both.

I general, my thinking is: if the info is there, and it is no effort
to provide it, then why not? I am waiting for a good argument against it.

Karl



From michael.bain@polycom.com  Fri Jun 14 16:19:01 2002
From: michael.bain@polycom.com (Bain, Michael)
Date: Fri Jun 14 15:19:01 2002
Subject: [Expat-discuss] Extra character inserted in CharacterData Handler?
Message-ID: <20020614221802.GC22038@polycom.com>

---------------------- multipart/mixed attachment
Hi expaters,

I'm having a problem where this xml document:

<SomeTag>
	<Text>
· some bulleted point
	</Text>
</SomeTag>

gets parsed into this output:


<SomeTag>
 	<Text>
 · some bulleted point 
	</Text>
 
</SomeTag>

as you can see I get the extra  added after the bulleted point.

I've seen this behavior in both expat-1.95.2 and expat-1.95.3 on Linux
2.2.19 (x86) as well as in vxWorks (Tornado 2.0.1 for ARM). I'm about to
try and wade into the source myself, but I thought I might ask you folks
first, just in case I'm missing something obvious.

I've attached a tarball with the xml document, output, example parser
and Makefile. (the parser's pretty dumb and ugly, I'll apologise for
that now. It does show the bug though) if the list strips attachments,
I've also posted the tarball here: 
http://macboy.homeip.net/~mike/PLCM/expatCharError.tar.gz

Thanks.

Mike

-- 
Michael Bain, s/w Developer, Polycom Canada Ltd ~ 604-697-9329  

"Don't anthropomorphize computers, they hate that."


---------------------- multipart/mixed attachment
A non-text attachment was scrubbed...
Name: expatCharError.tar.gz
Type: application/x-tar-gz
Size: 1030 bytes
Desc: not available
Url : http://mail.libexpat.org/pipermail-21/expat-discuss/attachments/20020614/f7066615/expatCharError.tar.bin

---------------------- multipart/mixed attachment--


From karl@waclawek.net  Fri Jun 14 18:08:18 2002
From: karl@waclawek.net (Karl Waclawek)
Date: Fri Jun 14 17:08:18 2002
Subject: [Expat-discuss] Extra character inserted in CharacterData Handler?
References: <20020614221802.GC22038@polycom.com>
Message-ID: <001601c21403$602c0430$0207a8c0@karl>


> Hi expaters,
>
> I'm having a problem where this xml document:
>
> <SomeTag>
> <Text>
> =B7 some bulleted point
> </Text>
> </SomeTag>
>
> gets parsed into this output:
>
>
> <SomeTag>
>   <Text>
>  =C2=B7 some bulleted point
> </Text>
>
> </SomeTag>
>
> as you can see I get the extra =C2 added after the bulleted point.
>
> I've seen this behavior in both expat-1.95.2 and expat-1.95.3 on Linux
> 2.2.19 (x86) as well as in vxWorks (Tornado 2.0.1 for ARM). I'm about t=
o
> try and wade into the source myself, but I thought I might ask you folk=
s
> first, just in case I'm missing something obvious.
>
> I've attached a tarball with the xml document, output, example parser
> and Makefile. (the parser's pretty dumb and ugly, I'll apologise for
> that now. It does show the bug though) if the list strips attachments,
> I've also posted the tarball here:
> http://macboy.homeip.net/~mike/PLCM/expatCharError.tar.gz
>

The "." character in your file - 0xB7 - is invalid UTF-8.
Maybe it is valid ISO-8859-1?
In that case you must add an XML declaration.

Actually, 1.95.3 should reject it (and it does so on my system).

Karl



From karl@waclawek.net  Fri Jun 14 20:32:01 2002
From: karl@waclawek.net (Karl Waclawek)
Date: Fri Jun 14 19:32:01 2002
Subject: Fw: [Expat-discuss] Extra character inserted in CharacterData Handler?
Message-ID: <003e01c21417$5bbdbd80$0207a8c0@karl>

> 
> The "." character in your file - 0xB7 - is invalid UTF-8.
> Maybe it is valid ISO-8859-1?
> In that case you must add an XML declaration.
> 
> Actually, 1.95.3 should reject it (and it does so on my system).

Rolf Ade just pointed out to me that I didn't read your code.
You passed the ISO-8859-1 encoding to the parser, so there
was no error on your side.

However, what you reported looks exactly like what a word processor
would show you when it expects ISO-8859-1, but gets UTF-8 (tested with Wordpad).
Now, this would be a correct result, since Expat only passes UTF-8
or UTF-16 to its handlers, no matter what the input.

Karl



From fdrake@acm.org  Sat Jun 15 10:23:02 2002
From: fdrake@acm.org (Fred L. Drake, Jr.)
Date: Sat Jun 15 09:23:02 2002
Subject: [Expat-discuss] Coding style in Expat
Message-ID: <15627.27078.851139.623784@grendel.zope.com>

There have been some emails on the expat-checkins list regarding the
coding style in Expat.  I've not actually received them all since
SourceForge's mail systems seem severely overloaded and has not been
delivering email in a timely manner (I've seen as much as a 4 day
delay).

Anyway, here are my comments on the coding style.

The Expat code base exhibits signs of coding style inconsistency,
possibly because additional people have taken over maintaining it
since James Clark wrote the original code, and don't feel comfortable
with his style.

The original style uses 2-space indentation levels with leading hard
tabs which represent 8 columns each.  The hard tabs definately cause
code to look funny for people whose editors are configured to show
tabs as 4 columns, causing a weird "reverse indentation" appearance in
some cases.

Solving the reverse indentation problem can be accomplished by
converting the code style to use only spaces and no tabs; this should
be done just before the 1.95.4 release.

The two-space indentation can be difficult to read as well, but it's
less clear that a change is actually required.

My personal preference would be to use a 4 space indent, but the Expat
code is already rife with long lines and deep nesting.  It's not clear
that changing the 2 space indents is worth the pain.  (See the .c
files in the tests/ directory for examples of my preferred C style.)


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at acm.org>
PythonLabs at Zope Corporation


From karl@waclawek.net  Sat Jun 15 17:29:01 2002
From: karl@waclawek.net (Karl Waclawek)
Date: Sat Jun 15 16:29:01 2002
Subject: [Expat-discuss] Coding style in Expat
References: <15627.27078.851139.623784@grendel.zope.com>
Message-ID: <003201c214c7$03cae070$0207a8c0@karl>

> There have been some emails on the expat-checkins list regarding the
> coding style in Expat.  I've not actually received them all since
> SourceForge's mail systems seem severely overloaded and has not been
> delivering email in a timely manner (I've seen as much as a 4 day
> delay).

Wow! Actually, a lot of things seem overloaded in SourceForge recently.
 
> Anyway, here are my comments on the coding style.
> 
> The Expat code base exhibits signs of coding style inconsistency,
> possibly because additional people have taken over maintaining it
> since James Clark wrote the original code, and don't feel comfortable
> with his style.

I try to follow, but may have made errors!
 
> The original style uses 2-space indentation levels with leading hard
> tabs which represent 8 columns each.  The hard tabs definately cause
> code to look funny for people whose editors are configured to show
> tabs as 4 columns, causing a weird "reverse indentation" appearance in
> some cases.

In my case tabs show as 2 columns.
Thanks for pointing it out. I thought that was intentional.
I found the code pretty hard to read sometimes...
Why didn't I look further into it? <damn>.

> Solving the reverse indentation problem can be accomplished by
> converting the code style to use only spaces and no tabs; this should
> be done just before the 1.95.4 release.

You have my blessing. :-)
 
> The two-space indentation can be difficult to read as well, but it's
> less clear that a change is actually required.
> 
> My personal preference would be to use a 4 space indent, but the Expat
> code is already rife with long lines and deep nesting.  It's not clear
> that changing the 2 space indents is worth the pain.  (See the .c
> files in the tests/ directory for examples of my preferred C style.)

Yes, I cam live with two spaces - actually, I find four spaces
too much. Anyway, after reading the code with reverse indentation,
nothing can scare me anymore <g>

Karl



From karl@waclawek.net  Sun Jun 16 12:50:02 2002
From: karl@waclawek.net (Karl Waclawek)
Date: Sun Jun 16 11:50:02 2002
Subject: [Expat-discuss] Discussion: InternalEntityRefHandler
References: <200206131708.TAA18982@pointsman.pointsman.de> <002901c21305$23f5f100$9e539696@citkwaclaww2k>
Message-ID: <013801c21569$457b8ef0$0207a8c0@karl>

In the meantime I had a private discussion with Rolf Ade,
and he helped me clarify (and also correct) my position.

Here is what I believe the proposed InternalEntityRefhandler
should do (I leave Rolf's objections for him to explain):

- For SAX compliance I need a StartInternalEntityHandler
  and an EndInternalEntityHandler instead of just an
  InternalEntityRefhandler.

- The StartInternalEntityHandler returns a boolean-type
  value that determines if the entity will be expanded or not;
  if there is no expansion, then the EndInternalEntityHandler
  will not be called.

- It may not make much sense to have this "optional expansion"
  available for parameter entity references too, but I would
  leave it in for the following reasons:
  a) I haven't seen a good argument why it will never make sense
     (anyone please feel free to come up with one)
  b) It is extra work to disable it, and because of b)
     I see no reason to invest more effort to not have  it
  c) This capability is analog to an existing one for the
     ExternalEntityRefhandler, since there, expansion
     can be suppressed within the handler - and I like symmetry <g>
  d) I don't like function arguments that depend on other
     function arguments - i.e. "ignore return value if PE".
     However, I recognize that this can often not be avoided 
     in realistic implementations.

- An entity reference whose expansion is suppressed will
  not be reported through another handler - since that
  is essentially double reporting. This applies mostly to
  reporting an internal GE "literally" through the character handler,
  if expansion was suppressed. For PEs there would not be a "character
  handler" anyway, and for external GEs there is no way to tell
  the parser to report it again, so we would have an inconsistency too.

- The literal entity value (with character references expanded)
  will be passed to the StartInternalEntityHandler.
  Main reason: the information is available, and is easy to pass.
  However, I do not know of a really good use case for it,
  but left it in, just in case there is one. Again, feel free
  anyone to come up with pros and cons.

- The ability to modify this entity value was discussed, because
  suppression of PE references leads to WF errors in many cases,
  so it would make sense to add a "replace entity value" capability.
  But at this moment I don't think it would be worth the effort.

- There is possible conflict with SetDefaulthandler and
  SetDefaultHandlerExpand, since these *also* try to determine
  if internal entities will be expanded.
  For backwards compatibility, it should work like this:
  a) StartInternalEntityHandler is set:
     SetDefaulthandler and SetDefaultHandlerExpand have no effect
     on internal entity expansion, they just set the default handler.
  b) StartInternalEntityHandler is NOT set:
     SetDefaulthandler and SetDefaulthandlerExpand behave as
     they used to - no change.
  In the future, SetDefaultHandlerExpand should be deprecated,
  and SetDefaultHandler should loose its function to suppress
  internal entity expansion. 

- *Unclear Issue*:

There is a statement in the SAX specs that pertains
to the topic of this thread, but I don't quite understand it:

<SAX-Quote>
Because of the streaming event model that SAX uses, some entity boundaries
cannot be reported under any circumstances:
  a.. general entities within attribute values
  b.. parameter entities within declarations
These will be silently expanded, with no indication of where the original entity boundaries were.
</SAX_Quote>

This would mean, that this should not be possible in Expat.
I agree that this is true when parsing entity declarations
or attribute values in declarations, since at this point
the replacement text is not constructed. However, whenever
the replacement text is built, this should be possible, or
is there something obvious I am not understanding?

Karl



From rolf@pointsman.de  Sun Jun 16 20:01:02 2002
From: rolf@pointsman.de (rolf@pointsman.de)
Date: Sun Jun 16 19:01:02 2002
Subject: [Expat-discuss] Discussion: InternalEntityRefHandler
In-Reply-To: <013801c21569$457b8ef0$0207a8c0@karl>
Message-ID: <200206170152.DAA02526@pointsman.pointsman.de>

On 16 Jun, Karl Waclawek wrote:
> Here is what I believe the proposed InternalEntityRefhandler
> should do (I leave Rolf's objections for him to explain):
> 
> - For SAX compliance I need a StartInternalEntityHandler
>   and an EndInternalEntityHandler instead of just an
>   InternalEntityRefhandler.

I know, you aim for SAX compliance. Although I don't think, that SAX
compliance is a strict 'must' for expat, I could see some value in
this.

Interesting enough you argue with SAX compliance for your proposal,
although your proposal in fact doesn't resemble the SAX startEntity
handler.

The SAX startEntity handler has as sole argument the entity name
(parameter entities have '%' prepended to their names) and especially
no return value (is void). See
http://www.saxproject.org/apidoc/org/xml/sax/ext/LexicalHandler.html#startEntity(java.lang.String)  

Since you now propose a Start/End InternalEntityHandler pair, why not
just always expand any entity (PE's and GE's), if possible? With the
Start-/EndInternalEntityHandler the programmer is able to preserve the
GE's inside the document - which is the main use case for this
Start-/EndInternalEntityHandler, that I'm able to see. Without the
risk of any harm. (But see the exceptions, at the end of the mail).

> - The StartInternalEntityHandler returns a boolean-type
>   value that determines if the entity will be expanded or not;
>   if there is no expansion, then the EndInternalEntityHandler
>   will not be called.

Well, as already said above, SAX doesn't know anything about such a
return value of startEntity.

> - It may not make much sense to have this "optional expansion"
>   available for parameter entity references too, but I would
>   leave it in for the following reasons:
>   a) I haven't seen a good argument why it will never make sense
>      (anyone please feel free to come up with one)

Since this "optional expansion" is clearly an enhancement of the SAX
startEntity handler API by you, why don't you bring up a pro argument
for doing it?

In a previous mail I've provided a range of examples, for which
suppressing the PE's expansion is disastrous.

Why do you want to add a feature, for which you have to write in the
documentation: "We don't know a sensible use case for this feature. Be
warned: If you use suppressing of PE expansion, there are pretty good
chances that you break your application."

I really don't buy in your argument 'It may eventually useful for
something, not known up to now'. If we accept this argument as valid,
we have to add anything to the API.

Do you know about any feature request for 'suppressing PE expansion'?
No? Oh...

Don't fix it, if it isn't broken.

>   b) It is extra work to disable it, and because of b)
>      I see no reason to invest more effort to not have  it

Again, I don't buy in this argument. Even if we came to the
conclusion, that the StartInternalEntityHandler should return a flag,
this would be 1 line of code. Come on, Karl.

>   c) This capability is analog to an existing one for the
>      ExternalEntityRefhandler, since there, expansion
>      can be suppressed within the handler - and I like symmetry <g>

No. This symmetry is only very vague. The ExternalEntityRefhandler has
to do the expansion of the external entity by it's own (resolve the
external entity, create an externalEntityParser, read the external
entity and feed it into the externalEntityParser etc.). The
StartInternalEntityHandler doesn't do the entity expansion, it's done
by the parser. Where's the symmetry?

Or look what happens, if both ExternalEntityRefhandler and
StartInternalEntityHandler are not set. External Entities are silently
skipped (not expanded), but internal entities will be expanded (if
there declaration is known). Really no clear symmetry.

>   d) I don't like function arguments that depend on other
>      function arguments - i.e. "ignore return value if PE".
>      However, I recognize that this can often not be avoided 
>      in realistic implementations.

OK. But if StartInternalEntityHandler returns void, this problem is
vanished.

> - The literal entity value (with character references expanded)
>   will be passed to the StartInternalEntityHandler.
>   Main reason: the information is available, and is easy to pass.
>   However, I do not know of a really good use case for it,
>   but left it in, just in case there is one. Again, feel free
>   anyone to come up with pros and cons.

What you call the "literal entity value" is exactly the same, that
someone could get via the entityDeclHandler, right?

So, since there is already a way, to get this information, if someone
really needs it, where's the point in providing a function argument,
which will - as even you confirm - be ignored in almost all cases?

> - There is possible conflict with SetDefaulthandler and
>   SetDefaultHandlerExpand, since these *also* try to determine
>   if internal entities will be expanded.
>   For backwards compatibility, it should work like this:
>   a) StartInternalEntityHandler is set:
>      SetDefaulthandler and SetDefaultHandlerExpand have no effect
>      on internal entity expansion, they just set the default handler.
>   b) StartInternalEntityHandler is NOT set:
>      SetDefaulthandler and SetDefaulthandlerExpand behave as
>      they used to - no change.
>   In the future, SetDefaultHandlerExpand should be deprecated,
>   and SetDefaultHandler should loose its function to suppress
>   internal entity expansion. 

Yes.

> - *Unclear Issue*:
> 
> There is a statement in the SAX specs that pertains
> to the topic of this thread, but I don't quite understand it:
> 
> <SAX-Quote>
> Because of the streaming event model that SAX uses, some entity boundaries
> cannot be reported under any circumstances:
>   a.. general entities within attribute values
>   b.. parameter entities within declarations
> These will be silently expanded, with no indication of where the original entity boundaries were.
> </SAX_Quote>
> 
> This would mean, that this should not be possible in Expat.
> I agree that this is true when parsing entity declarations
> or attribute values in declarations, since at this point
> the replacement text is not constructed. However, whenever
> the replacement text is built, this should be possible, or
> is there something obvious I am not understanding?

Yes. As illustration, look at this example:

<?xml version="1.0" ?>
<!DOCTYPE element [
<!ENTITY a "f" >
<!ENTITY b "b" >
]>
<element attr1="foo&a;foo" attr2="boo" attr3="bar&b;bar">baz</element>

Since the element name and all attributes are reported at once via the
elementStartHandler, at which point will you call Start- and
EndInternalEntityHandler? You could only call it befor or after the
call of the elementStartHandler. But this doesn't provide really
useful information. Even if you call the StartInternalEntityHandler
twice, let's say, befor the elementStartHandler, in which of the three
attributes are the two entities? And at which position inside the
Attribute value?  Same argumentation goes for "b..".

This is cleary a drawback. But there isn't much, one can do against,
even with your proposal.

(Well, I could see a way around, which even brings your
StartInternalEntityHandler return value back, but I doubt it would be
accepted. And since it's already high time to keep still, I'll do
exactly this ;-).)

rolf





From karl@waclawek.net  Mon Jun 17 08:15:02 2002
From: karl@waclawek.net (Karl Waclawek)
Date: Mon Jun 17 07:15:02 2002
Subject: [Expat-discuss] Discussion: InternalEntityRefHandler
Message-ID: <001401c21609$41efb360$9e539696@citkwaclaww2k>

Rolf Ade wrote:

> On 16 Jun, Karl Waclawek wrote:
> I know, you aim for SAX compliance. Although I don't think, that SAX
> compliance is a strict 'must' for expat, I could see some value in
> this.
>
> Interesting enough you argue with SAX compliance for your proposal,
> although your proposal in fact doesn't resemble the SAX startEntity
> handler.

Correct. I also try to satisfy some feature requests.

> The SAX startEntity handler has as sole argument the entity name
> (parameter entities have '%' prepended to their names) and especially
> no return value (is void). See
> http://www.saxproject.org/apidoc/org/xml/sax/ext/LexicalHandler.html#startEntity(java.lang.String)

The return value has the function of enabling the caller to suppress
expansion of selected entities, a feature request - see patch # 429501.
The entity value as parameter goes beyond SAX, for reasons explained.
My goal really is to add SAX functionality missing in Expat, not to turn
the Expat API into a SAX clone.

> Since you now propose a Start/End InternalEntityHandler pair, why not
> just always expand any entity (PE's and GE's), if possible? With the
> Start-/EndInternalEntityHandler the programmer is able to preserve the
> GE's inside the document - which is the main use case for this
> Start-/EndInternalEntityHandler, that I'm able to see. Without the
> risk of any harm. (But see the exceptions, at the end of the mail).

This would work for GEs, I think, but you still have the disadvantage
of letting Expat do unnecessary work - always parsing the entity value
even when you don't need it. But Expat is all about efficiency...

> > - The StartInternalEntityHandler returns a boolean-type
> >   value that determines if the entity will be expanded or not;
> >   if there is no expansion, then the EndInternalEntityHandler
> >   will not be called.
>
> Well, as already said above, SAX doesn't know anything about such a
> return value of startEntity.

Correct. SAX only allows to disable expansion of external PEs globally.
The proposal goes beyond SAX, to satisfy the request to disable expansion
of specific entities (predefined general entities for the feature request).
I didn't narrow the feature to such entities, but made it more generic.

> > - It may not make much sense to have this "optional expansion"
> >   available for parameter entity references too, but I would
> >   leave it in for the following reasons:
> >   a) I haven't seen a good argument why it will never make sense
> >      (anyone please feel free to come up with one)
>
> Since this "optional expansion" is clearly an enhancement of the SAX
> startEntity handler API by you, why don't you bring up a pro argument
> for doing it?

Because I think I rather need a counter argument.
I am the kind of guy who needs an argument *for* doing the extra work,
and *no* argument for *not* doing it. ;-)

> In a previous mail I've provided a range of examples, for which
> suppressing the PE's expansion is disastrous.
>
> Why do you want to add a feature, for which you have to write in the
> documentation: "We don't know a sensible use case for this feature. Be
> warned: If you use suppressing of PE expansion, there are pretty good
> chances that you break your application."
>
> I really don't buy in your argument 'It may eventually useful for
> something, not known up to now'. If we accept this argument as valid,
> we have to add anything to the API.

I don't quite agree. There are reasons for adding the Start/EndEntityHandler
the way I proposed. Coming with it as an automatic side-effect would then
be the ability to suppress PE expansion.
So, I don't need an argument for that ability, since it will be there
automatically. What I need is a good argument against, since my point is:
It will be there - why make extra steps to take it out?

> Do you know about any feature request for 'suppressing PE expansion'?
> No? Oh...

See above.

> Don't fix it, if it isn't broken.

Does that now mean - don't take it out. ;-)

> >   b) It is extra work to disable it, and because of b)
> >      I see no reason to invest more effort to not have  it
>
> Again, I don't buy in this argument. Even if we came to the
> conclusion, that the StartInternalEntityHandler should return a flag,
> this would be 1 line of code. Come on, Karl.

I just see no reason do do something extra to take a feature
out that comes automatically, if you can't tell me that this
feature makes no sense. It's not about the extra hours (or rather minutes)
I would have to spend.

Now - is there anybody on this list who knows XML well
enough to produce a good argument? I would be the first
to take the "suppress PE expansion" capability out, if
it makes no sense - but unfortunately I am not enough
of an expert to have a definitive opinion.

> >   c) This capability is analog to an existing one for the
> >      ExternalEntityRefhandler, since there, expansion
> >      can be suppressed within the handler - and I like symmetry <g>
>
> No. This symmetry is only very vague. The ExternalEntityRefhandler has
> to do the expansion of the external entity by it's own (resolve the
> external entity, create an externalEntityParser, read the external
> entity and feed it into the externalEntityParser etc.). The
> StartInternalEntityHandler doesn't do the entity expansion, it's done
> by the parser. Where's the symmetry?

In the things you can do - suppress expansion of all types of entities,
report entity boundaries, look at the entity value ...

> Or look what happens, if both ExternalEntityRefhandler and
> StartInternalEntityHandler are not set. External Entities are silently
> skipped (not expanded), but internal entities will be expanded (if
> there declaration is known). Really no clear symmetry.

It is true that, because of the fact that the handler doesn't actually
initiate the parsing of the internal entity, the behaviour in the case
of a missing handler would be different, unless we had an extra API capability
to control internal entity expansion. But we have it: SetDefaultHandler(Expand).

You just provided an argument to keep SetDefaulthandler and SetDefaultHandlerExpand,
and not deprecate them.

> >   d) I don't like function arguments that depend on other
> >      function arguments - i.e. "ignore return value if PE".
> >      However, I recognize that this can often not be avoided
> >      in realistic implementations.
>
> OK. But if StartInternalEntityHandler returns void, this problem is
> vanished.

*if* it returns void...

> > - The literal entity value (with character references expanded)
> >   will be passed to the StartInternalEntityHandler.
> >   Main reason: the information is available, and is easy to pass.
> >   However, I do not know of a really good use case for it,
> >   but left it in, just in case there is one. Again, feel free
> >   anyone to come up with pros and cons.
>
> What you call the "literal entity value" is exactly the same, that
> someone could get via the entityDeclHandler, right?

I would say so.

> So, since there is already a way, to get this information, if someone
> really needs it, where's the point in providing a function argument,
> which will - as even you confirm - be ignored in almost all cases?

Well, in our private conversations I was thinking about taking it out,
but you thought I might as well leave it in. One advantage I can think of:
It saves you an extra hash table lookup - since Expat does that anyway.

> > - *Unclear Issue*:
> >
> > There is a statement in the SAX specs that pertains
> > to the topic of this thread, but I don't quite understand it:
> >
> > <SAX-Quote>
> > Because of the streaming event model that SAX uses, some entity boundaries
> > cannot be reported under any circumstances:
> >   a.. general entities within attribute values
> >   b.. parameter entities within declarations
> > These will be silently expanded, with no indication of where the original entity boundaries
were.
> > </SAX_Quote>
> >
> > This would mean, that this should not be possible in Expat.
> > I agree that this is true when parsing entity declarations
> > or attribute values in declarations, since at this point
> > the replacement text is not constructed. However, whenever
> > the replacement text is built, this should be possible, or
> > is there something obvious I am not understanding?
>
> Yes. As illustration, look at this example:
>
> <?xml version="1.0" ?>
> <!DOCTYPE element [
> <!ENTITY a "f" >
> <!ENTITY b "b" >
> ]>
> <element attr1="foo&a;foo" attr2="boo" attr3="bar&b;bar">baz</element>
>
> Since the element name and all attributes are reported at once via the
> elementStartHandler, at which point will you call Start- and
> EndInternalEntityHandler? You could only call it befor or after the
> call of the elementStartHandler. But this doesn't provide really
> useful information. Even if you call the StartInternalEntityHandler
> twice, let's say, befor the elementStartHandler, in which of the three
> attributes are the two entities? And at which position inside the
> Attribute value?  Same argumentation goes for "b..".

Very good point, thanks!

Another way of stating the argumentation for b) in the quoted SAX-spec :
The XML spec seems to indicate, that the replacement text for
an entity is constructed *before* it is parsed. Which would mean
that entity boundaries for PEs in literal entity values get lost.

> This is cleary a drawback. But there isn't much, one can do against,
> even with your proposal.
>
> (Well, I could see a way around, which even brings your
> StartInternalEntityHandler return value back, but I doubt it would be
> accepted. And since it's already high time to keep still, I'll do
> exactly this ;-).)

Now you made me curious... <g>

Karl



From gstein@lyra.org  Fri Jun 21 08:30:05 2002
From: gstein@lyra.org (Greg Stein)
Date: Fri Jun 21 07:30:05 2002
Subject: [Expat-discuss] Re: [ expat-Bugs-564275 ] Test 11 in stream.t fails
In-Reply-To: <E17LPBe-0000Ho-00@usw-sf-web3.sourceforge.net>; from noreply@sourceforge.net on Fri, Jun 21, 2002 at 07:14:54AM -0700
References: <E17LPBe-0000Ho-00@usw-sf-web3.sourceforge.net>
Message-ID: <20020621073148.C10036@lyra.org>

I say that we just remove the XML::Parser from the list of areas that people
can file bugs against.

Cheers,
-g

On Fri, Jun 21, 2002 at 07:14:54AM -0700, noreply@sourceforge.net wrote:
>...
> ----------------------------------------------------------------------
> 
> >Comment By: Fred L. Drake, Jr. (fdrake)
> Date: 2002-06-21 10:14
> 
> Message:
> Logged In: YES 
> user_id=3066
> 
> This report can't be assigned to Clark Cooper since he's no
> longer active on this project.  I'll see if I can round up
> someone to help respond to XML::Parser issue reports -- I
> don't know that anyone currently on this project knows much
> about the Perl bindings.
> 
> ----------------------------------------------------------------------
>...

-- 
Greg Stein, http://www.lyra.org/


From Vijay.Naidu@adelphia.com  Thu Jun 27 08:57:07 2002
From: Vijay.Naidu@adelphia.com (Vijay Naidu)
Date: Thu Jun 27 07:57:07 2002
Subject: [Expat-discuss] A Newbie question.
Message-ID: <69DCAE8DF2BFD411AACC0002A50A63F015003730@cdptex1.adelphiacom.com>

I have currently just started using Expat. I had a question as to whether it
was possible to read the XML document that I recieve as an input stream from
a client without having to write it to a file on the disk? If yes, how can I
achieve that. A short example would be of great help.

Vijay Naidu
System Analyst
----------------------------------------------------------------------------
------------
Smile is a curve that makes everything straight. Keep smiling
Experience, my friends, is the hardest kind of teacher. 
It gives you a test first and the lesson afterwards
----------------------------------------------------------------------------
------------



From tentacula@wanadoo.fr  Thu Jun 27 15:49:03 2002
From: tentacula@wanadoo.fr (Tentacula)
Date: Thu Jun 27 14:49:03 2002
Subject: [Expat-discuss] using expat as a static library
Message-ID: <000801c21e24$57387950$0700a8c0@adeline>

This is a multi-part message in MIME format.

---------------------- multipart/alternative attachment
Hi,
I've just a problem : I'd like to use expat as a static library using =
VC6 (sp5), is it possible ? and if yes how can I do so ?
when I try to compil expat I get these linker errors :

xml.obj : error LNK2001: unresolved external symbol =
__imp__XML_GetCurrentLineNumber
xml.obj : error LNK2001: unresolved external symbol =
__imp__XML_ParserFree
xml.obj : error LNK2001: unresolved external symbol =
__imp__XML_ErrorString
xml.obj : error LNK2001: unresolved external symbol =
__imp__XML_GetErrorCode
xml.obj : error LNK2001: unresolved external symbol __imp__XML_Parse
xml.obj : error LNK2001: unresolved external symbol =
__imp__XML_SetCharacterDataHandler
xml.obj : error LNK2001: unresolved external symbol =
__imp__XML_SetElementHandler
xml.obj : error LNK2001: unresolved external symbol =
__imp__XML_SetUserData
xml.obj : error LNK2001: unresolved external symbol =
__imp__XML_ParserCreate

thanks.

---------------------- multipart/alternative attachment
An HTML attachment was scrubbed...
URL: http://mail.libexpat.org/pipermail-21/expat-discuss/attachments/20020627/d0c6b1ac/attachment.html

---------------------- multipart/alternative attachment--



From Josh.Martin@abq.sc.philips.com  Fri Jun 28 13:11:24 2002
From: Josh.Martin@abq.sc.philips.com (Josh Martin)
Date: Fri Jun 28 12:11:24 2002
Subject: [Expat-discuss] A Newbie question.
Message-ID: <200206281910.NAA00697@abqn42.abq.sc.philips.com>

> I have currently just started using Expat. I had a question as to whether it
> was possible to read the XML document that I recieve as an input stream from
> a client without having to write it to a file on the disk? If yes, how can I
> achieve that. A short example would be of great help.
> 
> Vijay Naidu
> System Analyst

The XML_Parse() function works on a buffer in memory, so writing the file to a 
disk and reading it back into a buffer would actually be doing more work than is 
required.  It would be possible to call XML_Parse() on each byte that you 
recieve from the input stream, if it streams one byte at a time, but that would 
be inefficient.  It would probably be better to buffer the input stream into an 
array as you're reading it, and then when the array gets full, parse that, and 
then clear the array and continue buffering.  Just make sure that you specify 
the length argument correctly in the call to XML_Parse(), and specify the 
isfinal argument to true when you are finished parsing the input stream.  
Remember that you will have to create a new parser object and start over again 
if you'll be parsing a series of XML documents from the stream rather than just 
one (although I think there's a function to reset the parser in expat 1.95.3).  
Let me know if you need any more information.

 - Josh Martin
 



From fdrake@acm.org  Fri Jun 28 13:21:13 2002
From: fdrake@acm.org (Fred L. Drake, Jr.)
Date: Fri Jun 28 12:21:13 2002
Subject: [Expat-discuss] using expat as a static library
In-Reply-To: <000801c21e24$57387950$0700a8c0@adeline>
References: <000801c21e24$57387950$0700a8c0@adeline>
Message-ID: <15644.43249.885857.252986@grendel.zope.com>

Tentacula writes:
 > I've just a problem : I'd like to use expat as a static library
 > using VC6 (sp5), is it possible ? and if yes how can I do so ?

You *should* be able to simply copy the .c and .h files from the lib/
directory of the sources, add the .c files to your project, and build
normally.  But I've not tried to do that myself under Windows, but
this is common on Unix.

 > when I try to compil expat I get these linker errors :
 > 
 > xml.obj : error LNK2001: unresolved external symbol __imp__XML_GetCurrentLineNumber
 > xml.obj : error LNK2001: unresolved external symbol __imp__XML_ParserFree
 > xml.obj : error LNK2001: unresolved external symbol __imp__XML_ErrorString
 > xml.obj : error LNK2001: unresolved external symbol __imp__XML_GetErrorCode
 > xml.obj : error LNK2001: unresolved external symbol __imp__XML_Parse
 > xml.obj : error LNK2001: unresolved external symbol __imp__XML_SetCharacterDataHandler
 > xml.obj : error LNK2001: unresolved external symbol __imp__XML_SetElementHandler
 > xml.obj : error LNK2001: unresolved external symbol __imp__XML_SetUserData
 > xml.obj : error LNK2001: unresolved external symbol __imp__XML_ParserCreate

I don't know what's up with this.  Hopefully someone who knows more
about doing this in the Windows environment can be of more help.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at acm.org>
PythonLabs at Zope Corporation


From karl@waclawek.net  Fri Jun 28 14:17:03 2002
From: karl@waclawek.net (Karl Waclawek)
Date: Fri Jun 28 13:17:03 2002
Subject: [Expat-discuss] using expat as a static library
References: <000801c21e24$57387950$0700a8c0@adeline> <15644.43249.885857.252986@grendel.zope.com>
Message-ID: <002601c21ee0$b25b4a30$9e539696@citkwaclaww2k>

> Tentacula writes:
>  > I've just a problem : I'd like to use expat as a static library
>  > using VC6 (sp5), is it possible ? and if yes how can I do so ?
> 
> You *should* be able to simply copy the .c and .h files from the lib/
> directory of the sources, add the .c files to your project, and build
> normally.  But I've not tried to do that myself under Windows, but
> this is common on Unix.
> 
>  > when I try to compil expat I get these linker errors :
>  > 
>  > xml.obj : error LNK2001: unresolved external symbol __imp__XML_GetCurrentLineNumber
>  > xml.obj : error LNK2001: unresolved external symbol __imp__XML_ParserFree
>  > xml.obj : error LNK2001: unresolved external symbol __imp__XML_ErrorString
>  > xml.obj : error LNK2001: unresolved external symbol __imp__XML_GetErrorCode
>  > xml.obj : error LNK2001: unresolved external symbol __imp__XML_Parse
>  > xml.obj : error LNK2001: unresolved external symbol __imp__XML_SetCharacterDataHandler
>  > xml.obj : error LNK2001: unresolved external symbol __imp__XML_SetElementHandler
>  > xml.obj : error LNK2001: unresolved external symbol __imp__XML_SetUserData
>  > xml.obj : error LNK2001: unresolved external symbol __imp__XML_ParserCreate
> 
> I don't know what's up with this.  Hopefully someone who knows more
> about doing this in the Windows environment can be of more help.

What project settings did you change to build a static library?
I simply replaced _USRDLL with _LIB in the Preprocessor definitions,
and changed the output file name. That compiled OK.

Karl



From henry.hsieh@idsnet.com  Fri Jun 28 17:00:01 2002
From: henry.hsieh@idsnet.com (Henry Hsieh)
Date: Fri Jun 28 16:00:01 2002
Subject: [Expat-discuss] Re: A Newbie question (about reading from an input stream)
Message-ID: <CABB1ACFCD4ED611844800A0C9FC17A07017@atlas.idsnet.com>

It depends on what type of input stream you are getting your information.
If it's up to you, you can try using the name-pipe.  Here is a quick
description of it:

The named pipe behaves very much like an ordinary file, except that (copied
from http://plasma-gate.weizmann.ac.il/Xmgr/doc/npipe.html check this web
page for more information)
1. Only one process can open the named pipe for writing, and only one
process can open the pipe for reading (at the same time), 
2. Nothing is written to the disk but rather into some memory buffer, 
3. If the listening end closes the pipe while the talking end has the pipe
still open for writing, the talking end gets a signal SIGPIPE if it tries to
write to the pipe. If we did not install a signal handler for SIGPIPE, the
talking end exits.

- Henry

>From: Vijay Naidu <Vijay.Naidu@adelphia.com>
>Date: Thu, 27 Jun 2002 10:52:17 -0400
>Subject: [Expat-discuss] A Newbie question.
>
>I have currently just started using Expat. I had a question as to whether
it
>was possible to read the XML document that I recieve as an input stream
from
>a client without having to write it to a file on the disk? If yes, how can
I
>achieve that. A short example would be of great help.
>
>Vijay Naidu
>System Analyst
>

Henry Hsieh
Integrated Decision Systems


From tentacula@wanadoo.fr  Sat Jun 29 11:28:02 2002
From: tentacula@wanadoo.fr (Tentacula)
Date: Sat Jun 29 10:28:02 2002
Subject: [Expat-discuss] using expat as a static library
References: <000801c21e24$57387950$0700a8c0@adeline> <15644.43249.885857.252986@grendel.zope.com> <002601c21ee0$b25b4a30$9e539696@citkwaclaww2k>
Message-ID: <000001c21f92$3b8121c0$0700a8c0@adeline>

Hi,
Argh, I've made a mistake, that's not the library that do not compile but
the project I've made using the expat library. soory about that !!
All I have done is to create a new dsp project (I have not used the provided
one), a static library project, added all the /lib/*.c and /lib/*.h files,
and just added the COMPILED_FROM_DSP flag in preprocessor definitions
settings.
The library compiles fine, but when I try to use it in another project I get
the linker problem I've mentionned.
I also use the zLib as a static library in the same project and it works
fine (just to show you that I'm not completly stupid and I know how to use
my IDE ;) - hmm, I guess... )

Well, i'm just trying to compile this code
ftp://ftp.flipcode.com/cotd/xml.zip (a XML parser/writer using expat) but
i'm asking if it could be too old ? the code works with the .DLL provided
with it, but I can't compile it with my static release !?

>from Tentacula
/me wants fresh code (and new brain with more neurones !)





From we_gowind@yahoo.co.in  Sun Jun 30 01:11:01 2002
From: we_gowind@yahoo.co.in (=?iso-8859-1?q?govindarajan=20varadharajulu?=)
Date: Sun Jun 30 00:11:01 2002
Subject: [Expat-discuss] help : how to use the expat-1.95.3
Message-ID: <20020630071023.98156.qmail@web8004.mail.in.yahoo.com>

i am installed expat-1.95.3 in my sunOS5.8 but the
path for expat-1.95.3/lib and expat-1.95.3/bin is not
set.whenever i try to run my parser perl program is
not at all Identifying the parser methods.

these are the septs i have followed.
1) down loaded expat-1.95.3 from sourceforge.net 
2) put into my home directory(/misc/home/john/)
3) gunzip and tar the .gz file(it's created a file
expat-1.95.3)
4) ./configure -PREFIX=/misc/home/john/expat-1.95.3
5) ./configure CPPFLAGS=-DXML_UNICODE
6) ./configure CFLAGS="-g -O2 -fshort-wchar" PPFLAGS=-
   DXML_UNICODE_WCHAR_T
It's trowing error(<govind@tucson:>./configure
CFLAGS="-g -O2 -fshort-wchar" PPFLAGS=-DXML_UNICO>
checking build system type... sparc-sun-solaris2.8
checking host system type... sparc-sun-solaris2.8
checking for gcc... gcc
checking for C compiler default output... configure:
error: C compiler cannot create executables)

7) make buildlib
8) make installlib
9) PATH=/usr/ccs/bin:$PATH make
throwing error(
cc -g -O2 -Wall -Wmissing-prototypes
-Wstrict-prototypes -fexceptions  -DXML_UNICODE -Ilib
-I. -o xmlwf/xmlwf.o -c xmlwf/xmlwf.c
/usr/ucb/cc:  language optional software package not
installed
*** Error code 1
make: Fatal error: Command failed for target
`xmlwf/xmlwf.o'
)
10)  LD_LIBRARY_PATH = {$LD_LIBRARY_PATH
}:/misc/home/john/expat-1.95.3

After this if i run any perl file having lib function
like

XML_Parser
XML_LChar *
XML_ExpatVersion();

throwing error 
(
syntax error at test.pl line 3, near "*
XML_ExpatVersion("
Execution of test.pl aborted due to compilation
errors.
)

Please advice what i want to do get this work well


govind


 





________________________________________________________________________
Want to sell your car? advertise on Yahoo Autos Classifieds. It's Free!!
       visit http://in.autos.yahoo.com