IOMay07RWGIssues < IVOA

<small>Jumps:  [[http://www.ivoa.net/forum/registry/][reg-dm mail archive]] :: IvoaResReg :: RegistryInterface :: VOResourceV10 :: RegUpgradeToV10
<br/> Meetings: InterOpMay2006ResReg :: InterOpSep2006ResReg</small>

---+!! Summary of Registry Issues Discussed at the May 2007 <nop>InterOp

During the Registry sessions, we took a census of the assembly regarding a number of proposals.  This page summarizes the proposals and reports the consensus of the group in attendence.  Since a number of active working group meetings couldn't be at the meeting, we want to give folks an additional opportunity to offer comments and register their preferences before we take any decisions as final.  

Please review these items and add any comments you have, preferably by  8 June.

_Note: Page under construction_

%TOC%

---++ Minor RI standard issues

---+++ 1. VOResource root element in harvesting Identify response

   $ Problem: The RI spec requires that the element enclosing VOResource records returned through the search interface and the harvesting *ListRecords* operation to be =&lt;ri:Resource&gt;=.  The VOResource record returned via the harvesting *Identify* operation does not have this restriction (RI section 3.1.5).   
   $ Proposal:  Add same requirement on the <nop>VOResource root element to RI section 3.1.5.
   $ Consensus of attendees:  YES
   $ Additional Comments: 

_add your comments here_

---+++ 2. Should record requirements apply to deleted records

   $ Problem:  There are records that have been created in error but which have propogated to other registries; thus, they have been marked as deleted.  Often such records will be end up being non-compliant as a <nop>VOResource record; making it compliant would require editing the record (on behalf of the publisher).  Should we relax the compliance requirements for records marked deleted, or allow registry providers to edit the records appropriately?
   $ Question:  Should record requirements apply to deleted records?
   $ Consensus of attendees:  YES.  Registry curators can add place-holding values as needed so that they validate.
   $ Additional Comments: 

_add your comments here_

---+++ 3. Require the use of =xsi:schemaLocation= in harvesting interface

   $ Problem:  The use of =xsi:schemaLocation= is required in response through the search interface; however, that same requirement is not in the harvesting interface.  
   $ Proposal:  Make the use of =xsi:schemaLocation= required in the harvesting interface in the same way as in the search interface.  
   $ Consensus of attendees:  YES.  
   $ Additional Comments: 

_add your comments here_

---+++ 4. Require use of namespace prefixes in =xsi:type= values

   $ Problem:  Whether you are using the ADQL search method or XQuery, it is somewhat difficult to do precise matching on =xsi:type= values unless the use of namespace prefixes are required.  Consider two possible values, =xsi:type='vr:Service'= and =xsi:type='vs:DataService'=.  To match either in an ADQL search, you can provide the constraint, =xsi:type like '%Service'=.  To match only the generic service, you could say =xsi:type like '%:Service'= but only if you could be certain that a prefix will always be used.  In XML Schema, the prefix is not required if the type is from the default namespace. 
   $ Proposal:  Require the use of namespace prefixes in =xsi:type= values.
   $ Concensus of attendees:  TABLED.  While it was recognized that this presented a problem for clients, it was not clear whether this would be easy to control by registry implementations.  Prefixes are often handled automatically by the XML processing tools, and it's not clear that explicit control would always be possible.

   $ Additional Comments: 

If we do not reach any concensus on this, I think we should put it in only as a recommendation, but not a requirement. 
 
-- IVOA.RayPlante - 24 May 2007

_add your comments here_

---+++ 5. Location of namespace declarations

   $ Problem:  Cutting out VOResource records out of a Harvesting response can be a little tricky because one has to make sure all the namespace declarations are captured.  Particularly tricky is the appearance of a prefix within an =xsi:type== attribute value, because most XML parsers tend to ignore the prefix, treating the whole value as an opaque string.  If we required that all  namespace declarations used by the VOResource record appear within the VOResource portion of the OAI response (and not in the OAI envelope), it would be possible to lexically (i.e. not using an XML parser) to cut out the VOResource record at the start and end of the =&lt;ri:Resource&gt;= element.  
   $ Proposal:  Require that all namespace declarations used by the VOResource record appear within the VOResource portion of the OAI response.
   $ Consensus of attendees:  NO.  Like in (3) above, namespace declarations are often controled transparently by XML tools, and so it might be hard to control where they get placed.  
   $ Additional Comments: 

_add your comments here_

---++ Missing Agreements

I noticed that we neglected to integrate several agreements from the Victoria meeting into our standards, so we will need to do this.

---+++ 6. Searchability of core VOResource metadata

   $ Problem:  It was AGREED in Victoria that all searchable registries must support constraint-based searching against, at a minimum, all of the metadata terms in the VOResource schema.
   $ Proposal:  Update RI to reflect this agreement.
   $ Consensus of attendees:  YES.
   $ Additional Comments: 

_add your comments here_

---+++ 7. Returning full VOResource records
   $ Problem:  It was AGREED in Victoria that a registry must return the full VOResource record as it was originally constructed or as harvested from another registry.  RI does not specify this.  As a way to deal with the graininess issue, we thought that this requirement should be relaxed a bit, so as to allow extra fine grained information obtained by a means other than harvesting (e.g. directly from the service) to be returned to end users via the search interface.  
   $ Proposal:  Add requirement to RI that the original VOResource record must be returned in its original state via the harvesting interface; however, a registry may add additional information in the VOResource records returned via the search interface.
   $ Consensus of attendees:  YES.
   $ Additional Comments: 

_add your comments here_


_under construction_










<br/>
<!--
      * Set ALLOWTOPICRENAME = %MAINWEB%.TWikiAdminGroup
-->
This topic: IVOA > WebHome > IvoaEvents > InterOpMay2007 > InterOpMay2007ResReg > IOMay07RWGIssues
Topic revision: r5 - 2007-05-24 - RayPlante