Re: Common HTTP Model


I still think I have a problem with this spec defining two things,
i.e. a model and functions. I would rather see two specs, in this way
I or anyone else can choose to implement either or both of the model
and functions. It makes no sense to me to conflate the concept of
modelling with a function library. If you must you could split it into
two parts where both are optional, however I think two separate spec
documents is preferable even if they had to share the same namespace.

Also... just wondering why the URL is suffixed '/editor', is there
some sort of significance to that?

On 26 February 2015 at 19:34, Florent Georges <> wrote:
>   Just a quick email to point out there is already an editor draft at
>  I still have pending changes I
> need to commit, I'll have a look as soon as I can.
> --
> Florent Georges
> On 25 February 2015 at 13:30, Christian Grün wrote:
>>> Before the HTTP Client Module hits 1.0, it would be very nice if we
>>> could define a common XML HTTP Model for HTTP Requests/Responses
>>> (excluding bodies initially) which could live outside of the
>>> namespace.
>> Yes, I believe that an own spec for defining the HTTP model would make
>> sense. We have the HTTP Client Module and RESTXQ today, and we may
>> have other extensions in future that could be based on this model.
>> Maybe it even simplifies the finalization of the HTTP Client Module,
>> as it its contents will be more focused on the actual task.
>> +1 from me,
>> Christian

Adam Retter

eXist Developer
{ United Kingdom }

Received on Friday, 27 February 2015 22:31:10 UTC