Gobo Eiffel Project

Colin Paul Adams:

> This is a UTF-8 BOM, and should be recognized by the parser as such
> (and so trigger UTF-8 recognition). 

Interesting! UTF-8 is the default, so it's a bit pointless. I see that 
the 3rd edition of the XML recommendation does allow this explicitly, 
but the 2nd edition seems rather ambiguous and I think my interpretation 
was within the 2nd edition spec. I'd bet that other parsers will also 
behave like this (presumably, hence the correction in the 3rd edition).

Anyway, I'll fix it of course.

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

    Franck> I see that the 3rd edition of the XML
    Franck> recommendation does allow this explicitly, but the 2nd
    Franck> edition seems rather ambiguous and I think my
    Franck> interpretation was within the 2nd edition spec. I'd bet
    Franck> that other parsers will also behave like this

The Unicode FAQ is very explicit the about a UTF-8 BOM.
-- 
Colin Paul Adams
Preston Lancashire

Colin Paul Adams:

> The Unicode FAQ is very explicit the about a UTF-8 BOM.

It is not sufficient though. It says a BOM is allowed in UTF-8, 
but also that a protocol can require or forbid it. In fact my 
current implementation allows it, and then the file is like 
this:

rubbish <?xml version= ...

and the XML syntax does not allow "rubbish" (be it a BOM or something 
else) to be there. So this issue must be specified in XML too, because 
you must proactively remove it, and it is indeed in the third edition.

I see that in Markus Kuhn's UTF-8 FAQ that he says it's a Microsoft 
idea (ah!) and strongly suggests not to use it on Unix (which does not 
prevent from accepting it on input of course).

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

    Franck> I see that in Markus Kuhn's UTF-8 FAQ that he says it's a
    Franck> Microsoft idea (ah!) and strongly suggests not to use it
    Franck> on Unix (which does not prevent from accepting it on input
    Franck> of course).

This is the problem, of course. FXSL contains some data files with
UTF-8 BOMs.
I've been pyhsically removing them.

Incidentally, FXSL (a demonstration that XSLT is fully a pure
functional language) has been finding lots of bugs in gexslt, since it
stresses tail recursion and lazy evaluation. So I haven't got round to
the date parsing yet (Bugs first, then additional functionality).

Working now, though.
-- 
Colin Paul Adams
Preston Lancashire

The UTF-8 BOM support is now in CVS.

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

    Franck> The UTF-8 BOM support is now in CVS.
and works here fine. Thanks.
-- 
Colin Paul Adams
Preston Lancashire

Franck Arnaud wrote:
> I have tested SE 2.1 beta 2. They have fixed 2 of my 
> reported bugs (FILE flush and empty substring), the others 
> are unchanged, and added 1 new non-ELKS "feature":
> 
> This is changing DOUBLE.floor to return DOUBLE instead of 
> INTEGER. While this is probably ideally better than 
> the ELKS choice (where you can't floor big numbers), that's 
> another portable routine gone. Among the working clusters, 
> it's only used in library/string a few times, and I've 
> found this workaround:
> 
>  floor_to_integer (d: DOUBLE): INTEGER is
>     -- INTEGER floor 
>     -- (floor is floating point with SE2, integer in ELKS)
>    do
>      Result := d.truncated_to_integer
>      if d.floor /= Result then
>        Result := Result - 1
>      end
>    ensure
>      definition: Result = d.floor
>    end
> 
> The problem is that truncated_to_integer behaves like "ceiling" 
> for negative numbers. The solution uses the fact that you can 
> still compare INTEGERs and REALs even if you can't assign 
> without an explicit truncated_to_integer (which would require 
> a ifdef).
> 
> Can I add this routine to KL_DOUBLE_ROUTINES?

OK. Shouldn't we put a precondition ensuring that the
result fits into an INTEGER? Something like:

     d_large_enough: d >= Platform.Minimum_integer_value
     d_small_enough: d < (Platform.Maximum_integer_value + 1.0)

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

Eric Bezault:

> OK. Shouldn't we put a precondition ensuring that the
> result fits into an INTEGER? Something like:
> 
>      d_large_enough: d >= Platform.Minimum_integer_value
>      d_small_enough: d < (Platform.Maximum_integer_value + 1.0)

Indeed, this is now in. This adds some positive point to 
having this function, as this is not checked by the 
compilers' native routines.

>>>>> "Eric" == Eric Bezault <ericb@...> writes:

    Eric> Shouldn't these classes go to their own cluster?  Something
    Eric> like library/time/formatter/? We already have several
    Eric> clusters in other libraries with that name. Otherwise, just
    Eric> library/time/format/ is fine.

library/time/format/ sounds better to me, as the _PARSER classes are
not doing any formatting.
-- 
Colin Paul Adams
Preston Lancashire

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

    Franck> As for zoned time and date without the other,
    Franck> DT_ZONED_TIME sounds OK, but zoned dates should probably
    Franck> be handled with time = midnight in DT_ZONED_DATE_TIME,
    Franck> because it seems to me a date on its own can't be
    Franck> meaningfully processed with a time zone without a time.

Yes, they can. It's set out in XML Schema.
-- 
Colin Paul Adams
Preston Lancashire

Colin Paul Adams:

>     Franck> because it seems to me a date on its own can't be
>     Franck> meaningfully processed with a time zone without a time.
> 
> Yes, they can. It's set out in XML Schema.

It says:

| Timezoned date values track the starting moment of their day

which makes sense, and I think may best be expressed by 
DT_ZONED_DATE_TIME with time set to 00:00:00 rather than 
a date without time. Well there could be a zoned date object, 
but I don't see the point as it must have an implicit time, 
so it can as well be explicit.

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

    Franck> | Timezoned date values track the starting moment of their
    Franck> day

    Franck> which makes sense, and I think may best be expressed by
    Franck> DT_ZONED_DATE_TIME with time set to 00:00:00 rather than a
    Franck> date without time. Well there could be a zoned date
    Franck> object, but I don't see the point as it must have an
    Franck> implicit time, so it can as well be explicit.

If it is explicit, then you can compare the embedded DT_DATE_TIME with
another DT_DATE_TIME, but this is not a proper thing to do, I think,
because all the zoned date tracks the starting moment of the day, it
is not conceptually that moment in calendar time.

2004-11-22Z < 2004-11-22T07-39-22Z

would then evaluate to True, but rather these should be considered as
incomparable.
After all, if you were to parse the zoned date-time and then convert
it to a zoned date, the two zoned dates would (correctly) compare as
equal.
 
So I think it should be implicit.
-- 
Colin Paul Adams
Preston Lancashire

Colin Paul Adams:

> If it is explicit, then you can compare the embedded DT_DATE_TIME with
> another DT_DATE_TIME, but this is not a proper thing to do, I think,
> because all the zoned date tracks the starting moment of the day, it
> is not conceptually that moment in calendar time.
> 
> 2004-11-22Z < 2004-11-22T07-39-22Z
> 
> would then evaluate to True, but rather these should be considered as
> incomparable.

You have a point.

> After all, if you were to parse the zoned date-time and then convert
> it to a zoned date, the two zoned dates would (correctly) compare as
> equal.

Are zoned dates comparable? I'd expect them to be at best only 
part comparable as they can overlap when understood as full 
days, so 2000-11-22Z should not be comparable with 
2004-11-22+0100.

That's why I'm uncomfortable with the idea of DT_ZONED_DATE:
- unlike all the other date types it's not cleanly 
  comparable (DT_DATE don't overlap so remain comparable 
  whether interpreted as a full day or as any point in the day)
- unlike the other zoned types, you can't directly use 
  the date with the zone (conversion must have a time).

xml-schema 3.2.7.5 says:
| dates without time zone have a total order among themselves.

which hints that dates with TZ have only a partial order 
at best. I don't know what it means for equality.

In general the needs of XML schema should not dictate 
at all cost what the generic date time library provides 
and if some of XML schema dates require adapter classes 
in the xml cluster then so be it.

But we do indeed need to validate and parse 2000-11-22Z distinctly 
from the one with an explicit time, and I can't see how we could 
express this nicely in the parser/formatter interface  
without having a zoned date type, even if it's little more 
than a pair of date and time zone. On the other hand, 
if implicit time is actually used for something, or it 
has a specific definition of equality or comparability, 
this can easily be done in an adapter class in library/xml.

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

    Franck> Are zoned dates comparable? I'd expect them to be at best
    Franck> only part comparable as they can overlap when understood
    Franck> as full days, so 2000-11-22Z should not be comparable with
    Franck> 2004-11-22+0100.

Well, I would guess it depends upon the application, to some extent.

You can definitely say that 2000-11-22Z is not later than
2004-11-22+0100.

    Franck> That's why I'm uncomfortable with the idea of
    Franck> DT_ZONED_DATE: - unlike all the other date types it's not
    Franck> cleanly comparable (DT_DATE don't overlap so remain
    Franck> comparable whether interpreted as a full day or as any
    Franck> point in the day) - unlike the other zoned types, you
    Franck> can't directly use the date with the zone (conversion must
    Franck> have a time).

Well, I don't see partial ordering as an argument against the type.

    Franck> xml-schema 3.2.7.5 says: | dates without time zone have a
    Franck> total order among themselves.

    Franck> which hints that dates with TZ have only a partial order
    Franck> at best.

I would say, at least, rather than at best. It depends upon the application.
If you use DT_ZONED_DATE_TIME instead, then you are IMPOSING total
ordering, which I would say prempts the application's perogative.

But for sorting purposes, there IS a total ordering. Z clearly sorts
earlier than +0100.
Then it's up to the application to decide whether to successive dates
having the same date part are to be considered equal or not.
-- 
Colin Paul Adams
Preston Lancashire

>>>>> "Colin" == Colin Paul Adams <colin@...> writes:


    Franck> That's why I'm uncomfortable with the idea of
    Franck> DT_ZONED_DATE: - unlike all the other date types it's not
    Franck> cleanly comparable (DT_DATE don't overlap so remain
    Franck> comparable whether interpreted as a full day or as any
    Franck> point in the day) - unlike the other zoned types, you
    Franck> can't directly use the date with the zone (conversion must
    Franck> have a time).

    Colin> Well, I don't see partial ordering as an argument against
    Colin> the type.

    Franck> xml-schema 3.2.7.5 says: | dates without time zone have a
    Franck> total order among themselves.

    Franck> which hints that dates with TZ have only a partial order
    Franck> at best.

    Colin> I would say, at least, rather than at best. It depends upon
    Colin> the application.  If you use DT_ZONED_DATE_TIME instead,
    Colin> then you are IMPOSING total ordering, which I would say
    Colin> prempts the application's perogative.

    Colin> But for sorting purposes, there IS a total ordering. Z
    Colin> clearly sorts earlier than +0100.  Then it's up to the
    Colin> application to decide whether to successive dates having
    Colin> the same date part are to be considered equal or not.

Can we come to some conclusion on this? I'm anxious to start coding
soon, as at the moment, lack of date/time processing is a big hole in
the XPath library.
-- 
Colin Paul Adams
Preston Lancashire

Colin Paul Adams:

> Can we come to some conclusion on this?

Go ahead. I think you've convinced me DT_ZONED_DATE time 
is acceptable. So we have

class DT_ZONED
feature
 time_zone: DT_TIME_ZONE


class DT_ZONED_DATE_TIME
inherit
 DT_ZONED
feature
 date_time: DT_DATE_TIME


class DT_ZONED_TIME
inherit 
 DT_ZONED
feature
 time: DT_TIME


class DT_ZONED_DATE
inherit
 DT_ZONED
feature
 date: DT_DATE

DT_ZONED indicates the classes have a common aspect, but it's 
not necessary.

And the formatter/parser class follow.

I think I'd still prefer DT_ZONED_DATE not to inherit from 
COMPARABLE to emphasize the ordering issue. An external sorter 
of type KL_PART_COMPARATOR can still be provided of course.
The others should probably be COMPARABLE, and all HASHABLE.

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

    Franck> ABORT [XM_XPATH_TEST_EVALUATOR.test_second_child_filter]
    Franck> Eiffel
    >> I doubt it. Especially if test_against_xml_file passed.  Better
    >> insert -Dabort into the command line, and send me the stack
    >> trace

    Franck> XM_XPATH_EVALUATOR build_static_context @
    Franck> context_item_is_node: <40306560> Assertion violated.  Fail

    Franck> -------------------------------------------------------------------------------
    Franck> XM_XPATH_EVALUATOR build_static_context @ <40306560>
    Franck> Routine failure.  Fail

    Franck> -------------------------------------------------------------------------------
    Franck> XXM_XPATH_TEST_EVAL test_second_child_filt <406D1388>
    Franck> (From XM_XPATH_TEST_E) Routine failure.  Fail

This test is using the tiny-tree model (the tests in
XM_XPATH_TEST_EVALUATOR are roughly half-and-half - it's the third
boolean on the call:

an_evaluator.build_static_context ("./data/books.xml", False, False, True, True)

that determines the tree model, so if all the aborting tests are the
ones where this is True, then it's because of the tiny tree.
-- 
Colin Paul Adams
Preston Lancashire