Re: [PyWrapper-devel] WG: tapir: capabilities

[<m.d...@BG...>]

I was just about to edit the schema and realizing that output models are =
only specified for searches. but what about views? they use query =
templates, yes. but only the ones listed in capabilities? we should have =
dynamic ones here as well I think. And they link back to static/dynamic =
models.

So should models maybe become a seperate section not tight to =
search/view operations? I am going to modify the schema nevertheless =
already to accomodate the changes below - ignoring views for now.

Markus


-----Original Message-----
From:	Javier privat
Sent:	Mon 7/17/2006 4:00 PM
To:	D=F6ring, Markus
Cc:	Copp, Charles; Renato De Giovanni; =
pyw...@li...; tdw...@li...
Subject:	Re: WG: tapir: capabilities

I suppose is fine yes...
It is also easier to explain dynamic/static :)

Javi.

On 7/17/06, "D=F6ring, Markus" <m.d...@bg...> wrote:
> Renato,
> I agree with your remarks. And I think we should stress the =
dynamic/static meaning more than the standard/custom one.
>
> If everyone agrees I would opt for the dynamic/static terminology then =
and modify the capabilities section as renato has outlined?. Especially =
as we have been refering to dynamic models ever since.
>
> -- Markus
>
>
> > -----Urspr=FCngliche Nachricht-----
> > Von: Copp, Charles
> > Gesendet: Montag, 17. Juli 2006 15:29
> > An: Renato De Giovanni
> > Cc: D=F6ring, Markus; Javier privat
> > Betreff: Re: WG: tapir: capabilities
> >
> > I think - standard/custom or static/dynamic is a choice of
> > terms that either would suit depending on how you want to
> > emphasise what they do.
> >
> > standard - meaning it comes provided for you as part of the
> > service you are contacting and custom means that it can be
> > changed and the user declares it.  static/dynamic emphasise
> > what the service is doing in processing terms.
> >
> > I think your Renato's comment on <structure> makes sense.
> >
> > Charles
> >
> >
> >
>
> Hi,
>
> I think I'm fine with any of the options. It could be "standard" if =
you all liked. The only detail is that a standardOutputModel doesn't =
necessarily come from an external library of standard models. It can =
also be something specifically tailored by the data provider for some =
reason.
>
> By the way, I'm looking at the schema now and it seems to be possible =
to have a "customOutputModels" element with attribute "accepted=3Dtrue"
> but with no schema structure capabilities specified - which is =
inconsistent.
>
> I think that the "customOutputModels" section is more related to the =
ability to dynamically process any output model specified in requests. =
In contrast, the "predefinedOutputModels" is just a list of "static" =
output models that are understood by the provider, regardless of having =
the response schema structure processed dynamically or not.
>
> So another possibility would be:
>
> <staticOutputModels>
>  ...list of outputModels...
> </staticOutputModels>
> <dynamicOutputModels>
>   <structure>...</structure>
> <dynamicOutputModels>
>
> In this case <structure> could become mandatory (minOccurs=3D1) and we =
could remove the attribute "accepted".
> Just another idea...
> --
> Renato
>
>
> On 17 Jul 2006 at 13:20, "D=F6ring, Markus" wrote:
>
> > hi,
> > a name for "predefined" model.
> > charles suggests "standard" as oppoased to custom.
> > I think that hits the nail on the head.
> >
> > other suggestions so far:
> > - standard
> > - shared
> > - preconfigured
> > - known
> > - available
> >
> >
> > lets pick!
> >
> >
> > -- Markus
> >
>