Re: request as data source in transformation?

Lets try from another angle. The data source is needed as in XSLT to
retrieve the external data as in XProc.

*Should they share the same protocol of data source definition, data
retrieval and results validation?*

By allowing external data in XSLT and limiting it to simple GET we are
excluding the dynamic data, data hosted outside( i.e. not on file system ),
data which are managed by 3rd party vendors. If the XSLT is used in
client-side web application, the extended cases would not be "extended"
anymore, rather be a usual pattern.

*Do we want to support the use of XSLT with external data in client-side
applications?*

That is about a very basic simple 1-way transformation. Which does not
involve any pipeline branching, I.e. in scope of XSLT and NOT of XProc.

There is a whole row of applications I call microapplications: a
microfront-end which serves UI to a single microservice. There is nothing
except of XSLT is needed, lacking the proper definition of the data source
and response handling. XProc there is super-overkill.
-s


On Tue, Dec 20, 2022 at 10:35 PM <list.mu@c-moria.com> wrote:

> Also for me this sounds more like building a specific XProc application
> other than XSLT to-be-standard functionality.
>
> I would suggest to discuss the “misfits “ at the xproc dev indeed. I for
> one am curious,
>
> And I bet there are participants on that list that could have some
> suggestions for you to overcome the misfits
>
>
>
> Best,
>
>
>
> Geert
>
>
>
> *From:* Sasha Firsov <suns@firsov.net>
> *Sent:* Wednesday, 21 December 2022 04:07
> *To:* Liam R. E. Quin <liam@fromoldbooks.org>
> *Cc:* public-xslt-40@w3.org
> *Subject:* Re: request as data source in transformation?
>
>
>
> Liam,
>
> "XProc pipelines are not limited to a linear succession of steps. They
> can fork and merge"
>
> from this definition the data source fits more into XSLT concept than into
> XProc.
>
>
>
> Also when it goes to Declarative Web Application, the 1-way transactional
> transformation nature of XSLT fits better.
>
> With all the flexibility of XProc, I do not see it fit into DWA.
>
>
>
> PS. My target here is to find the common denominator of web app needs and
> XML stack. XSLT so far is suitable. XPath-only or XProc are not. We can
> discuss the misfit on xproc-dev@w3.org if folks are interested.
>
>
>
>
>
> On Tue, Dec 20, 2022 at 6:54 PM Liam R. E. Quin <liam@fromoldbooks.org>
> wrote:
>
> On Tue, 2022-12-20 at 16:12 -0800, Sasha Firsov wrote:
> > 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.
>
> Are you sure that you are not trying to reinvent xproc 3, the pipeline
> language?
>
> liam
>
> >
>
> --
> Liam Quin, https://www.delightfulcomputing.com/
> Available for XML/Document/Information Architecture/XSLT/
> XSL/XQuery/Web/Text Processing/A11Y training, work & consulting.
> Barefoot Web-slave, antique illustrations:  http://www.fromoldbooks.org
>
>