Dear all,
I think there are issues pending. I think the getCapabilities has not been discussed openly enough, and should do so. Same thing for stageData. Therefore, these things will have to be discussed openly with the whole community. For example, I disagree on the way the getCapabilities functionality is being planned. And with me, some other people.
With respect to the VOQL-TEG list, nobody but VOQL-TEG members should incur in this list as we agreed in the creation of the group.
I copied Roy Williams (as IVOA TCG Chair) as there was some misunderstanding problem in the past reported by Doug to him on this VOQL-TEG, which Roy transferred to the Exec.
With respect to Bob, I don't understand why Doug introduced him.
To make a long story short: please proceed as we have agreed since the very beginning: VOQL-TEG members only can feed this forum. Others, have to send their voices through their corresponding representative.
In this line, may I remind you that the official representative in this group for the American NVO is Alex Szalay, and not Doug Tody. Doug is here as permanent invited to care for DAL interests in the creation of the TAP.
Should you have any problem with this approach, please let me know offline. Otherwise, with respects, we sign off Roy, Ray and Bob from this list. Of course, they can always (since the very beginning) follow the discussions in the forum archive.
Regards,
P.
On Wed, 2007-04-25 at 14:01 -0700, Roy Williams wrote:
> Doug
> You are right in principle in all that you say.
>
> > It has always been this way (except for cone search, which is the
> > trivial exception). SIA V1 has FORMAT=metadata, which returns service
> > metadata; this is the previous incarnation of getCapabilities.
> And that is why the SIA services that I have built are not listed in the
> VO registry -- because they are not complete, which is because I never
> got around to the FORMAT=metadata section. But I use them and find them
> useful all the same. If the specification did not have so many MANDATORY
> pieces, there would be a lot more astronomical data available, although
> the services would be less uniform.
>
> > getCapabilities tries to be more compatible
> > with an actual VOResource record.
>
> This is of course a nice model -- the service acting as its own
> "micro-registry". But the problem is that services are now much more
> difficult to implement: all the UCDs and utypes for the output table,
> the heartbeat services and logging with the RunID, and now the
> requirement to create a giant complicated XML document.
>
> Where is the software support for all this *mandatory* functionality?
> The actual astronomy logic is a tiny part now of all the IVOA complexity
> that surrounds it. This would be perfectly OK if there were software and
> documentation and tutorials about how to make a VO service. Who is
> making the "service provider package" so that data providers can just
> install and tweak, and moreover do it with their favorite language?
> Another question: is there a SINGLE service out there that does ALL the
> tricks (heartbeat, capabilities, logging, WSDL, STC coverage, etc)?
>
> > if anything changes the service implementation
> > can update (or even autogenerate) its own service metadata,
>
> I do not agree, and here is my scenario. What the original implementor
> did was to copy a record from the registry and edit it with Notepad,
> without really knowing much about XML or VOResource. When the result is
> not valid XML, there will be a delay of 3 months before trying again.
> When there are changes to the service, the implementor will probably do
> nothing, not wanting to dive into the horrible XML again. When the
> Registry curators come calling saying your VOResource is broken, the
> implementor may go back to the registry and attempt to use the
> publish/update forms to make the changes, but then harvesting happens
> and the edited version is replaced by the old one from the service itself.
>
> It seems we are just dumping more and more work on the service
> implementor, but without making the bulletproof infrastructure that they
> need to do the job effectively.
>
> Roy
-- Pedro Osuna Alcalaya European Space Agency (ESA) European Space Astronomy Centre (ESAC) Research and Scientific Support Department (RSSD) Astronomy Science Operations Division (SCI-SD) e-mail: Pedro.Osuna-at-esa.int Tel + 34 91 813 13 14 Fax: +34 91 813 11 72 ------------------------------------------------- European Space Astronomy Centre (ESAC) P.O. Box 50727 E-28080 Villafranca del Castillo MADRID - SPAIN ================================================================================================ This message and any attachments are intended for the use of the addressee or addressees only. The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its content is prohibited. If you received this message in error, please delete it from your system and notify the sender. E-mails can be altered and their integrity cannot be guaranteed. ESA shall not be liable for any e-mail if modified. =================================================================================================Received on 2007-04-26Z10:09:36