gobo-eiffel-develop — Development discussions

Re: [gobo-eiffel-develop] gexace nested cluster problem

[Glenn M. <gle...@ho...>]

>With the way it is implemented now, as soon as you
>have the attribute 'location', it is meant to be
>a full pathname and not a relative pathname to the
>parent directory. That's why you got the above behavior.
>

This is fine as long as it doesn't require absolute paths. I'd like to be 
able to move clusters around without having to recode the xace file. Relying 
on environment variables to specify the root of a path is ok but not perfect 
because it is another thing a user has to set to get a library working.

Ant is traditionally used by executing from the directory where the .ant 
file resides. Therefore every path can be relative. The geant files I have 
seen so far (from GOBO) seem to rely more on absolute paths with an 
environment variable specifying the root.

>
>What's your opinion on both solutions?
>

I prefer the current solution (name concatenation). But if the ISE nested 
cluster syntax was used then name clashes could again occur unless the 
concatenation was used as well. Needs some thought...

Glenn.


_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

[gobo-eiffel-develop] outofdate

[Eric B. <er...@go...>]

Sven,

So far we had class names of the form GEANT_<taskname>_COMMAND
and GEANT_<taskname>_TASK, where <taskname> is the name of
the corresponding task as it appears in the build files. So
although it doesn't follow exactly the Eiffel style, I would
personally have named the classes for <outofdate>
GEANT_OUTOFDATE_COMMAND and GEANT_OUTOFDATE_TASK instead
of GEANT_OUT_OF_DATE_COMMAND and GEANT_OUT_OF_DATE_TASK.
What is your point of view about the GEANT_<taskname>_COMMAND
and GEANT_<taskname>_TASK naming convention?

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

Re: [gobo-eiffel-develop] Re: Re: CDATA

[Eric B. <er...@go...>]

Sven Ehrke wrote:
> 
> So in summary I think at least some entities should
> be supported by an Eiffel XML parser and the CDATA
> as well for the elements.

I have implemented a patch into the Eiffel XML parser
so that it can now accept (and corretly interpret) the
entities '&.lt.;', '&.gt.;' and '&.amp.;' in attribute
string values (as usual dots are here just to avoid
Web mail interfaces to expand the entities, please
skip them). My 'build.eant' files have been updated
accordingly.

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

Re: [gobo-eiffel-develop] Eiffel XML parser 'parse_from_string' implementation

[Eric B. <er...@go...>]

Glenn Maughan wrote:
> 
> I'm trying to convert to using the Eiffel XML parser in GOBO but need to use
> 'parse_from_string' as that is the routine I was using with the expat
> implementation. It is currently implemented as:
> 
>         parse_from_string (data: STRING) is
>                 do
>                         check
>                                 False   -- TODO
>                         end
>                 end
> 
> Anyone willing to implement it for me? Please!

I just implemented it and committed to CVS. However no testing
has been done at all (apart from checking that it compiles
with ISE Eiffel). So it's up to you to try it if you want.

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

Re: [gobo-eiffel-develop] Feature requests for gexace

[Eric B. <er...@go...>]

Glenn Maughan wrote:
> 
> This is why gexace is so useful. We can hide the idiosyncrasies of each
> compiler's build language behind one general language. But the tool should
> also build the "best" Ace files possible for each language. It only has to
> be coded once and everyone benefits.

I just committed to CVS the changes to that 
'gexace --build --ise' should now generate
ISE's parent cluster syntax when possible.
I only tested by running the bootstrap script
with ISE Eiffel on my PC.

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

Re: [gobo-eiffel-develop] Feature requests for gexace

[Eric B. <er...@go...>]

Andreas Leitner wrote:
> So we need some kind of eiffel-identifier checker in gexace.
> Eric, I assume something similar is in eiffel-tools already.

Not yet: in eiffel-tools the check is done by the lexical
analyzer during the parsing. So there was no need to write
such eiffel-identifier checker routine.

> Using only one implementation for the identifier checker has
> the additional advantage that should the definition of eiffel
> identifiers ever change (think unicode) we only need to adopt
> it at one place.

Agreed, such routine should definitely be put in the
eiffel-tools library so that it can be shared between
various tools needing such functionality.

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

Re: [gobo-eiffel-develop] gexace nested cluster problem

[Eric B. <er...@go...>]

Glenn Maughan wrote:
> 
> The following cluster element:
> 
>         <cluster name="goanna" location=".">
>                 <cluster name="TESTGEN"/>
>                 <cluster name="utility_tests" location="utility"/>
>                 <cluster name="log4e_tests" location="log4e"/>
>         </cluster>
> 
> builds an ISE Ace file with the following cluster definitions:
> 
>         goanna: "."
>         goanna_TESTGEN: "./TESTGEN"
>         goanna_utility_tests: "utility"
>         goanna_log4e_tests: "log4e"
> 
> I would have expected the 'goanna_utility_tests' and 'goanna_log4e_tests' to
> have the './' of the parent cluster prepended to the path.

With the way it is implemented now, as soon as you
have the attribute 'location', it is meant to be 
a full pathname and not a relative pathname to the
parent directory. That's why you got the above behavior.

So you would have had to write:

        <cluster name="goanna" location=".">
                <cluster name="TESTGEN"/>
                <cluster name="utility_tests" location="./utility"/>
                <cluster name="log4e_tests" location="./log4e"/>
        </cluster>

to get your expected result.

> In the cluster element above I needed to use different names to the paths
> because existing clusters already used the names 'utility' and 'log4e'.

In the Ace file generated by 'gexace' the cluster tags are
actually the concatenation of the parent full tag and the
cluster name, as you could see above with 'goanna_TESTGEN'
for example. So even if you used 'utility' somewhere else,
there is low risk that there will be a name clash.

Now the question is whether the policy of concatenating
tags adopted by 'gexace' is a good thing or not. Another
policy could have been to use directly the values specified
in the 'name' attribute and append 1, 2, 3 ,... when there
are name clashes:

  <cluster name="foo" location="path/name">
      <cluster name="bar"/>
      <cluster name="toto>
         <cluster name="bar"/>
      </cluster>
  </cluster>

how it works now:

  foo: "path/name"
  foo_bar: "path/name/bar"
  foo_toto: "path/name/toto"
  foo_toto_bar: "path/name/toto/bar"

other possible solution (not implemented):

  foo: "path/name"
  bar: "path/name/bar"
  toto: "path/name/toto"
  bar1: "path/name/toto/bar"

We'd put "bar1" instead of "bar" to avoid the name clash.

What's your opinion on both solutions?

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

[gobo-eiffel-develop] Feature requests for gexace

[Eric B. <er...@go...>]

Another message which should have been sent to the list.

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

[gobo-eiffel-develop] Eiffel XML parser 'parse_from_string' implementation

[Eric B. <er...@go...>]

This is a message from Andreas which was sent to me
instead of to the list.

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

[gobo-eiffel-develop] gexace nested cluster problem

[Glenn M. <gle...@op...>]

The following cluster element:

	<cluster name="goanna" location=".">
		<cluster name="TESTGEN"/>
		<cluster name="utility_tests" location="utility"/>
		<cluster name="log4e_tests" location="log4e"/>
	</cluster>

builds an ISE Ace file with the following cluster definitions:

	goanna: "."
	goanna_TESTGEN: "./TESTGEN"
	goanna_utility_tests: "utility"
	goanna_log4e_tests: "log4e"

I would have expected the 'goanna_utility_tests' and 'goanna_log4e_tests' to
have the './' of the parent cluster prepended to the path.

In the cluster element above I needed to use different names to the paths
because existing clusters already used the names 'utility' and 'log4e'.

Is this correct?

Thanks.
Glenn.

Re: [gobo-eiffel-develop] Feature requests for gexace

[Eric B. <er...@go...>]

Glenn Maughan wrote:
> 
> A general question first: Eric, do you want feature requests and bugs to be
> sent to this list or logged on the SourceForge trackers? I'm all for the
> SourceForge trackers...it increases the activity stats for the project and
> makes them easy to track.

Personnally, I'm not sure I'll have time to manage the
SF trackers and would prefer to use the list. I don't
think that activity stats is a goal, and other members
of the list may be interested in discussing requests
or how to fix bugs. A bug tracker might be valuable
for big projects, I'm not sure we can really take the
full advantage of it at this stage of development in
Gobo. Do you (or somebody else) have any experience
with SF bug tracker?

> A couple of requests:
> 
> 1) Would it be possible for gexace to generate Ace files for ISE that use
> the nested cluster syntax rather than concatenating the parent and child
> cluster names? 

I personnally hate this syntax adopted by ISE, so I never
use it in my Ace files. That's why Ace files are currently
generated the way they are by 'gexace'.

> This allows the ISE environment to build a tree structure of clusters that
> is much easier to navigate and quicker to display.

That's a good reason. I'll have a look at it, but a priori
I don't think it should be too difficult to implement it
the way you want.

> 2) This may be a bug. The following Xace cluster:
> 
>         <cluster name="parent" location="my/path">
>                 <cluster name="my-child"/>
>         </cluster>
> 
> generates:
> 
>         parent: "my/path"
>         my-child: "my/path/my-child"
> 
> The cluster name 'my-child' is invalid in ISE. Perhaps it needs to be
> converted to 'my_child'.

The bug is that:

  <cluster name="my-child"/>

should have been rejected by 'gexace'. The attribute 'name'
should be a valid Ace file cluster tag. If  the name of
a directory is not a valid cluster name, you should write
it that way:

  <cluster name="a_valid_tag" location="full/path/name"/>

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

Re: [gobo-eiffel-develop] Eiffel XML parser 'parse_from_string' implementation

[Eric B. <er...@go...>]

Glenn Maughan wrote:
> 
> I'm trying to convert to using the Eiffel XML parser in GOBO but need to use
> 'parse_from_string' as that is the routine I was using with the expat
> implementation. It is currently implemented as:
> 
>         parse_from_string (data: STRING) is
>                 do
>                         check
>                                 False   -- TODO
>                         end
>                 end
> 
> Anyone willing to implement it for me? Please!

I doesn't seem to be complicated (just 4 or 5 lines of code
to pass a string buffer instead of a file buffer to the parser),
but I won't have time to implement it before this weekend
(I'm on the road for business this week, and although I still
have email access, I don't have my usual development environment).

> Am I correct in assuming that the Eiffel parser will generate the same
> events as the expat parser? Does it handle namespace events correctly?

I don't know, I'm not familiar with this code.

> On the expat side, I found that Makefile.win.msc does not compile correctly
> using VC++ 6.0. I think it is because the eiffel.h header is expecting the
> symbol 'ise' to be defined but 'ISE' is defined instead. Must be
> case-sensitive in nmake.
> 
> Also the makefile builds the file 'libexml.lib' rather than the
> 'libexml-expat-${GOBO_EIFFEL}.a' as defined in the library/xml/cluster.xace
> file.
> 
> Finally, the <external> element in library/xml/cluster.xace uses braces '{}'
> rather than parenthesis '()' to surround environment variables for the
> externals. It also defines '-lexpat' as a link library. nmake does not seem
> to like either of these.
> 
> Perhaps there needs to be a few conditional <external> elements that depend
> on the OS for the expat clusters. A bit messy!

As you have noticed, the expat part of the XML library is
one part of the Gobo CVS code which has not been tried
yet. We will definitely have to do something here, the
first thing of course being to take your remarks and bug
fixes into account.

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

Re: [gobo-eiffel-develop] Bootstrap from CVS

[Eric B. <er...@go...>]

This is just to let everybody know that Glenn managed to
bootstrap using ISE in the end. There is no real reason
why it didn't work the first time.

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

[gobo-eiffel-develop] geant changes

[Sven E. <sve...@we...>]

I just made the following changes to geant:

1)
messages from the geant tasks/commands are suppressed by default now.
Those messages coming from the called external tools still apear.
If you want to see them use

  geant -v

or

  geant --verbose

2)
every task now supports the attributes "if", "unless" and "dir".
They have the same behaviour as those of the targets.

3)
There is a first version of a new task called <outofdate>. This
task can be used to determine if it is necessary to call another task.
An example of it's usage can be found in

  $GOBO/example/geant/misc/outofdate.eant

- Sven

Re: [gobo-eiffel-develop] Eiffel XML parser 'parse_from_string' implementation

[Sven E. <sve...@we...>]

"Glenn Maughan" <gle...@op...> schrieb am 16.10.01:
> I'm trying to convert to using the Eiffel XML parser in GOBO but need to use
> 'parse_from_string' as that is the routine I was using with the expat
> implementation. It is currently implemented as:
> 
> 	parse_from_string (data: STRING) is
> 		do
> 			check
> 				False   -- TODO
> 			end
> 		end
> 
> Anyone willing to implement it for me? Please!

I'll have a look at this.

> 
> Am I correct in assuming that the Eiffel parser will generate the same
> events as the expat parser? Does it handle namespace events correctly?

That should be the case but I cannot tell you more details since so far I did
not use the expat parser yet. Andreas Leitner has much more experience
with it so maybe he can answer your questions.

- Sven

_______________________________________________________________________
1.000.000 DM gewinnen - kostenlos tippen - http://millionenklick.web.de
Ih...@we..., 8MB Speicher, Verschluesselung - http://freemail.web.de

[gobo-eiffel-develop] Feature requests for gexace

[Glenn M. <gle...@op...>]

Great progress GOBO developers! I'm converting Goanna to use gexace and
geant and it will make it much easier to manage.

A general question first: Eric, do you want feature requests and bugs to be
sent to this list or logged on the SourceForge trackers? I'm all for the
SourceForge trackers...it increases the activity stats for the project and
makes them easy to track.

A couple of requests:

1) Would it be possible for gexace to generate Ace files for ISE that use
the nested cluster syntax rather than concatenating the parent and child
cluster names? For example, the Xace clusters:

	<cluster name="parent" location="my/path">
		<cluster name="child" location="subpath"/>
	</cluster>

could be generated as:

	parent: "my/path"
	child (parent): "$/subpath"

(if you are not familiar, the '$' in the 'child' cluster is replaced with
'my/path').
This allows the ISE environment to build a tree structure of clusters that
is much easier to navigate and quicker to display.

2) This may be a bug. The following Xace cluster:

	<cluster name="parent" location="my/path">
		<cluster name="my-child"/>
	</cluster>

generates:

	parent: "my/path"
	my-child: "my/path/my-child"

The cluster name 'my-child' is invalid in ISE. Perhaps it needs to be
converted to 'my_child'.

[gobo-eiffel-develop] Eiffel XML parser 'parse_from_string' implementation

[Glenn M. <gle...@op...>]

I'm trying to convert to using the Eiffel XML parser in GOBO but need to use
'parse_from_string' as that is the routine I was using with the expat
implementation. It is currently implemented as:

	parse_from_string (data: STRING) is
		do
			check
				False   -- TODO
			end
		end

Anyone willing to implement it for me? Please!

Am I correct in assuming that the Eiffel parser will generate the same
events as the expat parser? Does it handle namespace events correctly?

On the expat side, I found that Makefile.win.msc does not compile correctly
using VC++ 6.0. I think it is because the eiffel.h header is expecting the
symbol 'ise' to be defined but 'ISE' is defined instead. Must be
case-sensitive in nmake.

Also the makefile builds the file 'libexml.lib' rather than the
'libexml-expat-${GOBO_EIFFEL}.a' as defined in the library/xml/cluster.xace
file.

Finally, the <external> element in library/xml/cluster.xace uses braces '{}'
rather than parenthesis '()' to surround environment variables for the
externals. It also defines '-lexpat' as a link library. nmake does not seem
to like either of these.

Perhaps there needs to be a few conditional <external> elements that depend
on the OS for the expat clusters. A bit messy!

Glenn.

Re: [gobo-eiffel-develop] Bootstrap from CVS

[Eric B. <er...@go...>]

Glenn Maughan wrote:
> 
> No other version of geyacc.exe was in the path.

This is strange. Can you send me (to my private email 
address) the generated class GEPP_TOKENS? It should
say:

  generator: "geyacc version 2.1"

in the indexing clause and it should include the
routine `token_name'.

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

Re: [gobo-eiffel-develop] XML library compilation error

[Eric B. <er...@go...>]

Glenn Maughan wrote:
> 
> The following routine from class XP_API refers to an undefined 'str'. I
> assume it is supposed to be 'base'.

Yes, you're right. I just checked it with the old eXML code.
I will fix it in the CVS code.

--
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

[gobo-eiffel-develop] XML library compilation error

[Glenn M. <gle...@op...>]

The following routine from class XP_API refers to an undefined 'str'. I
assume it is supposed to be 'base'. It compiles clean after this change.

-----------------------------
	exml_XML_SetBase_string (parser_handle: POINTER; base: STRING): BOOLEAN is
			-- Sets the base to be used for resolving relative URIs in
			-- system identifiers in declarations.  Resolving relative
			-- identifiers is left to the application: this value will be
			-- passed through as the base argument to the
			-- XM_ExternalEntityRefHandler, XML_NotationDeclHandler and
			-- XM_UnparsedEntityDeclHandler. The base argument will be
			-- copied.
			-- Returns zero if out of memory, non-zero otherwise.
		require
			parser_handle_not_null: parser_handle /= default_pointer
			base_not_void: base /= Void
		local
			c_str: ANY
		do
			c_str := str.to_c
			Result := ext_exml_XML_SetBase (parser_handle, $c_str)
		end
-----------------------------

Glenn.

RE: [gobo-eiffel-develop] Bootstrap from CVS

[Glenn M. <gle...@op...>]

> Did the bootstrap procedure correctly generate a 'geyacc.exe'
> in $GOBO/bin? If so it looks like an old version of 'geyacc.exe'
> (probably the one from the Gobo 2.0 delivery) is still in your
> path before the one in $GOBO/bin.

Eric,

No other version of geyacc.exe was in the path. 

Glenn.

[gobo-eiffel-develop] Re: Re: CDATA

[Sven E. <sve...@we...>]

"Sven Ehrke" <sve...@we...> schrieb am 14.10.01:
> er...@go... schrieb am 14.10.01:
> > OK, I'll try to implement that in the parser. BTW, is it
> > allowed to have CDATA in the string value of attributes
> > like that?
> 
> Hmm, I just tried it with Netscape 6.1. It does accept them between
> the element tags but not in the attributes. I'll try to find out more
> about this tomorrow when I have to proper tools available.

My big XML book says it's not allowed. I made up a small example
(using XML authority, and XML Spy):

________________ DTD__________________
<?xml version='1.0' encoding='UTF-8' ?>

<!--Generated by XML Authority-->

<!ELEMENT e1 (#PCDATA)>
<!ATTLIST e1  a1 CDATA  #IMPLIED >
_______________________________________

I was hoping that defining a1 as CDATA (character data)
instead of PCDATA (parsed character data) would help
but XML Spy says that the following XML document:
___________________________________________
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE e1 SYSTEM "D:\tmp\e1.dtd">
<e1 a1="<![CDATA[jjj]]>"><![CDATA[jjj]]></e1>
___________________________________________
is not even well formed. Using CDATA within the body
of the elements (second CDATA in the example) is ok.
Generally markup is not allowed for attributes.
This might be another argument for rather using
elements than attributes.

So in summary I think at least some entities should
be supported by an Eiffel XML parser and the CDATA
as well for the elements.
 
- Sven






_______________________________________________________________________
1.000.000 DM gewinnen - kostenlos tippen - http://millionenklick.web.de
Ih...@we..., 8MB Speicher, Verschluesselung - http://freemail.web.de

Re: Re: [gobo-eiffel-develop] Re: Re: CDATA

[Sven E. <sve...@we...>]

er...@go... schrieb am 14.10.01:

> Hmmm, I don't know what to say. This is not what I sent.
> Although there is the same thing in the mailing list archive,
> I received from the mailing list the exact message that
> I sent. So let me try it again:
> 
>     <getest config="getest.cfg"
>       compile="geant compile_ise &.gt.; xcompile.log 2&.gt.;.&.amp.;1"/>
> 
> Please remove the . characters, they are just here to avoid
> the entity expansion.

I got all mails correctly with MS outlook in my office. But when I look at the archive with
the browser (NS 6.1, NS 4.7) the entities get expanded, probably because they are html
entities as well.

- Sven

_______________________________________________________________________
1.000.000 DM gewinnen - kostenlos tippen - http://millionenklick.web.de
Ih...@we..., 8MB Speicher, Verschluesselung - http://freemail.web.de

Re: Re: [gobo-eiffel-develop] Re: Re: CDATA

[Sven E. <sve...@we...>]

er...@go... schrieb am 14.10.01:

> Hmmm, I don't know what to say. This is not what I sent.
> Although there is the same thing in the mailing list archive,
> I received from the mailing list the exact message that
> I sent. So let me try it again:
> 
>     <getest config="getest.cfg"
>       compile="geant compile_ise &.gt.; xcompile.log 2&.gt.;.&.amp.;1"/>

Now I see :-)

> 
> Please remove the . characters, they are just here to avoid
> the entity expansion.

I can imagine that the problem is that I am using a web interface
as email client. I'll see tomorrow what I can do about that.
Sorry for the confusion.

> 
> > But personally I find the CDATA version more readable.
> 
> OK, I'll try to implement that in the parser. BTW, is it
> allowed to have CDATA in the string value of attributes
> like that?

Hmm, I just tried it with Netscape 6.1. It does accept them between
the element tags but not in the attributes. I'll try to find out more
about this tomorrow when I have to proper tools available.

> I understand that your Eiffel implementation of the XML parser
Just for completeness: Andreas put a lot of work in as well.

> is a minimal implementation. I think that the long term solution
> would be to replace it and integrate the full-fledge Eiffel
> implementation of the XML parser developed by Franck Arnaud
> instead.

I have to admit that I did not look at it yet.
I would appreciate switching to a full-fledge Eiffel version very
much. I'll try to have a look at it soon.

- Sven




_______________________________________________________________________
1.000.000 DM gewinnen - kostenlos tippen - http://millionenklick.web.de
Ih...@we..., 8MB Speicher, Verschluesselung - http://freemail.web.de

Re: [gobo-eiffel-develop] Re: Re: CDATA

[Eric B. <er...@go...>]

Sven Ehrke wrote:
> 
> > Of course you cannot understand: it seems that the entities
> > that I put in my previous message have been interpreted
> > either on my side or your side by the mail tool. Here is
> > again what I wrote, in the hope that it will appear correctly
> > this time:
> >
> >    <getest config="getest.cfg"
> >      compile="geant compile_ise > xcompile.log 2>&1"/>
> 
> Sorry for my stupidity but I still cannot see the
> xml entity in the compile attribute.

Hmmm, I don't know what to say. This is not what I sent.
Although there is the same thing in the mailing list archive,
I received from the mailing list the exact message that
I sent. So let me try it again:

    <getest config="getest.cfg"
      compile="geant compile_ise &.gt.; xcompile.log 2&.gt.;.&.amp.;1"/>

Please remove the . characters, they are just here to avoid
the entity expansion.

> So with the support of entities it probably would look like this
> (I hope it comes through the mail proberly):
> 
>    <getest config="getest.cfg"
>      compile="geant compile_ise &gt; xcompile.log 2&gt;&1"/>
> 
> Maybe the ampersand has to replaced by an entity as well (I cannot
> remeber the symbol for it right now).

Yes, this is what I'm trying to say since the begining,
but somehow the entities are expanded when you receive them.
Note that even though the above is a quote from your message,
the entities may appear expanded again when you will receive
them ;-(

> But personally I find the CDATA version more readable.

OK, I'll try to implement that in the parser. BTW, is it
allowed to have CDATA in the string value of attributes
like that?

> > > If you are talking about
> > > xml entities you are right: they are not handled.
> >
> > But they should, no?
> 
> Yes, would be nice. But the current implementation does not support
> many features of a professional XML parser. But we can add missing
> features as we need them.

I understand that your Eiffel implementation of the XML parser
is a minimal implementation. I think that the long term solution
would be to replace it and integrate the full-fledge Eiffel
implementation of the XML parser developed by Franck Arnaud
instead.

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com