An STC "when" and "where" example

[Alasdair Allan]

Matthew J. Graham wrote:
> Alasdair Allan wrote:
>> Arnold Rots wrote:
>>> Any parser that feels like it (or knows what they say) can skip the 
>>> included documents which are going to be part of a standard IVOA 
>>> library.
>>
>> ...write factory and parser toolkits in Perl, Python, Ruby, C, C++, 
>> C#, Fortran, Java, PHP and the half dozen other languages currently 
>> in use inside various projects that will be involved in creating and 
>> parsing VOEvent messages?
>
> OK, let's be realistic here: if you are serializing XML across the 
> Web, I believe with 95% confidence that you are using Java, C#, Perl 
> or Python (does anyone really write pure Fortran web services?)

Perhaps not, but a serialised VOEvent document isn't necessarily going 
to stay inside the walled garden on the VO. It could end up via email, 
or some raw TCP proprietary binary push, at an observatory that hasn't 
seen new code since Fortran 77 was just a glimmering in the eye.

On the other hand I know people who write pure C++ web services... and 
Ruby is widely used for web services in the "real world", although I 
don't know anyone who has talked about it inside the VO community.

Also PHP, if we're talking about portal implementations (and usually 
I'm not as I think portals are a big mistake and a total dead end, but 
that's another argument all together) then you also have to seriously 
worry about PHP. Anyone that does think portals are a good idea, and 
aren't using PHP to implement them, are probably slightly mad...

> so we need STC support libraries in these four languages. Now Java has 
> binding toolkits to handle XML <---> Java object and it needs to 
> verified that these will work with the STC schemata (previous versions 
> have not). I suspect that C# has a similar toolkit and Perl/Python?

Not that I know of, dynamically typed languages don't really work that 
way.

> Of course, the alternative way to access these verbose XML documents 
> is to apply an XPath statement against the XML document to retrieve 
> the elements/attributes you want:

Err, yuck.

> The harder part is actually creating the documents. With standards 
> like XForms being increasingly supported, doing this through an 
> interactive form on a browser is straightforward

Argh! We cannot assume there is ever (ever) a human in the loop. The 
documents have to be created and parsed easily programmatically. We 
cannot assume a call back to anything more intelligent than software!

> This just leaves programmatically creating the document: binding is 
> good here where it is possible, otherwise a simple solution might be 
> stylesheets that would populate an XML STC document from a simpler 
> key-value pair document: default values could also be defined in the 
> stylesheets.
>
> This type of approach will actually work with most of the languages 
> you mention with little additional work once it is implemented.

Yes, once it is implemented. That's what I'm going on about here, or at 
least one of the things I'm trying to get across at least. If we make 
this initial implementation too much of a struggle for developers, 
especially developers outside the immediate VO community, then we may 
as well stay home. We need as light a weight spec as we can get away 
with, at least initially.

Al.