Gobo Eiffel Project

franck@... writes:

> What do you think of having both?

Good :-)


> I've noticed I forgot a few things in the previous proposal, so here 
> it is fixed, with document start/finish event, and an error event.
> 
> XI_CALLBACKS -- + _FILTER version with next
>           -- all parameters are strings
>           -- ns = "" just out of the parser
>           -- pre = "" when no prefix
>        on_start -- document wide
>        on_finish
>        on_comment (content)
>        on_processing_instruction (name, content)
>        on_start_tag (ns,pre,local)
>        on_attribute (ns,pre,local,value)
>        on_start_tag_finish
>        on_end_tag (ns,pre,local)
>        on_content_string (content)
>        on_error (error)
> 
> XI_STRUCTURED_CALLBACKS -- + _FILTER version with next
>        on_comment (content: STRING) -- needed? PI?
>        on_start_tag (name: XI_NAME; attributes: DS_HASH_TABLE[STRING,XI_NAME])
>        on_end_tag -- no name needed, validated upstream
>        on_content_string (content) -- could have a req that never two in a row
>        on_error (error)

Both callbacks can be converted to each other with the proper filter I
think. Such a filter should be provided.

I'm not sure STRUCTURED callbacks are a good thing. Perhaps call them
SAX_CALLBACK or EXPAT_CALLBACK or so? I don't know if it is really
SAX, it looks a bit like it.


> Is document start finish needed in the structured version? Also we 
> may need to find a good signature for the error event.

Yes please.


-- 
Groetjes,

Berend. (-:

Berend de Boer:
> Both callbacks can be converted to each other with the proper filter I
> think. Such a filter should be provided.

Yes of course.

> I'm not sure STRUCTURED callbacks are a good thing. Perhaps call them
> SAX_CALLBACK or EXPAT_CALLBACK or so? I don't know if it is really
> SAX, it looks a bit like it.

It's not really expat specific (I still think expat's interface should 
issue 
unstructured events, but both are possible). It's not SAX either, SAX does 
not deal with namespaces I think (so is less structured).

I agree "structured callbacks" is not a good name, but putting expat or 
sax in 
the name would be worse. Anyone with something better? Maybe invert 
names:

XI_RAW_CALLBACKS
XI_CALLBACKS

?

> > Is document start finish needed in the structured version? Also we 
> Yes please.

OK.

--
franck@...

Franck Arnaud wrote:
>
>  Anyone with something better? Maybe invert names:
> 
> XI_RAW_CALLBACKS
> XI_CALLBACKS
> 
> ?

 XI_CALLBACKS
 XI_PREPROCESSED_CALLBACKS

 XI_CALLBACKS
 XI_COMPOUNDED_CALLBACKS

The advantage of your suggestion is that it
gives shorter class names.

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

"Franck Arnaud" <franck@...> writes:

> > I'm not sure STRUCTURED callbacks are a good thing. Perhaps call them
> > SAX_CALLBACK or EXPAT_CALLBACK or so? I don't know if it is really
> > SAX, it looks a bit like it.
> 

> It's not really expat specific (I still think expat's interface
> should issue unstructured events, but both are possible). It's not
> SAX either, SAX does not deal with namespaces I think (so is less
> structured).

Right.


> I agree "structured callbacks" is not a good name, but putting expat or 
> sax in 
> the name would be worse. Anyone with something better? Maybe invert 
> names:
> 
> XI_RAW_CALLBACKS
> XI_CALLBACKS

This scheme implies that somehow getting events for attributes is more
or less easy/simple to use than otherwise, which might not be the
case. It's just a different interface.

But I've to admit I've not a better proposal yet. Perhaps just
XI_SCHEME1_CALLBACK versus XI_SCHEME2_CALLBACK.

-- 
Groetjes,

Berend. (-:

On 01/10/27 1:29 PM, "Berend de Boer" <berend@...> wrote:

> "Franck Arnaud" <franck@...> writes:
> 
>>> I'm not sure STRUCTURED callbacks are a good thing. Perhaps call them
>>> SAX_CALLBACK or EXPAT_CALLBACK or so? I don't know if it is really
>>> SAX, it looks a bit like it.
>> 
> 
>> It's not really expat specific (I still think expat's interface
>> should issue unstructured events, but both are possible). It's not
>> SAX either, SAX does not deal with namespaces I think (so is less
>> structured).
> 
> Right.

SAX2 actually does deal with namespaces.

Cheers,
Bob

>So the idea is to have the raw interface emit data without namespace 
>resolution. All you get is prefix and name as seperate strings.
>Whereas in the structured interface, you also have the namespaces resolved, 
>as in, you get the URI for the prefix.
>Why should we make this distinction. If the raw interface does not resolve 
>namespaces, why should the structured.

Do you mean that the child element of the following XML:

<parent xmlns:pre="http://other.com">
    <pre:child>Mary</pre:child>
</parent>

Will be have the structure:

    localname="child"
    prefix="http://other.com"

This seems to mean that we loose information. The original element prefixes 
are lost. The process would no longer be transitive. ie, we cannot generate 
exactly the original XML because we no longer know what the original 
prefixes were.

The W3C DOM holds 'localname', 'prefix' and 'namespaceUrl'. Thus retaining 
all of the original information. Setting the 'namespaceUrl' for each element 
would be what I consider to be "namespace resolution".

Also what happens with default namespaces?

I am also interested in how the parser will treat namespace attributes. ie, 
will the 'xmlns:pre' attribute above generate a standard attribute callback 
(or be passed as an attribute in the attribute structure, as the case may 
be). I would like them to be retained as normal attributes also.

Hopefully I'm not completely off track! Please set me straight if I am.

Thanks.
Glenn.


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

On Wed, Nov 14, 2001 at 03:40:53PM +1100, Glenn Maughan wrote:
> >as in, you get the URI for the prefix.
> >Why should we make this distinction. If the raw interface does not resolve 
> >namespaces, why should the structured.
> 
> Do you mean that the child element of the following XML:
> 
> <parent xmlns:pre="http://other.com">
>    <pre:child>Mary</pre:child>
> </parent>
> 
> Will be have the structure:
> 
>    localname="child"
>    prefix="http://other.com"

No it would be:

	localname="child"
	prefix="pre"


> This seems to mean that we loose information. The original element prefixes 
> are lost. The process would no longer be transitive. ie, we cannot generate 
> exactly the original XML because we no longer know what the original 
> prefixes were.
> 
> The W3C DOM holds 'localname', 'prefix' and 'namespaceUrl'. Thus retaining 
> all of the original information. Setting the 'namespaceUrl' for each element 
> 
> would be what I consider to be "namespace resolution".

To find the URI (namespace) for a given prefix. I guess we are using different nameing conventions here.

For now in GOBO XML namespaces can only be resolved in the tree parser. But I do agree that it also makes sense to resolve them in the event parser, but it would be nice if this step could be optional, and be implemented via a filter.

> Also what happens with default namespaces?

Finding the correct URL would be the task of the namespace resolver.

> I am also interested in how the parser will treat namespace attributes. ie, 
> will the 'xmlns:pre' attribute above generate a standard attribute callback 
> (or be passed as an attribute in the attribute structure, as the case may 
> be). I would like them to be retained as normal attributes also.

Good question. Actually we do not loose information if we strip those attributes out. In the current tree namespace resolver the striping is optional. Maybe we can keep such a flag for the event based namespace resolver as well.
 
regards,
Andreas

Have you guys considered this namespace resolution given the position taken
by this document: http://www.w3.org/TR/xml-infoset/

A few things:
- the namespace qualifier is not the namespace, the URI is
- the xmlns and xmlns:xx attributes are special

Speaking as someone who would *only* use the event processor...

It is important to provide the whole infoset to every client of the parser.
This includes the tree parser. I strongly believe that not resolving the
namespaces is a false economy. Every application that is namespace aware
needs the namespace, and not necessarily the namespace qualifier or the
qualified name.

The xmlns and xmlns:xx attributes are special, and in my opinion, should not
be mixed in with the normal attributes.

Cheers,
Bob

On Wed, 2001-11-14 at 14:15, Bob Hutchison wrote:
> 
> Have you guys considered this namespace resolution given the position taken
> by this document: http://www.w3.org/TR/xml-infoset/

Thanks. This is a very good read. I just glanced over it, but will read
it again more carefully.

> A few things:
> - the namespace qualifier is not the namespace, the URI is

this is how GOBO XML behaves currently. A named node has a `ns_prefix'
giving you the prefix that was used to refere to a namespace if any
("ns_" is needed because "prefix" is a reserved word in Eiffel), it has
an attribute `namespace', which referse to the namespace addressed by
prefix in the given context (if any) - in the URL above this would be
the "namespace name", and it has a attribute `name' which is the name of
the node without the collon and the prefix ("local" in the above URL -
now I know why Frank came up with `local' in his postings :)

I guess in order to comply to this URL (which makes sense) we should
really use the tripple: `locale', `namespace' and `prefix' (this
renaming `name' to `locale'.

> - the xmlns and xmlns:xx attributes are special

Now the URL has an interesting view on this. Not hiding xmlns:xx
attributes, but reporting them distinct from the regular attributes.
This would map to an event of it's own in the event based parser. I
could live with that, to say at least (;

> Speaking as someone who would *only* use the event processor...
> 
> It is important to provide the whole infoset to every client of the parser.
> This includes the tree parser. I strongly believe that not resolving the
> namespaces is a false economy. Every application that is namespace aware
> needs the namespace, and not necessarily the namespace qualifier or the
> qualified name.

Yes, but there are other reasons for seperating the namespace resolver
as a filter:

Given we have X implementations of XML parser, which do no resolve
namespaces. They choose not to do so, because they all use the provided
namespace resolving filter. Thus they reuse code, makeing each parser
implementation more trivial and thus avoid uneccessary errors.

> The xmlns and xmlns:xx attributes are special, and in my opinion, should not
> be mixed in with the normal attributes.

Good point.

thanks for your input,
Andreas

On 01/11/14 9:35 AM, "Andreas Leitner" <nozone@...> wrote:

> On Wed, 2001-11-14 at 14:15, Bob Hutchison wrote:
>> 
>> Have you guys considered this namespace resolution given the position taken
>> by this document: http://www.w3.org/TR/xml-infoset/
> 
> Thanks. This is a very good read. I just glanced over it, but will read
> it again more carefully.

It gets better on the third or fourth read I've found :-) It clarifies a
lot.

> 
>> A few things:
>> - the namespace qualifier is not the namespace, the URI is
> 
> this is how GOBO XML behaves currently. A named node has a `ns_prefix'
> giving you the prefix that was used to refere to a namespace if any
> ("ns_" is needed because "prefix" is a reserved word in Eiffel), it has
> an attribute `namespace', which referse to the namespace addressed by
> prefix in the given context (if any) - in the URL above this would be
> the "namespace name", and it has a attribute `name' which is the name of
> the node without the collon and the prefix ("local" in the above URL -
> now I know why Frank came up with `local' in his postings :)
> 
> I guess in order to comply to this URL (which makes sense) we should
> really use the tripple: `locale', `namespace' and `prefix' (this
> renaming `name' to `locale'.

I'm much more comfortable with this. "locale" though? or "local"?

> 
>> - the xmlns and xmlns:xx attributes are special
> 
> Now the URL has an interesting view on this. Not hiding xmlns:xx
> attributes, but reporting them distinct from the regular attributes.
> This would map to an event of it's own in the event based parser. I
> could live with that, to say at least (;
> 
>> Speaking as someone who would *only* use the event processor...
>> 
>> It is important to provide the whole infoset to every client of the parser.
>> This includes the tree parser. I strongly believe that not resolving the

I meant the event parser here (I wasn't trying to be obnoxious :-)

>> namespaces is a false economy. Every application that is namespace aware
>> needs the namespace, and not necessarily the namespace qualifier or the
>> qualified name.
> 
> Yes, but there are other reasons for seperating the namespace resolver
> as a filter:
> 
> Given we have X implementations of XML parser, which do no resolve
> namespaces. They choose not to do so, because they all use the provided
> namespace resolving filter. Thus they reuse code, makeing each parser
> implementation more trivial and thus avoid uneccessary errors.

Within the parser framework I'm all for it (at least as a general
principal). I don't think the applications should have to worry about this
-- just resolve it.

In this particular case though? I think that namespace resolution isn't
really open to a lot of interpretation (given that it is pretty precisely
defined). This might be more work than it is worth (but you never know).

> 
>> The xmlns and xmlns:xx attributes are special, and in my opinion, should not
>> be mixed in with the normal attributes.
> 
> Good point.
> 
> thanks for your input,
> Andreas
> 
> 
> 
> _______________________________________________
> gobo-eiffel-develop mailing list
> gobo-eiffel-develop@...
> https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop

>Why would `uri' need a class of it's own, when `local_part' does not?
>Maybe I am missing something, but wouldn't
>--
>class NAME feature uri: STRING local_part: STRING end
>--

Shouldn't the types be UC_STRING? Or are we going with NenieXML style 
unicode support?

By the way, is anyone working on support for streaming different character 
encodings and transformation between them?

Glenn.



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

On Tue, 2001-11-20 at 05:32, Glenn Maughan wrote:
> >Why would `uri' need a class of it's own, when `local_part' does not?
> >Maybe I am missing something, but wouldn't
> >--
> >class NAME feature uri: STRING local_part: STRING end
> >--
> 
> Shouldn't the types be UC_STRING? Or are we going with NenieXML style 
> unicode support?

Yes it should. I think we all agreed on the following plan regarding
unicode support (and I hope I got things right, and this is really what
everybody agreed on :)

*) Stick with UC_ for now
*) Eric said he is going to prototype a version of UC_STRING where it
inherits from STRING
*) If this approach prooves to work, we can switch the interface to
STRING. GOBO XML will internally still use (or better create) UC_STRING
objects and unicode handling will be right, but the user won't notice. 

 
> By the way, is anyone working on support for streaming different character 
> encodings and transformation between them?

What exactly do you mean by that? Streaming via the new kernel i/o
cluster? Using UC_STRING or STRING? Sorry, it is quite late (;

regards,
Andreas

Andreas Leitner <nozone@...> writes:

> Yes it should. I think we all agreed on the following plan regarding
> unicode support (and I hope I got things right, and this is really what
> everybody agreed on :)
> 
> *) Stick with UC_ for now
> *) Eric said he is going to prototype a version of UC_STRING where it
> inherits from STRING

I've missed this one, what's the advantage?

The advantage of UC_STRING, as far as I'm aware, is that one can
optimize the encoding. I.e. one should be able to say this program
is best served by an 16-BIT encoding, so the underlying encoding is
16-BIT. For other program's the memory usage would be to much and it
could specify 8-BIT encodings.

This way you can nicely optimize for speed/memory, depending on the
situation. And with UC_STRING you can switch 16 or 8 bit encodings on
the fly.

I do not hope that with STRING we always will use UTF8 or something
like that. 

Also STRING isn't particularly optimized as it's memory allocation
scheme waste's up to 50%. With UC_STRING we can do much better, see my
post several months ago.


-- 
Groetjes,

Berend. (-:

Berend de Boer wrote:
> 
> Andreas Leitner <nozone@...> writes:
> 
> > Yes it should. I think we all agreed on the following plan regarding
> > unicode support (and I hope I got things right, and this is really what
> > everybody agreed on :)
> >
> > *) Stick with UC_ for now
> > *) Eric said he is going to prototype a version of UC_STRING where it
> > inherits from STRING
> 
> I've missed this one,

I didn't talked about that in this mailing list yet, because
as Franck already suggested many times, it's better to do
some proof of concept and benchmarks before having harsh
discussions on false assumptions. So I won't enter the debate
now before I found time to do the prototyping Andreas talked
about.

> what's the advantage?

Don't have to convert strings again and again. OK, I said
that I would say nothing before having a proof of context,
but now I'm forced to expose part of the idea ;-( Damn,
I hate discussing things too early like that since it might
be a waste of time if the proof of concept fails (in particular
I'm not sure whether all Eiffel compilers accept to have
heirs of STRING). So, here is the inheritance graph:

             STRING
               ^
               |
            UC_STRING*
              ^  ^ 
             /    \ 
 UC_UTF8_STRING   UC_UTF16_STRING  ...

That way one can have:

  f (s: STRING)

and be able to call it with:

  f ("foo")

or:

  ucs: UC_STRING
  f (ucs)

Sorry, I don't want to enter into the details at this stage.

> The advantage of UC_STRING, as far as I'm aware, is that one can
> optimize the encoding. I.e. one should be able to say this program
> is best served by an 16-BIT encoding, so the underlying encoding is
> 16-BIT. For other program's the memory usage would be to much and it
> could specify 8-BIT encodings.

I think we could do that as well.

> This way you can nicely optimize for speed/memory, depending on the
> situation. And with UC_STRING you can switch 16 or 8 bit encodings on
> the fly.

Conversion routines are possible.

> I do not hope that with STRING we always will use UTF8 or something
> like that.

No.

> Also STRING isn't particularly optimized as it's memory allocation
> scheme waste's up to 50%.

I'm not sure I understand what you mean here. Are you
talking about STRING, or UTF8-in-STRING as Franck suggested
a few months ago? Note that what I want to prototype is
a different design from UTF8-in-STRING.

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

Eric Bezault wrote:
> 
>              STRING
>                ^
>                |
>             UC_STRING*
>               ^  ^
>              /    \
>  UC_UTF8_STRING   UC_UTF16_STRING  ...

For those who are reading closely the various threads in this
mailing list, you might have noticed that on one side I argue
that inheritance should be banned, and here I suggest inheriting
from STRING. Isn't it contradictory? ;-)

Here is a small story: one of my previous project leaders was
always arguing the reverse of what I was suggesting. For
example if I said white he would say black, and we would
strongly argue on that during the day. Then after a night
of thought I would come back at work the next morning
convinced by his arguments of the day before. So I would
say that he was right and I said black. But then he would
change his position and argue that I was right and would
white. And we would argue again the whole day white
against black, except that we reversed our roles between
the two consecutive days. And this could last several days
like that. The moral of the story is not that my project
leader was convinced by one position or another, but he
would just play the role which would contradict my arguments,
whatever they were, just to force me to think very hard
about the pros and cons of both sides. He was the best
project leader I ever had.

So as the graph above shows, I'm not against inheritance,
I just played the role which would contradict as much as
possible Andreas' arguments, and pushing the game to
be as extremist as possible in this role. Unfortunately
Andreas didn't change his way of thinking and argue
against inheritance, so I was not given a chance to
play the other role and argue in favor of inheritance ;-(
Anyway, I hope that the discussion was necessary to
realize that XI_ATTRIBUTES was not exactly a table, and
not exactly a set, although it shares many functionalities.
BTW, Andreas played his role to the extreme as well, arguing
that everything is a container. I'm not saying that it is
not true, just that it is an extreme point of view, in the
same way that it was extreme to say that inheritance 
should be avoided just because transitions are not as
smooth as with client/supplier and the obsolete clause.

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

Eric Bezault <ericb@...> writes:

> > Also STRING isn't particularly optimized as it's memory allocation
> > scheme waste's up to 50%.
> 
> I'm not sure I understand what you mean here. Are you
> talking about STRING, or UTF8-in-STRING as Franck suggested
> a few months ago? Note that what I want to prototype is
> a different design from UTF8-in-STRING.

It was the article about smart memory allocation I send you a while
back. If a character is added to a string, it just allocates twice as
much memory (or 50% as much, or some variant) and proceeds.

With UC_STRING we have the ability to control a little bit better such
memory allocation schemes for cases you have a lot of string
processing to do.

-- 
Groetjes,

Berend. (-:

Berend de Boer wrote:
> 
> It was the article about smart memory allocation I send you a while
> back. If a character is added to a string, it just allocates twice as
> much memory (or 50% as much, or some variant) and proceeds.
> 
> With UC_STRING we have the ability to control a little bit better such
> memory allocation schemes for cases you have a lot of string
> processing to do.

Since it is not UTF8-in-STRING but UC_STRING inheriting from
STRING that I want to prototype, such control could still
be done in class UC_STRING. Again I don't want to have a
long discussion on that before I know that it is doable, but
with this design I think that you will still be able to
use class UC_STRING as you do now if you want, but in addition
it will also allow authors of supplier classes to write
routines which accept both regular strings and UC_STRING
with a single interface (instead of having one interface 
for STRING and another interface for UC_STRING, or explicitly
having to convert strings to UC_STRING, as we would have to
do now).

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

Eric Bezault <ericb@...> writes:

> Since it is not UTF8-in-STRING but UC_STRING inheriting from
> STRING that I want to prototype, such control could still
> be done in class UC_STRING. 

My only concern.


> use class UC_STRING as you do now if you want, but in addition
> it will also allow authors of supplier classes to write
> routines which accept both regular strings and UC_STRING
> with a single interface (instead of having one interface 
> for STRING and another interface for UC_STRING, or explicitly
> having to convert strings to UC_STRING, as we would have to
> do now).

Sounds interesting. So goodluck with the experiment.

-- 
Groetjes,

Berend. (-:

Berend:

> Nonetheless I backed this up with an example how
> much code you have to write with the atomic interface compared to the
> structured interface.

And I came up with a reply showing that with very few lines 
of code the atomic interface behaves like your (semi-)
structured one. So I'm not convinced.

In any case, all code in the library itself should work well 
with the atomic interface, and any atomic->structured filter 
can easily be added on whenever needed.

Berend:

>For performance I sacrifice everything.

But not Eiffel, garbage collection, OO? All of these things 
slow you down :-).

franck@... writes:

> >For performance I sacrifice everything.
> 
> But not Eiffel, garbage collection, OO? All of these things 
> slow you down :-).

Actually, garbage collection speeds things up compared to reference
counting you get with most other languages. And you have a lot more
control over strings in Eiffel than in Delphi for example which does
all kinds of horrible things behind the scenes.

And anyway code writing performance is greatly improved with Eiffel :-)

-- 
Groetjes,

Berend. (-: