[tdwg-tapir] RE: WG: tapir: capabilities

["Döring, Markus"]

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öring, Markus
Cc:	Copp, Charles; Renato De Giovanni; pywrapper-devel at lists.sourceforge.net; tdwg-tapir at lists.tdwg.org
Subject:	Re: WG: tapir: capabilities

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

Javi.

On 7/17/06, "Döring, Markus" <m.doering at bgbm.org> 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üngliche Nachricht-----
> > Von: Copp, Charles
> > Gesendet: Montag, 17. Juli 2006 15:29
> > An: Renato De Giovanni
> > Cc: Döring, 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=true"
> 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=1) and we could remove the attribute "accepted".
> Just another idea...
> --
> Renato
>
>
> On 17 Jul 2006 at 13:20, "Döring, 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
> >
>