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

["Döring, Markus"]

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
>