Re: request as data source in transformation?

SaxonJS is a cool but self-closed solution, not even open source. This
discussion is about *extension of XSLT* to support *Request *and
*Response* kind
of entities on the level of XSLT, not XPath function.

The Request data are not static and can be the result of transformation,
hence have to be an XML namespace kind of entity.
Similar is applicable to Response. Which has to be consumable to further
transformation.

-s
PS SaxonJS is not functionally complete as far as I can see. There are
assumptions on the content ahead or responce availability. It does not
match most real use cases. The data can be returned in at least few formats
and some return values would not have data but still have their own meaning
via http status.

Typical processing has to cover
* happy path (200, return type matches expected format). Granted, SaxonJs
covers a happy path.
* server side error - auth /401
* server side error - timeout
* server side error - broken (5xx)
* network connection broken - not even status
^^ is a bare minimum on enterprise grade apps


On Tue, Dec 20, 2022 at 1:01 AM Martin Honnen <martin.honnen@gmx.de> wrote:

>
> Am 12/20/2022 um 5:26 AM schrieb Sasha Firsov:
> > Dear XSLT forum, this is a teaser for an architectural kind of
> > discussion, not a syntax.
> >
> > Rather than reference to external documents in XPath/ #XSLT, the
> > Declarative Web Application needs a concept of Request as valid data
> > feed.
> >
> > The data source reference the object is a result of transformation with
> > * url
> > * headers
> > * http method
> > * custom payload
> > * schema of data in response
> >
> > This data source then could be used as input parameter for following
> > XSLT transformation via XPath. The data source is just a definition
> > which would be resolved to live HTTP request only when it is actually
> > used in transformation.
> >
> > The request would produce the Response object with access to
> > * response HTTP code( 200 for normal, 4xxx, 5xxx errors, etc. )
> > * http headers
> > * data. The data reading would be immediate when no schema defined, or
> > triggered dynamically when data access needed by
> > transformation/selectors in case the schema is available.
>
>
> Are you familiar with SaxonJS? It runs in the browser and it seems it
> (in a different way) implements part of that with e.g.
>
> https://www.saxonica.com/saxon-js/documentation2/index.html#!ixsl-extension/instructions/schedule-action
>
> https://www.saxonica.com/saxon-js/documentation2/index.html#!api/getResource
>
>
>
>
>