Re: request as data source in transformation?

I am trying to avoid the exact syntax proposal at this stage. We need to
have an agreement on including DAL as one of the essential pieces of XSLT
first.
If we treat XSLT as an application transformation pipeline engine, then it
would be a natural choice. If XSLT is treated just as a template for data
feed, there is no reason to continue.

The XSLT syntax needs some semantic adjustments in order to be efficient as
an application transformation engine. We would discuss those aspects
separately. It would be tied to request syntax.

The semantic meaning of data source pipeline would include:
* data source definition, with url, methods, etc.
* request object.
* response object

associated flows
* data source preparation ( fill in the dynamic data as result of
transformation )
* triggering request
* response processing
* response data use in general document transformation
Each flow would have its own syntax and ability to associate its own
transformation rules. The syntax for most flows fits into XSLT 3.0, the
objects can(should be?) expressed via their own DTD.
-s

On Tue, Dec 20, 2022 at 3:57 PM Christian Grün <cg@basex.org> wrote:

> Hi Sasha,
>
> Do you have some idea how the declarative syntax should look like? Should
> it be XSLT-only or be added to XPath?
>
> Best,
> Christian
>
>
>
> Am 21.12.2022 00:16 schrieb Sasha Firsov <suns@firsov.net>:
>
> 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.
>
>
>
>