pywrapper-devel

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

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

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.=20

-- Markus
 =20

> -----Urspr=FCngliche Nachricht-----
> Von: Copp, Charles=20
> Gesendet: Montag, 17. Juli 2006 15:29
> An: Renato De Giovanni
> Cc: D=F6ring, Markus; Javier privat
> Betreff: Re: WG: tapir: capabilities
>=20
> I think - standard/custom or static/dynamic is a choice of=20
> terms that either would suit depending on how you want to=20
> emphasise what they do.
>=20
> standard - meaning it comes provided for you as part of the=20
> service you are contacting and custom means that it can be=20
> changed and the user declares it.  static/dynamic emphasise=20
> what the service is doing in processing terms.
>=20
> I think your Renato's comment on <structure> makes sense.
>=20
> Charles
>=20
>=20
>=20

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"=20
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".=20
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.
>=20
> other suggestions so far:
> - standard
> - shared
> - preconfigured
> - known
> - available
>=20
>=20
> lets pick!
>=20
>=20
> -- Markus
> =20

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
> >
>

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

[Renato De G. <re...@cr...>]

Hi,

If I remember well, the "view" operation was re-included in the 
protocol just to handle query templates, especifically for TapirLite 
providers. So if someone wants to query a provider using some 
external output model that should be dynamically parsed, then the 
"search" operation must be used instead (using either XML or simple 
GET request). View operations are really bound to query templates, 
and they are not allowed to specify "filter" or "partial" parameters.
--
Renato

On 17 Jul 2006 at 21:26, "D=F6ring, Markus" wrote:

> 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

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

[John R. W. <tu...@be...>]

A little off topic, but it occurs to me that a great deal of work is still
ongoing with TAPIR, which suggests to me that it may be warranted to
re-state my request for a simple message type - a log request. This request
would be the same as a search request, except that the caller doesn't need =
a
response. Providers would use this type of request to log data usage if the
data were retrieved from a cache elsewhere. I remember talking about this i=
n
Berlin, at which time there was supposed to be a feature freeze. Clearly
we've gone beyond that, so I'm requesting it again.

On 7/17/06, Renato De Giovanni <re...@cr...> wrote:
>
> Hi,
>
> If I remember well, the "view" operation was re-included in the
> protocol just to handle query templates, especifically for TapirLite
> providers. So if someone wants to query a provider using some
> external output model that should be dynamically parsed, then the
> "search" operation must be used instead (using either XML or simple
> GET request). View operations are really bound to query templates,
> and they are not allowed to specify "filter" or "partial" parameters.
> --
> Renato
>
> On 17 Jul 2006 at 21:26, "D=F6ring, Markus" wrote:
>
> > 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
>
> _______________________________________________
> tdwg-tapir mailing list
> tdw...@li...
> http://lists.tdwg.org/mailman/listinfo/tdwg-tapir
>

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

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

yes and no.
sure you need a template for views. but do we force providers to =
register supported templates? If an implementation can handle dynamic =
models, it surely can handle "dynamic" templates. And even if a =
providers says I only understand those 4 models, all query templates =
based on those 4 models should be easy to be processed. So =
dynamic/static models are important for views as well, cause templates =
are based on them.

But if the intention of views was/is for TapirLite only, then registered =
lists of templates are needed and dynamic templates dont make too much =
sense. And searches and inventories without templates could always also =
be called through their respective GET versions as well. So yes, an =
implementation could process "dynamic" templates, but maybe we just dont =
need them.=20

Then again if providers need to configure supported templates, all =
installations would be different - unless the implementation can handle =
"dynamic" templates and just retrieves all available query templates for =
their supported models from a central service and registers them =
automatically for the provider.


-- Markus
 =20

> -----Urspr=FCngliche Nachricht-----
> Von: pyw...@li...=20
> [mailto:pyw...@li...] Im=20
> Auftrag von Renato De Giovanni
> Gesendet: Montag, 17. Juli 2006 23:01
> An: tdw...@li...
> Cc: pyw...@li...
> Betreff: Re: [PyWrapper-devel] WG: tapir: capabilities
>=20
> Hi,
>=20
> If I remember well, the "view" operation was re-included in=20
> the protocol just to handle query templates, especifically=20
> for TapirLite providers. So if someone wants to query a=20
> provider using some external output model that should be=20
> dynamically parsed, then the "search" operation must be used=20
> instead (using either XML or simple GET request). View=20
> operations are really bound to query templates, and they are=20
> not allowed to specify "filter" or "partial" parameters.
> --
> Renato
>=20
> On 17 Jul 2006 at 21:26, "D=F6ring, Markus" wrote:
>=20
> > I was just about to edit the schema and realizing that=20
> output models=20
> > are only specified for searches. but what about views? they=20
> use query=20
> > templates, yes. but only the ones listed in capabilities? we should=20
> > have dynamic ones here as well I think. And they link back to=20
> > static/dynamic models.
> >=20
> > So should models maybe become a seperate section not tight to=20
> > search/view operations? I am going to modify the schema=20
> nevertheless=20
> > already to accomodate the changes below - ignoring views for now.
> >=20
> > Markus
>=20
>=20
> --------------------------------------------------------------
> -----------
> Take Surveys. Earn Cash. Influence the Future of IT Join=20
> SourceForge.net's Techsay panel and you'll get the chance to=20
> share your opinions on IT & business topics through brief=20
> surveys -- and earn cash=20
> http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge
&CID=3DDEVDEV
> _______________________________________________
> PyWrapper-devel mailing list
> PyW...@li...
> https://lists.sourceforge.net/lists/listinfo/pywrapper-devel
>=20

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
> >
>