SimpleDALRegExt: maxImageSize

[Ray Plante]

Hi folks,

I have responded to all of the comments from the SimpleDALRegExt RFC 
but one; I'm presenting this last issue today in Sao Paulo.  I 
summarize here as well for you folks at home.  

The capability metadatum, maxImageSize, provides a way to indicate the 
maximum image size that the SIA service can return.  The schema 
currently in use and what was in the RFC version provides markup that 
allows one to give the size in pixels along longitudinal and 
latitudinal axes (i.e. with <long>, <lat>), and then has vague 
weezel words about images that don't line up on conical axes.  

Several people correctly pointed out that its not really important 
to know which is "longitudinal" or "latitudinal"--i.e. its 
orientation; we just need to know the extent and shape in pixels (and 
maybe shape is not important either).  Randy Thompson, wearing 
his publisher hat, suggested that this is likely how publishers have 
filled it in--i.e. not being concerned which number goes where.  I 
think this is closer to the original intent expressed in the SIA spec.  

I see three possible ways to do this to bring the maxImageSize 
definition closer to this intent: 

  1.  Keep the XML schema definition as it is, but put in the document 
      words that say that it doesn't matter which number goes in 
      <long> and which goes in <lat>.  

  2.  Change the definition of maxImageSize to take an array of pixel 
      lengths, as in:

        <maxImageSize>4000 6000</maxImageSize>

      (or even,
        <maxImageSize>4000 6000 100</maxImageSize>
      )

  3.  Change the definition of maxImageSize to mark up the individual 
      axis lengths:

        <maxImageSize>
           <axisLength>4000</axisLength>
           <axisLength>6000</axisLength>
           ...
        </maxImageSize>
        
Here are some considerations:

  a.  (1) has the advantage of being backward compatible with the 
      current schema in use.  This, in general, means it has no impact 
      on existing records.  (2) and (3) would require that existing 
      records be updated.  

  b.  Very soon, we will be updating all of these DAL records anyway 
      to comply with the update VODataService; thus, we might argue 
      that we shouldn't worry about being backward-compatible with the 
      capability part.  My only concern is in the period where some 
      registries have upgrade and others have not.  Will the fact that 
      we have two versions (with different namespace URIs, of course)
      of the schemas running around out there be a problem for either 
      applications or registry providers.  

  c.  While (2) is more compact (good for consuming applications), its 
      harder to validate and might be harder for applications like our 
      publishing interface.  (3) solves this problem.  I doubt that 
      there are any consuming applications that make use of this 
      metadata, so the bigger concern might be for consuming registry 
      apps. 

For my own opinion, I think I prefer option (3); however, I am 
concerned about the possible disruptions to registries with such a 
change.  I discussed this with my VAO colleagues, we gravitated toward 
(3), but we would like hear from others.

thanks,
Ray