Re: request as data source in transformation?

Christian, et al,
while HTTP Client v2 as part of EXPath has a complete sense on its own, in
order to be efficient in the transformation pipeline by Declarative Web
Application, the declarative syntax for request/response is a must. Without
declarative XSLT syntax following transformation rules would be tough to
layer.

In addition to request preparation as part of transformation, there are
many other use cases which are essential part of web application:
* pre-request authentication( tokens of all kinds, etc. )
* request payload validation to match the expected schema.
* response validation against expected by client schemas
* variations and error handling with potential re-try.
* response integrity validation

Note, all ^^ are meant to be executed by transformation pipeline, i.e. have
to be expressed via XSLT syntax. Outside of XPath where those layers are
not meant to be primarily defined.
The execution environment would be triggering layers depending on runtime
configuration. Schema Validators have to be run only once when the service
or client code is changed, session token has to be re-validated only if the
previous is expired, etc. That fits into the request pipeline as XSLT
concept but not into XPath.

-s
PS. Can we agree that all cases ^^ have to be supported as declaratively as
via scripting languages ( XPath and JS )?

On Tue, Dec 20, 2022 at 2:18 AM Christian Grün <cg@basex.org> wrote:

> Hi Sasha,
>
> An EXPath module exists for sending HTTP Requests, it's called HTTP Client
> Module:
>
> http://expath.org/spec/http-client
>
> Together with Adam, we've done some work on a new version:
>
> http://expath.github.io/expath-cg/specs/http-client-2/
>
> The general question may be which features should be part of the core
> language or made available externally, as e.g. discussed here:
>
> https://github.com/qt4cg/qtspecs/issues/274
>
> Best,
> Christian
>
>
>
> Am 20.12.2022 05:28 schrieb Sasha Firsov <suns@firsov.net>:
>
> 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.
>
> -s
> PS. The Declarative Web Application stack manifest and proposal is still
> in baking and data access layer based on XSLT transformation pipeline is a
> part of it.
>
>
>