<div dir="ltr"><br><div class="gmail_quote"><div dir="ltr"><div><div>I would like to add (remind) that the evolution plan includes a {metadata} capability that we nominally said would be part of SIA-2.1 but since it is another capability it could be defined there or in a new spec or in another spec (eg SODA-1.1). The {metadata} capability is intended to allow clients to get the necessary metadata for a single dataset (ID=...) so they can figure out how to call the SODA service and take advantage of all the features offered.<br><br></div>Now, that general usage pattern (make a remote call to get metadata) is nice an clean but it isn't necessarily optimal if you want to process many things the same way. I can understand Markus' idea to define domain metadata inline in a SODA service descriptor but it looks a lot like an optimisation to me. I' not saying it isn't useful/necessary to optimise, but I do not think we should try to do that without having tackled the general problem.<br><br></div>This also makes me now think that {metadata} is much more closely related to SODA than it is to SIA and it's a good thing we thought about detailed metadata but didn't do anything in SIA-2.0 when we didn't need it. So it is good to advertise intentions but not do anything concrete with them until we actually need them :-)<br></div><div class="gmail_extra"><div><div class="h5"><br><div class="gmail_quote"><span></span><br clear="all"></div><br></div></div><span class="HOEnZb"><font color="#888888">-- <br><div><div dir="ltr"><div><div>Patrick Dowler<br></div>Canadian Astronomy Data Centre<br></div>Victoria, BC, Canada<br></div></div>
</font></span></div>
</div><br><br clear="all"><br>-- <br><div class="gmail_signature"><div dir="ltr"><div><div>Patrick Dowler<br></div>Canadian Astronomy Data Centre<br></div>Victoria, BC, Canada<br></div></div>
</div>