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

[Javier de la T. <ja...@gm...>]

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/stati=
c meaning more than the standard/custom one.
>
> If everyone agrees I would opt for the dynamic/static terminology then an=
d 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 a=
ll 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 inconsiste=
nt.
>
> I think that the "customOutputModels" section is more related to the abil=
ity to dynamically process any output model specified in requests. In contr=
ast, the "predefinedOutputModels" is just a list of "static" output models =
that are understood by the provider, regardless of having the response sche=
ma 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 co=
uld 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
> >
>