gestalt-users — Using Gestalt

[Gestalt-users] End of project

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

Nearly two weeks ago, I ceased all work on Gestalt.

I shall not be pursuing the project, or having anything more to do
with anything related to the W3C, in protest at the betrayal of trust
implied by their intention to implement the proposed so-called "Fifth
Edition" of XML 1.0.

If anyone else wants to take on the project, then they are welcome to
do so.
-- 
Colin Adams
Preston Lancashire

Re: [Gestalt-users] Should file: URIs create new directories?

[Florent G. <li...@fg...>]

Colin Paul Adams wrote:

  Hi

> Opinions are welcome.

  I could see the benefits of having the ability to create the
necessary directories from an output URI.  At the first glance, my
feeling is that it should be best by default (especially if other
processors behave so,) providing you have a way to disable the
functionality (for instance by a command line argument.)

  Just some thoughts...

  Regards,

--drkm




















      _____________________________________________________________________________ 
Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail http://mail.yahoo.fr

Re: [Gestalt-users] Should file: URIs create new directories?

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

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

    Colin> An alternative would be for an extension function that

That should sat extension instruction, of course.
-- 
Colin Adams
Preston Lancashire

[Gestalt-users] An explanation of version numbers and release policy

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

Version 1.0 was the first general release. The next general release
will be 1.1. Version 2.0 will be a sign that I believe there is 100%
conformance to the XSLT 2.0 specification, and it's dependent
specifications. I would hope to achieve this by the end of the summer.

After the initial release, I noticed that I had not included the
binary in the Linux (i386) version. By this time I had already fixed
many bugs, so I released it as 1.0.1.

Later, I acquired a 64-bit machine, and since I had fixed some more
bugs, I released the Linux 64-bit version as 1.0.2.

Currently, I am trying to build on FreeBSD (at the request of an
existing user). Since I fixed a whole bunch of new bugs yesterday,
this will be 1.0.3 (at least). I am also working on a DragonFly
release (purely to unify my website :-) ).

My intention is to release 1.1 when the known XML parser bugs are
fixed (so the date is out of my control), in order that Gestalt will
then be able to process DocBook (XSLT 2.0 version only - exslt is not
supported (environment variables excepted), nor will it ever be,
unless someone else wants to write the functions).
-- 
Colin Adams
Preston Lancashire

[Gestalt-users] Should file: URIs create new directories?

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

Currently, if you specify a file: URI in the href attribute of
xsl:result-document, Gestalt will not attempt to create any
directories for you. This is consistent with the behaviour I would
expect if you specify an http URI (I would not expect a server to
create new directories for you). It is also consistent with i/o
redirection (if you DON'T use xsl:result-document, and attempt to
redirect the output to a file in a non-existing directory, bash
refuses to do it.

Liam Quinn points out that this is not what Saxon does (nor xsltproc +
exslt - both behaviours are consistent with the
specifications). Furthermore, with xsl:result-document, the actual
href attribute, and therefore the presence or absence of necessary
directories, can be determined (and he does so) by data in the source
documents. And XSLT does not have a mkdir command.

I pointed out that it would be possible to tackle this by doing two
transformations - the first of which creates the necessary mkdir
commands.

But this would not be efficient (two passes over the source document),
and further more, it would not be portable accross operating systems.

An alternative would be for an extension function that takes a file:
URI and attempts to create all necessary directories.

Opinions are welcome.
-- 
Colin Adams
Preston Lancashire

[Gestalt-users] HTTP PUT or POST?

[Colin A. <col...@go...>]

Currently, writing an xsl:result-document to an http: destination is
invoking POST.

I think this should probably be using PUT.

I propose changing POST to PUT, but adding an extension attribute,
gexslt:http-method, which can take values of 'PUT' or 'POST'. And an
extension function to receive POST response data from an http URI for
which an xsl:result-document has been written during the
transformation using the POST method.

Comments please.

[Gestalt-users] Collections

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

Is anyone using the collection() or default-collection() function with
Gestalt (or gexslt)?

I propose to abandon the current scheme, and replace it as outlined in
http://colina.demon.co.uk/?q=node/42 , but if anyone is currently
using it extensively, I might need to think about a
backwards-compatibility option.
-- 
Colin Adams
Preston Lancashire

[Gestalt-users] License upgrade

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

The license for Gestalt has just been upgraded to GPL v 3.0
-- 
Colin Adams
Preston Lancashire

Re: [Gestalt-users] Binary downloads for gestalt

[Colin A. <col...@go...>]

Sorry, problems with ftp and firewall.

Instead I've updated the FAQ. Latest snapshot binary is now obtainable from:

http://colina.demon.co.uk/?q=node/6

On 19/10/2007, Colin Adams <col...@go...> wrote:
> Rick, Dave, and anyone else,
>
> I have put files gestalt.bz2 (Linux x86) and gestalt.zip (Windows XP
> x86) on my secure ftp server at colina.demon.co.uk .
>
> Logon on as ftp, use <username>@ as a password (e.g. rick@ or dave@),
> then cd to pub.
>
> Documentation is at http://colina.demon.co.uk/?q=node/5 (although it's
> not quite up-to-date).
>
> See also http://colina.demon.co.uk/?q=node/39 for using with schematron!
>
> Support is by the mailing list at
> https://lists.sourceforge.net/lists/listinfo/gestalt-users
>

[Gestalt-users] Design and use-cases for web-services access

[Colin A. <col...@ho...>]

This is principally addressed to Abel, as he has expressed a wish for the 
functionality, but others may well be interested too.

It is currently possible to do an HTTP(S) POST followed by an HTTP(S) GET by 
following a call to xsl:result-document by one to fn:document(), but with 
the proviso that the two URIs differ in some respect (such as a query 
parameter) other than a fragment identifier.

This might work in any XSLT 2.0 processor (but since it has an intrinsic 
dependency on the order of processing, it cannot be relied upon), but last 
time I tested http with xsl:result-document in Saxon, it did not work. It 
does work with Gestalt, but since a long-term goal for Gestalt is to using 
parallel processing, it cannot be relied upon to work forever.

Still, this is an interesting (but rather limiting) use case.

Abel, can you set up a web server which can be used to test such a use case, 
write a transformation to verify that it works, and publish it here? It will 
be a good regression test, to make sure the full scheme doesn't break this 
case.

It will not be hard to modify xsl:result-document to return a document node 
from an HTTP(S) POST, but as the XSLT REC specifies the value of the 
xsl:result-document instruction is an empty sequence, this cannot be done.

So my suggested solution is an extension instruction in the namespace 
http://gestalt.sourceforge.net/extension
local name of result-document,
which is identical in it's semantics to xsl:result-document, except that the 
result of evaluating it is zero or one document nodes.

Then the result of a SOAP request (for instance) can be captured in an 
xsl:variable by placing a gestalt:result-document instruction into its 
sequence constructor.

Any comments on this design?

_________________________________________________________________
Got a favourite clothes shop, bar or restaurant? Share your local knowledge  
http://www.backofmyhand.com

Re: [Gestalt-users] Follow-up from XSL-List: Gestalt, Extension Functions, the DLR, Spider Monkey, Tamarin, and IronMonkey

[M. D. P. <m....@xm...>]

On Sun, 09 Sep 2007 14:44:10 -0600, Colin Paul Adams  
<co...@co...> wrote:

>
> Well that looks to be a good option.

I would go this route as well as it would be quite easy to create C-based  
bindings for both SpiderMonkey/Tamarin and .NET by either embedding calls  
to Mono directly into the C application or by using P/Invoke.  Either way  
it will work, and you can use #ifdef, #else, and #endif to differentiate  
between the SpiderMonkey/Tamarin and .NET bindings.

-- 
/M:D

M. David Peterson
http://mdavid.name | http://www.oreillynet.com/pub/au/2354 |  
http://dev.aol.com/blog/3155

Re: [Gestalt-users] Follow-up from XSL-List: Gestalt, Extension Functions, the DLR, Spider Monkey, Tamarin, and IronMonkey

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

>>>>> "Abel" == Abel Braaksma <abe...@xs...> writes:

    >> Does that mean a native-code application can use it?

    Abel> and my answer: yes and no. I think M:D is about using
    Abel> Gestalt with .NET. 

Well, that isn't on, as the author of the ePosix library says it is
not going to support .NET.

    Abel> And I am about using Gestalt with any
    Abel> language that is capable of calling C-style externalized
    Abel> functions. For the latter: you do not need (and don't want
    Abel> to need) any .NET libraries, but SpiderMonkey itself is pure
    Abel> C and is very well externalized and documented:
    Abel> http://www.mozilla.org/js/spidermonkey/apidoc/sparse-frameset.html

Well that looks to be a good option.

-- 
Colin Adams
Preston Lancashire

Re: [Gestalt-users] Follow-up from XSL-List: Gestalt, Extension Functions, the DLR, Spider Monkey, Tamarin, and IronMonkey

[Abel B. <abe...@xs...>]

This thread hes gotten a bit scatterred over several sources: lists / 
offlist / this list...  Last reply from Colin to the statements of M:D  
below:

> Does that mean a native-code application can use it?

and my answer: yes and no. I think M:D is about using Gestalt with .NET. 
And I am about using Gestalt with any language that is capable of 
calling C-style externalized functions. For the latter: you do not need 
(and don't want to need) any .NET libraries, but SpiderMonkey itself is 
pure C and is very well externalized and documented: 
http://www.mozilla.org/js/spidermonkey/apidoc/sparse-frameset.html

The problems you had before with Parrot are something you won't 
encounter here.

I assume, but am not sure, that one would need the .NET version of 
SpiderMonkey (i.e.: Tamarin/IronMonkey) if you want to use it with .NET, 
but then again, maybe not, because the interface into the 
extension-language runtime will be written in Eiffel anyway. So if you 
do a port to .NET, is it then a problem to have non .NET libraries 
dependencies?

Cheers,
-- Abel Braaksma


M. David Peterson wrote:
> To summarize,
>
> Mozilla is building the IronMonkey, which is the Dynamic Language Runtime  
> directly embedded into Tamarin and Spider Monkey without aid of Mono  
> (meaning they're writing the support from scratch, building the foundation  
> directly on top of blazing fast Tamarin virtual machine) or any other CLR  
> implementation.
>
> Links
> -----
> http://www.mozilla.org/projects/tamarin/
> http://wiki.mozilla.org/Tamarin:IronMonkey
>
> Also, as per my follow-up to Abel,
>
> "Have you add a look at the Dynamic Language Runtime at all?  It's  
> open-sourced under the MSPL (the most liberal (BSD-like) license MSFT  
> offers), runs on Mono quite well, and if the hooks were provided you could  
> gain the advantage of writing extension functions in any DLR supported  
> language which at present time is IronPython, IronRuby, Vista Smalltalk,  
> (compiled) Javascript, and VBx (Dynamic VB.)  This would also pave the way  
> for providing in-browser support via Silverlight which has the DLR  
> embedded directly into its core.  And as per my last response to Abel,  
> could provide the perfect bridge to both SpiderMonkey and Tamarin as  
> well.  That's quite the language and technology span!"
>
>   

[Gestalt-users] Follow-up from XSL-List: Gestalt, Extension Functions, the DLR, Spider Monkey, Tamarin, and IronMonkey

[M. D. P. <m....@xm...>]

To summarize,

Mozilla is building the IronMonkey, which is the Dynamic Language Runtime  
directly embedded into Tamarin and Spider Monkey without aid of Mono  
(meaning they're writing the support from scratch, building the foundation  
directly on top of blazing fast Tamarin virtual machine) or any other CLR  
implementation.

Links
-----
http://www.mozilla.org/projects/tamarin/
http://wiki.mozilla.org/Tamarin:IronMonkey

Also, as per my follow-up to Abel,

"Have you add a look at the Dynamic Language Runtime at all?  It's  
open-sourced under the MSPL (the most liberal (BSD-like) license MSFT  
offers), runs on Mono quite well, and if the hooks were provided you could  
gain the advantage of writing extension functions in any DLR supported  
language which at present time is IronPython, IronRuby, Vista Smalltalk,  
(compiled) Javascript, and VBx (Dynamic VB.)  This would also pave the way  
for providing in-browser support via Silverlight which has the DLR  
embedded directly into its core.  And as per my last response to Abel,  
could provide the perfect bridge to both SpiderMonkey and Tamarin as  
well.  That's quite the language and technology span!"

-- 
/M:D

M. David Peterson
http://mdavid.name | http://www.oreillynet.com/pub/au/2354 |  
http://dev.aol.com/blog/3155

Re: [Gestalt-users] HTTP Basic Authentication support

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

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

    Colin> I have added --user and --password options.  This requires
    Colin> a new version of the http resolver which I have posted to
    Colin> the eposix list. Hopefully Berend will distribute it in the
    Colin> next beta.

I have distributed another version of the http resolver on the eposix
list. This one makes use of user:password@ information in the URL if
present. Only if it is not present will the --user and --password
information be used.
-- 
Colin Adams
Preston Lancashire

[Gestalt-users] HTTP Basic Authentication support

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

I have added --user and --password options.

This requires a new version of the http resolver which I have posted
to the eposix list. Hopefully Berend will distribute it in the next
beta.

I have also added HTTPS support. (ePosix 3.0 required)
-- 
Colin Adams
Preston Lancashire

Re: [Gestalt-users] XSLT 2.0 serializer

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

Florent Georges wrote:

> Colin Paul Adams wrote:

  Hi

> > It says gexslt is not yet supported.

>   Oops, yes you're right.

  Thanks to your great help those last days, my serializer is finally
working with Gexslt/Gestalt.  I updated the site (even if some further
documentation work could be done):

    http://www.fgeorges.org/xslt/serial/

  Thank you,

--drkm





















      _____________________________________________________________________________ 
Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail 

[Gestalt-users] Gestalt Central

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

In case anyone here hasn't noticed yet, I have a new website at
http://colina.demon.co.uk 
devoted (largely) to gestalt/gexslt and XSLT 2.0.
-- 
Colin Adams
Preston Lancashire

Re: [Gestalt-users] XSLT 2.0 serializer

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

Colin Paul Adams wrote:

> >>>>> "Florent" == Florent Georges writes:

>     Florent> you say "I think an XSLT 2.0 html serializer has also
>     Florent> been written".  You can have a look at
>     Florent> http://www.fgeorges.org/xslt/serial/.  I think the doc
>     Florent> can be improved, but there is enough to get started.

> It says gexslt is not yet supported.

  Oops, yes you're right.

  I didn't have a lot of time the last few weeks (months?)
to work on my XSLT projects.  I've just had a look at this
with the current Gexslt SVN version, and found a bug related
to @use-when and function-available().  I opened an issue on
SF.net.

  Actually, all seems to work fine, except that the last
evaluated expression that transforms the whole output tree
(an opportunity for post-processing, but for now it is only
f:id()) returns... the empty sequence :-(

  I hope I will able to look at this further in the next few
days.  Rain is back in Belgium, things are getting back to a
normal state, so...

  Regards,

--drkm























      
	
		
___________________________________________________________________________ 
Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! 
Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses 
http://fr.answers.yahoo.com

Re: [Gestalt-users] XSLT 2.0 serializer

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

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

    Florent>   Hi Colin In your freshly born Gestalt documentation,

it's not freshly born - you have long had it on your system :-)

It's just fresh to most of the public.

    Florent> you say "I think an XSLT 2.0 html serializer has also
    Florent> been written".  You can have a look at
    Florent> http://www.fgeorges.org/xslt/serial/.  I think the doc
    Florent> can be improved, but there is enough to get started.

It says gexslt is not yet supported.
-- 
Colin Adams
Preston Lancashire

[Gestalt-users] XSLT 2.0 serializer

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

  Hi Colin

  In your freshly born Gestalt documentation, you say "I think an XSLT
2.0 html serializer has also been written".  You can have a look at
http://www.fgeorges.org/xslt/serial/.  I think the doc can be improved,
but there is enough to get started.

  FXSL is used mainly to have first class object functions, so you can
use different serializers at the same time (to text, HTML with @class,
...).

  Regards,

--drkm





















      
___________________________________________________________________________ 
Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! 
Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses 
http://fr.answers.yahoo.com

Re: [Gestalt-users] Memo functions

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

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

    Florent> Colin Paul Adams wrote: Hi

    >> I have changed the non-compliant gexslt:memo-function extension
    >> attribute to do nothing but issue a warning message.

    >> Instead I have introduced the extension instruction
    >> gexslt:function.

    Florent>   If I remember correctly the discussion we had on XSL
    Florent> List, the attribute is not conmpliant because an
    Florent> extension attribute cannot change the behaviour of an
    Florent> XSLT instruction in anyway.

Well that is almost correct.
An extension attribute may change the behaviour, but only to the extent
that the behaviour is implementation defined.

That is not the case with a memo function.

    >> This is identical to xsl:function except that it memoizes the
    >> result just like specifying gexslt:memo-function=3D"yes" used to
    >> do.

    Florent>   Instead of defining gexslt:function to have the exact
    Florent> meaning of xsl:function with memoizing in addition, why
    Florent> not defining it to have the exact form/meaning of
    Florent> xsl:function, but with additional attributes (at the
    Florent> moment just @memo-function or @memoize).

    Florent>   That would make it possible to add another extension
    Florent> attribute to gexslt:function, without interfering with
    Florent> its memoization behaviour:

    Florent>     <!-- Maybe additional non-standard attributes... -->
    Florent> <gexslt:function name=3D"..." memoize=3D"true"> ...
    Florent> </gexslt:function>

I can still do that in the future, without loss of compatibility
(memoize would default to true) if I wish to.






















=20=20=20=20=20=20
    Florent> ______________________________________________________________=
_____________
    Florent> D=E9couvrez une nouvelle fa=E7on d'obtenir des r=E9ponses =E0
    Florent> toutes vos questions !  Profitez des connaissances, des
    Florent> opinions et des exp=E9riences des internautes sur Yahoo!
    Florent> Questions/R=E9ponses http://fr.answers.yahoo.com

    Florent> --------------------------------------------------------------=
-----------
    Florent> This SF.net email is sponsored by DB2 Express Download
    Florent> DB2 Express C - the FREE version of DB2 express and take
    Florent> control of your XML. No limits. Just data. Click to get
    Florent> it now.  http://sourceforge.net/powerbar/db2/
    Florent> _______________________________________________
    Florent> Gestalt-users mailing list
    Florent> Ges...@li...
    Florent> https://lists.sourceforge.net/lists/listinfo/gestalt-users


--=20
Colin Adams
Preston Lancashire

Re: [Gestalt-users] Memo functions

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

Colin Paul Adams wrote:

  Hi

> I have changed the non-compliant gexslt:memo-function extension
> attribute to do nothing but issue a warning message.

> Instead I have introduced the extension instruction gexslt:function.

  If I remember correctly the discussion we had on XSL List, the
attribute is not conmpliant because an extension attribute cannot
change the behaviour of an XSLT instruction in anyway.  Do someone
remember the discussion, I can't find it in the archive?

> This is identical to xsl:function except that it memoizes the
> result just like specifying gexslt:memo-function="yes" used to
> do.

  Instead of defining gexslt:function to have the exact meaning of
xsl:function with memoizing in addition, why not defining it to have
the exact form/meaning of xsl:function, but with additional attributes
(at the moment just @memo-function or @memoize).

  That would make it possible to add another extension attribute to
gexslt:function, without interfering with its memoization behaviour:

    <!-- Maybe additional non-standard attributes... -->
    <gexslt:function name="..." memoize="true">
      ...
    </gexslt:function>

  Regards,

--drkm






















      
___________________________________________________________________________ 
Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! 
Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses 
http://fr.answers.yahoo.com

[Gestalt-users] Memo functions

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

I have changed the non-compliant gexslt:memo-function extension
attribute to do nothing but issue a warning message.

Instead I have introduced the extension instruction gexslt:function.

This is identical to xsl:function except that it memoizes the result,
just like specifying gexslt:memo-function="yes" used to do.

The only difference from the old technique is that it is fully compliant.
-- 
Colin Adams
Preston Lancashire

[Gestalt-users] Gestalt explorer

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

It's still very crude, and you may not be able to work out how to use
it at first, but there is now an interactive debugger for gestalt in
the explorer sub-directory.

It features breakpoints and stepping through the code line-by-line.
-- 
Colin Adams
Preston Lancashire