gestalt-users — Using Gestalt

Re: [Gestalt-users] New extension function

[Florent G. <dar...@ya...>]

Colin Paul Adams wrote:

  Hi

> But it is totally superfluous.
> The Gobo XSLT library implements stylesheet caching by default.

  I didn't know that.  So I guess you are right, it is totally
superfluous.

  So if I understand right, the idea is that caching is on by default,
and to allow in the future more control on caching through flags. 
IMHO, it makes sense, against the Saxon way to not perform caching,
just allowing the user to keep track of the compiled scripts.

  Regards,

--drkm



















	

	
		
___________________________________________________________________________ 
Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire.
http://fr.mail.yahoo.com

Re: [Gestalt-users] New extension function

[Colin P. A. <co...@co...>]

>>>>> "Frans" == Frans Englich <fra...@te...> writes:

    Frans> On Friday 14 July 2006 20:13, Florent Georges wrote:
    >> Frans Englich wrote: > However, I would prefer a whitespace
    >> separated list of > xs:anyURIs where it is implementation
    >> defined which that > are recognized(and where unrecognized are
    >> ignored). In > this way any implementation can add performance
    >> settings > in a portable way.
    >> 
    >> Personally, I see well a list of QNames or strings in the same
    >> lexical space (resolved with the in-scope namespaces).  URIs
    >> can be a pain to manipulate, IMHO, while QNames provide the
    >> same level of isolation (because namespaces are URIs), with the
    >> advantage of the readibility.

    Frans> Good idea.

Well, 2/2 and I see no objection, so I'll do that.
-- 
Colin Adams
Preston Lancashire

Re: [Gestalt-users] New extension function

[Colin P. A. <co...@co...>]

>>>>> "Florent" == Florent Georges <dar...@ya...> writes:

    Florent>   Did you think about dividing this in two times:
    Florent> compilation + transformation itself?  So it would be
    Florent> possible to compile once a script and then apply it
    Florent> several times, on several inputs.  For example to
    Florent> transform all input documents in a directory, what seems
    Florent> to be a very common need.

No.
   
     Florent>   It is the way choosen in Saxon.  And I think it is what
    Florent> JAXP provides with Templates.

But it is totally superfluous.
The Gobo XSLT library implements stylesheet caching by default. So if
you call a transformation on the same URi twice, the stylesheet will
only be compiled once.

    Florent>   I see you have "various stylesheet-caching control
    Florent> flags in mind".  This can be a simple way to achieve this
    Florent> in some cases, delegated to the user.

These are to alter the behaviour described above. (I'm not sure why
anyone would actually want to, but I provided these facilities in the
class XM_XSLT_TRANSFORMER_FACTORY from the start. take a look at the
source if you like. Eiffel is extremely readable.

-- 
Colin Adams
Preston Lancashire

Re: [Gestalt-users] New extension function

[Frans E. <fra...@te...>]

On Friday 14 July 2006 20:13, Florent Georges wrote:
> Frans Englich wrote:
> > However, I would prefer a whitespace separated list of
> > xs:anyURIs where it is implementation defined which that
> > are recognized(and where unrecognized are ignored). In
> > this way any implementation can add performance settings
> > in a portable way.
>
>   Personally, I see well a list of QNames or strings in the
> same lexical space (resolved with the in-scope namespaces).
> URIs can be a pain to manipulate, IMHO, while QNames provide
> the same level of isolation (because namespaces are URIs),
> with the advantage of the readibility.

Good idea.


		Frans

Re: [Gestalt-users] New extension function

[Florent G. <dar...@ya...>]

Frans Englich wrote:

> However, I would prefer a whitespace separated list of
> xs:anyURIs where it is implementation defined which that
> are recognized(and where unrecognized are ignored). In
> this way any implementation can add performance settings
> in a portable way.

  Personally, I see well a list of QNames or strings in the
same lexical space (resolved with the in-scope namespaces).
URIs can be a pain to manipulate, IMHO, while QNames provide
the same level of isolation (because namespaces are URIs),
with the advantage of the readibility.

  Regards,

--drkm


























	

	
		
___________________________________________________________________________ 
Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire.
http://fr.mail.yahoo.com

Re: [Gestalt-users] New extension function

[Florent G. <dar...@ya...>]

Colin Paul Adams wrote:

> Here is my current specification for a proposed new
> extension function, to be written this weekend. Comments
> welcome.

> gexslt:transformation

  Good news ;-)

> This function allows you to run an XSLT transformation
> from within your current XSLT transformation. Syntax is:

> gexslt:transformation ($trans as xs:anyURI,
> $initial-context as node()?, $initial-template as
> xs:QName?, $initial-mode as xs:QName?, $parameters as
> item*, $flags as xs:boolean*) as item()+ or
> gexslt:transformation ($trans as xs:anyURI,
> $initial-context as node()?) as item()+

  Did you think about dividing this in two times:
compilation + transformation itself?  So it would be
possible to compile once a script and then apply it several
times, on several inputs.  For example to transform all
input documents in a directory, what seems to be a very
common need.

  It is the way choosen in Saxon.  And I think it is what
JAXP provides with Templates.

  I see you have "various stylesheet-caching control flags
in mind".  This can be a simple way to achieve this in some
cases, delegated to the user.

  Regards,

--drkm

























	

	
		
___________________________________________________________________________ 
Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire.
http://fr.mail.yahoo.com

Re: [Gestalt-users] New extension function

[Colin P. A. <co...@co...>]

>>>>> "Frans" == Frans Englich <fra...@te...> writes:

    Frans> * It gives at least a small hint what
    Frans> a flag does. "c" for "caching", for example.

A hint that might well be mis-leading. Caching is on by default.

    Frans> I fail to see the advantages with booleans. Could you
    Frans> enlighten?

Yes. true() means non-default behaviour.

    Frans> (Indeed, but it doesn't hurt designing things so others can
    Frans> adopt it, and hence increase chances for portability. Also,
    Frans> perhaps this will move to EXSL-T at somepoint, and then it
    Frans> can be done without changing your and others
    Frans> implementations.)

I suppose that might happen, but the namespace at least would have to
change. And the name and return types are not the same as saxon:transform.
-- 
Colin Adams
Preston Lancashire

Re: [Gestalt-users] New extension function

[Frans E. <fra...@te...>]

On Friday 14 July 2006 17:11, Colin Paul Adams wrote:
[...]
> =A0 =A0 Frans> Using letters is a step better, like flags for
> =A0 =A0 Frans> fn:tokenize() and so on.
>
> I don't think that's better at all.

Ok. Discussing it seems slightly redundant since I understand you're going =
for=20
the xs:anyURI approach instead, but I'm nevertheless curious of why you thi=
nk=20
so. I can think of many reasons why it's preferred:

* A lot less to type. (false(), false(), true()) more verbose than "abc".
* It gives at least a small hint what a flag does. "c" for "caching", for=20
example. With boolean one have only the order as key which is arbitrary.
* The user must think about the argument order. With letters that's=20
insignificant.

(Perhaps that's why the F&O functions are designed this way.)

I fail to see the advantages with booleans. Could you enlighten?

> However, I like the idea of supply a list of ws-separated xs:anyURIs.

It should also be specified what a flag can be expected to do. For example,=
 I=20
presume a flag can't alter the semantics of the function.

> =A0 =A0 Frans> However, I would prefer a whitespace separated list of
> =A0 =A0 Frans> xs:anyURIs where it is implementation defined which that
> =A0 =A0 Frans> are recognized(and where unrecognized are ignored). In this
> =A0 =A0 Frans> way any implementation can add performance settings in a
> =A0 =A0 Frans> portable way.
>
> But this is an implementation-specific extension function, so there IS
> only one implementation.

(Indeed, but it doesn't hurt designing things so others can adopt it, and=20
hence increase chances for portability. Also, perhaps this will move to=20
EXSL-T at somepoint, and then it can be done without changing your and othe=
rs=20
implementations.)


Cheers,

		Frans

Re: [Gestalt-users] New extension function

[Colin P. A. <co...@co...>]

>>>>> "Frans" == Frans Englich <fra...@te...> writes:

    Frans> On Friday 14 July 2006 16:27, Colin Paul Adams wrote:
    >> Here is my current specification for a proposed new extension
    >> function, to be written this weekend. Comments welcome.
    >> 
    >> 
    >> gexslt:transformation
    >> 
    >> This function allows you to run an XSLT transformation from
    >> within your current XSLT transformation. Syntax is:
    >> 
    >> gexslt:transformation ($trans as xs:anyURI,

    Frans> As far as I know the current practice is to have arguments
    Frans> taking URIs be of type xs:string(so one can pass string
    Frans> literals) but require the lexical space to conform to
    Frans> xs:anyURI. I think it's sensible.

Hm. I envisioned passing literal strings - of course a cast is legal,
but it will not happen automatically, so I think your suggestion is
good.

    Frans> Here's a lot of "must" words, but it isn't spec'd what must
    Frans> be done if it fails. What error code is raised if the
    Frans> conditions aren't reached?

    >> The parameters list must consist of an even number of
    >> items. The odd numbered items must be of type xs:QName, which
    >> represent the name of a global stylesheet parameter. The
    >> following even-numbered item will be the value of that
    >> stylesheet parameter.

I meant to document them, but forgot to do so. I shall do it.

    Frans> I would use two lists for this, where one is the names and
    Frans> the other the values. This makes type checking possible in
    Frans> an ordinary fashion, and it makes the spec simpler.

Another good suggestion.

    >> The flags all default to false(). Trailing flags may be
    >> omitted, which means I can easily add further flags later. The
    >> meaning of the flags currently defined is as follows: No flags
    >> are defined at this stage. I have various stylesheet-caching
    >> control flags in mind.

    Frans> Hm, booleans aren't very readable for switches. For
    Frans> example:

    Frans> (false(), false(), true(), false(), true())

    Frans> What is what? That's especially hard to tell when someone
    Frans> else is reading the code or some time have passed since
    Frans> writing it.

That is true.

    Frans> Using letters is a step better, like flags for
    Frans> fn:tokenize() and so on.

I don't think that's better at all.

    Frans> However, I would prefer a whitespace separated list of
    Frans> xs:anyURIs where it is implementation defined which that
    Frans> are recognized(and where unrecognized are ignored). In this
    Frans> way any implementation can add performance settings in a
    Frans> portable way.

But this is an implementation-specific extension function, so there IS
only one implementation.
However, I like the idea of supply a list of ws-separated xs:anyURIs.

    >> The result sequence has one of two forms: Exactly one xs:QName,
    >> representing an error code from the transformation One or
    >> moredocument-node().

    Frans> Reads a bit weird.

I'll see if I can improve my wording.

    Frans> (Not that I'm a Gestalt user.)

Thanks for your comments anyway.
-- 
Colin Adams
Preston Lancashire

Re: [Gestalt-users] New extension function

[Frans E. <fra...@te...>]

On Friday 14 July 2006 16:27, Colin Paul Adams wrote:
> Here is my current specification for a proposed new extension
> function, to be written this weekend. Comments welcome.
>
>
> gexslt:transformation
>
> This function allows you to run an XSLT transformation from within your
> current XSLT transformation. Syntax is:
>
> gexslt:transformation ($trans as xs:anyURI,

As far as I know the current practice is to have arguments taking URIs be of 
type xs:string(so one can pass string literals) but require the lexical space 
to conform to xs:anyURI. I think it's sensible.

> $initial-context as node()?, 
> $initial-template as xs:QName?, $initial-mode as xs:QName?, $parameters as
> item*, $flags as xs:boolean*) as item()+ or gexslt:transformation ($trans
> as xs:anyURI, $initial-context as node()?) as item()+
>
> The two-argument form is equivalent to passing () for all remaining
> arguments.
>
> The meaning of the arguments is as follows:
> The URI of the transformation to be run An optional initial context node An
> optional initial template An optional initial mode

Here's a lot of "must" words, but it isn't spec'd what must be done if it 
fails. What error code is raised if the conditions aren't reached?

> The parameters list must consist of an even number of items. The odd
> numbered items must be of type xs:QName, which represent the name of a
> global stylesheet parameter. The following even-numbered item will be the
> value of that stylesheet parameter.

I would use two lists for this, where one is the names and the other the 
values. This makes type checking possible in an ordinary fashion, and it 
makes the spec simpler.

> The flags all default to false(). Trailing flags may be omitted, which
> means I can easily add further flags later. The meaning of the flags
> currently defined is as follows: No flags are defined at this stage. I have
> various stylesheet-caching control flags in mind.

Hm, booleans aren't very readable for switches. For example:

(false(), false(), true(), false(), true())

What is what? That's especially hard to tell when someone else is reading the 
code or some time have passed since writing it.

Using letters is a step better, like flags for fn:tokenize() and so on.

However, I would prefer a whitespace separated list of xs:anyURIs where it is 
implementation defined which that are recognized(and where unrecognized are 
ignored). In this way any implementation can add performance settings in a 
portable way.

> The result sequence has one of two forms: Exactly one xs:QName,
> representing an error code from the transformation One or
> moredocument-node().

Reads a bit weird.

(Not that I'm a Gestalt user.)


Cheers,

		Frans

[Gestalt-users] New extension function

[Colin P. A. <co...@co...>]

Here is my current specification for a proposed new extension
function, to be written this weekend. Comments welcome.


gexslt:transformation

This function allows you to run an XSLT transformation from within your current XSLT transformation. Syntax is:

gexslt:transformation ($trans as xs:anyURI, $initial-context as node()?, $initial-template as xs:QName?, $initial-mode as xs:QName?, $parameters as item*, $flags as xs:boolean*) as item()+ or gexslt:transformation ($trans as xs:anyURI, $initial-context as node()?) as item()+

The two-argument form is equivalent to passing () for all remaining arguments.

The meaning of the arguments is as follows:
The URI of the transformation to be run An optional initial context node An optional initial template An optional initial mode

The parameters list must consist of an even number of items. The odd numbered items must be of type xs:QName, which represent the name of a global stylesheet parameter. The following even-numbered item will be the value of that stylesheet parameter.

The flags all default to false(). Trailing flags may be omitted, which means I can easily add further flags later. The meaning of the flags currently defined is as follows:
No flags are defined at this stage. I have various stylesheet-caching control flags in mind.

The result sequence has one of two forms: Exactly one xs:QName, representing an error code from the transformation One or moredocument-node(). The first document will be the implicit result document if one exists.

Result documents can be serialized using the gexslt:serialize extension instruction.

-- 
Colin Adams
Preston Lancashire

[Gestalt-users] News

[Colin P. A. <co...@co...>]

I thought I'd just provide an update of the development situation.

The current CVS code is now close to the expected Candidate
Recommendation (Basic XSLT processor).

Apart from any undiscovered bugs, the following areas are known not to
be compliant:

    * Serializer does not yet support UTF-16 as an output encoding,
        nor does it support Unicode normalization. 
    * Regular expressions do not yet support Unicode data (ASCII
        only). Also Unicode digits are not yet supported for xsl:number
        and format-date/datetime/time functions. 
    * The functions unparsed-text() and and unparsed-text-available()
        do not work properly yet. They will probably work OK for 7-bit
        ASCII and UTF-8 files. 
    * The function normalize-unicode() has not been implemented yet.

I should very soon be starting an Eiffel programming job on
Windows. This means I will be in a position to release win32 and .NET
binaries soon.

If anyone is interested, I could release an up-to-date Linux binary,
compiled with the free edition of the ISE compiler. This means a
splash screen gets written to stdout, but you can always redirect
stdout to /dev/null and use the --output option to direct the
transformation output to a file.

Alternatively, I could use the VE compiler - but this produces much
slower executables.
Unfortunately, the GPLed SmartEiffel compilers are all a bit buggy
now, so I cannot produce a fast-running executable with any version of
them at the moment. I think this is the only compiler I can use on Mac
OS/X at the moment, otherwise I would have tested gestalt against
Bruce's bibliography stuff.

At the moment I am writing a utility program to generate Eiffel
Unicode routines from the Unicode database (4.1). This will enable me
to fix the xsl:number etc. problem.
The next stage is to write a Unicode-aware regular expression engine
so I can fix those bits.
Finally UTF-16 output will be fairly easy to do, but as this
abomination is no use to mankind, I leave it to last.

I hope to be able to release compliant binaries by Christmas.

Performance has greatly improved since alpha 2 release - it continues
however to be about 7 times faster than Saxon for short (0 - 4
seconds) transformations, thereafter getting progressively slower
(maybe 5 times slower for long running (over 10 minutes) transformations).
-- 
Colin Adams
Preston Lancashire

Re: [Gestalt-users] crashing

[Colin P. A. <co...@co...>]

>>>>> "Bruce" == Bruce D'Arcus <bd...@fa...> writes:

    Bruce> On Dec 3, 2004, at 6:42 AM, Colin Paul Adams wrote:

    >> Anyway, try an identity transform:...  on a small test file. If
    >> this doesn't work, then there is a SERIOUS problem.

    Bruce> This works fine.

    Bruce> I just can't get anything else to work.  I end up with
    Bruce> this:

    Bruce> $ gestalt syllabus-latex.xsl 101-syllabus.xml Eiffel
    Bruce> program crash at run time.  No trace when using option
    Bruce> "-boost"

OK. It's a bug then.
I've already fixed quite a few bugs that I've discovered since
releasing alpha-1. It may be that's it's already fixed.

You have 3 choices:

1) Use the Bugs tracker on the sourceforge site to to upload a data
   file plus all the xslt modules, and I can try and fix it.

or 

2) I could compile a debug version which will give a stack trace. You
   could then download that and send me back the stack trace (but it
   may take a very long time indeed to run - my XPath test suite, for
   instance, takes 43 seconds, but over 5 hours with the debug version
   compiled with the particular complier I use on MacOSX).

or

3) Forget all about it, and just hope the bug will have mysteriously
   dissappeared when alpha-2 is released.
-- 
Colin Paul Adams
Preston Lancashire

Re: [Gestalt-users] crashing

[Bruce D'A. <bd...@fa...>]

On Dec 3, 2004, at 6:42 AM, Colin Paul Adams wrote:

> Anyway, try an identity transform:...
> on a small test file. If this doesn't work, then there is a SERIOUS 
> problem.

This works fine.

I just can't get anything else to work.  I end up with this:

$ gestalt syllabus-latex.xsl 101-syllabus.xml
Eiffel program crash at run time.
No trace when using option "-boost"

Bruce

[Gestalt-users] crashing

[Colin P. A. <co...@co...>]

Bruce>I downloaded the OS X binary, but it crashes on everything I throw at 
Bruce> it. Do you have test stylesheets that work on your end?

When you saying crashing, if you get anything other than:

segmentation fault

as output, can you post it here?

Feel free to submit reports to the BUGS tracker on the website - you
can upload stylesheets and test files there.
If you do that, I can see what I can do about fixing the problems.

Anyway, try an identity transform:

<xsl:transform
 xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
 version="1.0">


<xsl:template match="/" >
  <xsl:copy-of select="."/>
</xsl:template>

</xsl:transform>

on a small test file. If this doesn't work, then there is a SERIOUS problem.
-- 
Colin Paul Adams
Preston Lancashire

[Gestalt-users] Testing on OSX

[Colin P. A. <co...@co...>]

I just ran an identity transform against itself.

Also, just typing gestalt should give you a usage message.

But there are bugs present - I'm getting crashes when trying out the
FXSL stylesheets - some of them anyway, and I'm investigating these
bugs.

It is only alpha test.
-- 
Colin Paul Adams
Preston Lancashire

[Gestalt-users] crashing

[Bruce D'A. <bd...@fa...>]

Colin,

I downloaded the OS X binary, but it crashes on everything I throw at 
it. Do you have test stylesheets that work on your end?

Bruce

[Gestalt-users] List open

[Colin P. A. <co...@co...>]

This list is now open.
-- 
Colin Paul Adams
Preston Lancashire