DALI-1.0 RFCThis document will act as RFC centre for the Data Access Layer Interface 1.0 specification. The current version of the document is available at: http://www.ivoa.net/Documents/DALI/index.htmlRFC Review Period: 2013-02-22 to 2013-03-22
TCG Review Period: 2013-05-29 to 2013-06-26Implementation detailsLinks and description of existing interoperable implementations The specification describes common patterns and requirements for DAL services; it does not describe a single service that can be implemented. Still, existing TAP services implement most of the recommended practices with only small technical differences that can be addressed in a future version. Other DAL services like SIA and SSA are also more or less consistent with the recommended practices.Comments from the Communityduring the RFC PeriodPoints by MarkusDemleitner, 2013-03-14
Comment by Arnold RotsIn an attempt to be more specific, I suggest replacing the following text in Section 3.1.2: Values never include a time zone indicator and are always interpreted as UTC [17].In cases where values may be expressed using Julian Date (JD) or Modified Julian Date (MJD), these follow the rules for double precision numbers above and may have additional metadata as described in 4.4. by: Values must never include a time zone indicator and shall be interpreted as stated below. In cases where values may be expressed using Julian Date (JD) or Modified Julian Date (MJD), these follow the rules for double precision numbers above and may have additional metadata as described in 4.4. All date-time values (ISO-8601, JD, and MJD) shall be interpreted as referring to time scale UTC and time reference position UNKNOWN, unless either or both of these are explicitly specified to be different [17]. -- ArnoldRots - 2013-03-15
The VAO has reviewed this document and, aside from Arnold's comment above, has no further comments to make. -- MatthewGraham - 2013-03-19 Comments by Mark Taylor
Comments by Pierre Fernique
Comments from NormanGray (Semantics) 2013-04-04:These refer to version http://www.ivoa.net/Documents/DALI/20121210/WD-DALI-1.0-20121210.html Sect. 2: The table at the top of this section is neither referred to nor explained. Also what does 'required' = 'service specific' mean (does that mean it is or isn't required)?
Comments from TCG member during the TCG Review Period: 2013-05-29 to 2013-06-26WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or not the Standard. IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.TCG Chair & Vice Chair ( _Séverin Gaudet, Matthew Graham )Approved -- SeverinGaudet - 2013-09-19Applications Working Group ( _Mark Taylor, Pierre Fernique )Basically approved, but some suggestions to consider for the final version:
Data Access Layer Working Group ( Patrick Dowler, Francois Bonnarel )Approved -- PatrickDowler - 2013-09-18Data Model Working Group ( _Jesus Salgado, Omar Laurino )Approved with comments. | ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
Grid & Web Services Working Group ( Andre Schaaff, Andreas Wicenec )Approved -- AndreSchaaff - 2013-09-22Registry Working Group ( _Gretchen Greene, Pierre Le Sidaner )Approved -- GretchenGreene - 2013-09-20Semantics Working Group ( _Norman Gray, Mireille Louys )The document relies on the ISO8601 specification to express TIME stamps, as mentionned in Section 3.1.2.As other IVOA standards , like VOTable , f. i., rely on the FITS restricted usage of this specification, with UTC values possibly eluding the Z suffix , should we clarify that DALI supports the full ISO8601 specification? This document has no clash nor inconsistencies with respect to Semantic standards . Approved -- -- MireilleLouys - 2013-10-30 Response: Yes, there is a subtle inconsistency between ISO8601 and IVOA usage, which follows FITS usage and has been also noted in STC data model. I will change the language and references to make the format consistent with FITS and STC instead of ISO8601. -- PatrickDowler - 2013-11-07 Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )Time Domain Interest Group ( _John Swinbank, Mike Fitzpatrick )Approved -- MikeFitzpatrick - 2013-09-26Data Curation & Preservation Interest Group ( Alberto Accomazzi )Knowledge Discovery in Databases Interest Group ( George Djorgovski )Theory Interest Group ( _Franck Le Petit, Rick Wagner )Standards and Processes Committee ( Francoise Genova)<--
|
DALI-1.0 RFCThis document will act as RFC centre for the Data Access Layer Interface 1.0 specification. The current version of the document is available at: http://www.ivoa.net/Documents/DALI/index.htmlRFC Review Period: 2013-02-22 to 2013-03-22
TCG Review Period: 2013-05-29 to 2013-06-26Implementation detailsLinks and description of existing interoperable implementations The specification describes common patterns and requirements for DAL services; it does not describe a single service that can be implemented. Still, existing TAP services implement most of the recommended practices with only small technical differences that can be addressed in a future version. Other DAL services like SIA and SSA are also more or less consistent with the recommended practices.Comments from the Communityduring the RFC PeriodPoints by MarkusDemleitner, 2013-03-14
Comment by Arnold RotsIn an attempt to be more specific, I suggest replacing the following text in Section 3.1.2: Values never include a time zone indicator and are always interpreted as UTC [17].In cases where values may be expressed using Julian Date (JD) or Modified Julian Date (MJD), these follow the rules for double precision numbers above and may have additional metadata as described in 4.4. by: Values must never include a time zone indicator and shall be interpreted as stated below. In cases where values may be expressed using Julian Date (JD) or Modified Julian Date (MJD), these follow the rules for double precision numbers above and may have additional metadata as described in 4.4. All date-time values (ISO-8601, JD, and MJD) shall be interpreted as referring to time scale UTC and time reference position UNKNOWN, unless either or both of these are explicitly specified to be different [17]. -- ArnoldRots - 2013-03-15
The VAO has reviewed this document and, aside from Arnold's comment above, has no further comments to make. -- MatthewGraham - 2013-03-19 Comments by Mark Taylor
Comments by Pierre Fernique
Comments from NormanGray (Semantics) 2013-04-04:These refer to version http://www.ivoa.net/Documents/DALI/20121210/WD-DALI-1.0-20121210.html Sect. 2: The table at the top of this section is neither referred to nor explained. Also what does 'required' = 'service specific' mean (does that mean it is or isn't required)?
Comments from TCG member during the TCG Review Period: 2013-05-29 to 2013-06-26WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or not the Standard. IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.TCG Chair & Vice Chair ( _Séverin Gaudet, Matthew Graham )Approved -- SeverinGaudet - 2013-09-19Applications Working Group ( _Mark Taylor, Pierre Fernique )Basically approved, but some suggestions to consider for the final version:
Data Access Layer Working Group ( Patrick Dowler, Francois Bonnarel )Approved -- PatrickDowler - 2013-09-18Data Model Working Group ( _Jesus Salgado, Omar Laurino )Approved with comments.
Grid & Web Services Working Group ( Andre Schaaff, Andreas Wicenec )Approved -- AndreSchaaff - 2013-09-22Registry Working Group ( _Gretchen Greene, Pierre Le Sidaner )Approved -- GretchenGreene - 2013-09-20Semantics Working Group ( _Norman Gray, Mireille Louys )The document relies on the ISO8601 specification to express TIME stamps, as mentionned in Section 3.1.2.As other IVOA standards , like VOTable , f. i., rely on the FITS restricted usage of this specification, with UTC values possibly eluding the Z suffix , should we clarify that DALI supports the full ISO8601 specification? This document has no clash nor inconsistencies with respect to Semantic standards . Approved -- -- MireilleLouys - 2013-10-30 | ||||||||
Added: | ||||||||
> > | Response: Yes, there is a subtle inconsistency between ISO8601 and IVOA usage, which follows FITS usage and has been also noted in STC data model. I will change the language and references to make the format consistent with FITS and STC instead of ISO8601. -- PatrickDowler - 2013-11-07 | |||||||
Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )Time Domain Interest Group ( _John Swinbank, Mike Fitzpatrick )Approved -- MikeFitzpatrick - 2013-09-26Data Curation & Preservation Interest Group ( Alberto Accomazzi )Knowledge Discovery in Databases Interest Group ( George Djorgovski )Theory Interest Group ( _Franck Le Petit, Rick Wagner )Standards and Processes Committee ( Francoise Genova)<--
|
DALI-1.0 RFCThis document will act as RFC centre for the Data Access Layer Interface 1.0 specification. The current version of the document is available at: http://www.ivoa.net/Documents/DALI/index.htmlRFC Review Period: 2013-02-22 to 2013-03-22
TCG Review Period: 2013-05-29 to 2013-06-26Implementation detailsLinks and description of existing interoperable implementations The specification describes common patterns and requirements for DAL services; it does not describe a single service that can be implemented. Still, existing TAP services implement most of the recommended practices with only small technical differences that can be addressed in a future version. Other DAL services like SIA and SSA are also more or less consistent with the recommended practices.Comments from the Communityduring the RFC PeriodPoints by MarkusDemleitner, 2013-03-14
Comment by Arnold RotsIn an attempt to be more specific, I suggest replacing the following text in Section 3.1.2: Values never include a time zone indicator and are always interpreted as UTC [17].In cases where values may be expressed using Julian Date (JD) or Modified Julian Date (MJD), these follow the rules for double precision numbers above and may have additional metadata as described in 4.4. by: Values must never include a time zone indicator and shall be interpreted as stated below. In cases where values may be expressed using Julian Date (JD) or Modified Julian Date (MJD), these follow the rules for double precision numbers above and may have additional metadata as described in 4.4. All date-time values (ISO-8601, JD, and MJD) shall be interpreted as referring to time scale UTC and time reference position UNKNOWN, unless either or both of these are explicitly specified to be different [17]. -- ArnoldRots - 2013-03-15
The VAO has reviewed this document and, aside from Arnold's comment above, has no further comments to make. -- MatthewGraham - 2013-03-19 Comments by Mark Taylor
Comments by Pierre Fernique
Comments from NormanGray (Semantics) 2013-04-04:These refer to version http://www.ivoa.net/Documents/DALI/20121210/WD-DALI-1.0-20121210.html Sect. 2: The table at the top of this section is neither referred to nor explained. Also what does 'required' = 'service specific' mean (does that mean it is or isn't required)?
Comments from TCG member during the TCG Review Period: 2013-05-29 to 2013-06-26WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or not the Standard. IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.TCG Chair & Vice Chair ( _Séverin Gaudet, Matthew Graham )Approved -- SeverinGaudet - 2013-09-19Applications Working Group ( _Mark Taylor, Pierre Fernique )Basically approved, but some suggestions to consider for the final version:
Data Access Layer Working Group ( Patrick Dowler, Francois Bonnarel )Approved -- PatrickDowler - 2013-09-18Data Model Working Group ( _Jesus Salgado, Omar Laurino )Approved with comments.
Grid & Web Services Working Group ( Andre Schaaff, Andreas Wicenec )Approved -- AndreSchaaff - 2013-09-22Registry Working Group ( _Gretchen Greene, Pierre Le Sidaner )Approved -- GretchenGreene - 2013-09-20Semantics Working Group ( _Norman Gray, Mireille Louys ) | ||||||||
Added: | ||||||||
> > | The document relies on the ISO8601 specification to express TIME stamps, as mentionned in Section 3.1.2. As other IVOA standards , like VOTable , f. i., rely on the FITS restricted usage of this specification, with UTC values possibly eluding the Z suffix , should we clarify that DALI supports the full ISO8601 specification? This document has no clash nor inconsistencies with respect to Semantic standards . Approved -- -- MireilleLouys - 2013-10-30 | |||||||
Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )Time Domain Interest Group ( _John Swinbank, Mike Fitzpatrick )Approved -- MikeFitzpatrick - 2013-09-26Data Curation & Preservation Interest Group ( Alberto Accomazzi )Knowledge Discovery in Databases Interest Group ( George Djorgovski )Theory Interest Group ( _Franck Le Petit, Rick Wagner )Standards and Processes Committee ( Francoise Genova)<--
|
DALI-1.0 RFCThis document will act as RFC centre for the Data Access Layer Interface 1.0 specification. The current version of the document is available at: http://www.ivoa.net/Documents/DALI/index.htmlRFC Review Period: 2013-02-22 to 2013-03-22
TCG Review Period: 2013-05-29 to 2013-06-26Implementation detailsLinks and description of existing interoperable implementations The specification describes common patterns and requirements for DAL services; it does not describe a single service that can be implemented. Still, existing TAP services implement most of the recommended practices with only small technical differences that can be addressed in a future version. Other DAL services like SIA and SSA are also more or less consistent with the recommended practices.Comments from the Communityduring the RFC PeriodPoints by MarkusDemleitner, 2013-03-14
Comment by Arnold RotsIn an attempt to be more specific, I suggest replacing the following text in Section 3.1.2: Values never include a time zone indicator and are always interpreted as UTC [17].In cases where values may be expressed using Julian Date (JD) or Modified Julian Date (MJD), these follow the rules for double precision numbers above and may have additional metadata as described in 4.4. by: Values must never include a time zone indicator and shall be interpreted as stated below. In cases where values may be expressed using Julian Date (JD) or Modified Julian Date (MJD), these follow the rules for double precision numbers above and may have additional metadata as described in 4.4. All date-time values (ISO-8601, JD, and MJD) shall be interpreted as referring to time scale UTC and time reference position UNKNOWN, unless either or both of these are explicitly specified to be different [17]. -- ArnoldRots - 2013-03-15
The VAO has reviewed this document and, aside from Arnold's comment above, has no further comments to make. -- MatthewGraham - 2013-03-19 Comments by Mark Taylor
Comments by Pierre Fernique
Comments from NormanGray (Semantics) 2013-04-04:These refer to version http://www.ivoa.net/Documents/DALI/20121210/WD-DALI-1.0-20121210.html Sect. 2: The table at the top of this section is neither referred to nor explained. Also what does 'required' = 'service specific' mean (does that mean it is or isn't required)?
Comments from TCG member during the TCG Review Period: 2013-05-29 to 2013-06-26WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or not the Standard. IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.TCG Chair & Vice Chair ( _Séverin Gaudet, Matthew Graham )Approved -- SeverinGaudet - 2013-09-19Applications Working Group ( _Mark Taylor, Pierre Fernique )Basically approved, but some suggestions to consider for the final version:
Data Access Layer Working Group ( Patrick Dowler, Francois Bonnarel )Approved -- PatrickDowler - 2013-09-18Data Model Working Group ( _Jesus Salgado, Omar Laurino )Approved with comments.
Grid & Web Services Working Group ( Andre Schaaff, Andreas Wicenec ) | ||||||||
Added: | ||||||||
> > | ||||||||
Approved -- AndreSchaaff - 2013-09-22
Registry Working Group ( _Gretchen Greene, Pierre Le Sidaner )Approved -- GretchenGreene - 2013-09-20Semantics Working Group ( _Norman Gray, Mireille Louys )Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )Time Domain Interest Group ( _John Swinbank, Mike Fitzpatrick ) | ||||||||
Added: | ||||||||
> > | Approved -- MikeFitzpatrick - 2013-09-26 | |||||||
Data Curation & Preservation Interest Group ( Alberto Accomazzi )Knowledge Discovery in Databases Interest Group ( George Djorgovski )Theory Interest Group ( _Franck Le Petit, Rick Wagner )Standards and Processes Committee ( Francoise Genova)<--
|
DALI-1.0 RFCThis document will act as RFC centre for the Data Access Layer Interface 1.0 specification. The current version of the document is available at: http://www.ivoa.net/Documents/DALI/index.htmlRFC Review Period: 2013-02-22 to 2013-03-22
TCG Review Period: 2013-05-29 to 2013-06-26Implementation detailsLinks and description of existing interoperable implementations The specification describes common patterns and requirements for DAL services; it does not describe a single service that can be implemented. Still, existing TAP services implement most of the recommended practices with only small technical differences that can be addressed in a future version. Other DAL services like SIA and SSA are also more or less consistent with the recommended practices.Comments from the Communityduring the RFC PeriodPoints by MarkusDemleitner, 2013-03-14
Comment by Arnold RotsIn an attempt to be more specific, I suggest replacing the following text in Section 3.1.2: Values never include a time zone indicator and are always interpreted as UTC [17].In cases where values may be expressed using Julian Date (JD) or Modified Julian Date (MJD), these follow the rules for double precision numbers above and may have additional metadata as described in 4.4. by: Values must never include a time zone indicator and shall be interpreted as stated below. In cases where values may be expressed using Julian Date (JD) or Modified Julian Date (MJD), these follow the rules for double precision numbers above and may have additional metadata as described in 4.4. All date-time values (ISO-8601, JD, and MJD) shall be interpreted as referring to time scale UTC and time reference position UNKNOWN, unless either or both of these are explicitly specified to be different [17]. -- ArnoldRots - 2013-03-15
The VAO has reviewed this document and, aside from Arnold's comment above, has no further comments to make. -- MatthewGraham - 2013-03-19 Comments by Mark Taylor
Comments by Pierre Fernique
Comments from NormanGray (Semantics) 2013-04-04:These refer to version http://www.ivoa.net/Documents/DALI/20121210/WD-DALI-1.0-20121210.html Sect. 2: The table at the top of this section is neither referred to nor explained. Also what does 'required' = 'service specific' mean (does that mean it is or isn't required)?
Comments from TCG member during the TCG Review Period: 2013-05-29 to 2013-06-26WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or not the Standard. IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.TCG Chair & Vice Chair ( _Séverin Gaudet, Matthew Graham )Approved -- SeverinGaudet - 2013-09-19Applications Working Group ( _Mark Taylor, Pierre Fernique )Basically approved, but some suggestions to consider for the final version:
Data Access Layer Working Group ( Patrick Dowler, Francois Bonnarel )Approved -- PatrickDowler - 2013-09-18Data Model Working Group ( _Jesus Salgado, Omar Laurino )Approved with comments.
Grid & Web Services Working Group ( Andre Schaaff, Andreas Wicenec ) | ||||||||
Added: | ||||||||
> > | Approved -- AndreSchaaff - 2013-09-22 | |||||||
Registry Working Group ( _Gretchen Greene, Pierre Le Sidaner )Approved -- GretchenGreene - 2013-09-20Semantics Working Group ( _Norman Gray, Mireille Louys )Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )Time Domain Interest Group ( _John Swinbank, Mike Fitzpatrick )Data Curation & Preservation Interest Group ( Alberto Accomazzi )Knowledge Discovery in Databases Interest Group ( George Djorgovski )Theory Interest Group ( _Franck Le Petit, Rick Wagner )Standards and Processes Committee ( Francoise Genova)<--
|
DALI-1.0 RFCThis document will act as RFC centre for the Data Access Layer Interface 1.0 specification. The current version of the document is available at: http://www.ivoa.net/Documents/DALI/index.htmlRFC Review Period: 2013-02-22 to 2013-03-22
TCG Review Period: 2013-05-29 to 2013-06-26Implementation detailsLinks and description of existing interoperable implementations The specification describes common patterns and requirements for DAL services; it does not describe a single service that can be implemented. Still, existing TAP services implement most of the recommended practices with only small technical differences that can be addressed in a future version. Other DAL services like SIA and SSA are also more or less consistent with the recommended practices.Comments from the Communityduring the RFC PeriodPoints by MarkusDemleitner, 2013-03-14
Comment by Arnold RotsIn an attempt to be more specific, I suggest replacing the following text in Section 3.1.2: Values never include a time zone indicator and are always interpreted as UTC [17].In cases where values may be expressed using Julian Date (JD) or Modified Julian Date (MJD), these follow the rules for double precision numbers above and may have additional metadata as described in 4.4. by: Values must never include a time zone indicator and shall be interpreted as stated below. In cases where values may be expressed using Julian Date (JD) or Modified Julian Date (MJD), these follow the rules for double precision numbers above and may have additional metadata as described in 4.4. All date-time values (ISO-8601, JD, and MJD) shall be interpreted as referring to time scale UTC and time reference position UNKNOWN, unless either or both of these are explicitly specified to be different [17]. -- ArnoldRots - 2013-03-15
The VAO has reviewed this document and, aside from Arnold's comment above, has no further comments to make. -- MatthewGraham - 2013-03-19 Comments by Mark Taylor
Comments by Pierre Fernique
Comments from NormanGray (Semantics) 2013-04-04:These refer to version http://www.ivoa.net/Documents/DALI/20121210/WD-DALI-1.0-20121210.html Sect. 2: The table at the top of this section is neither referred to nor explained. Also what does 'required' = 'service specific' mean (does that mean it is or isn't required)?
Comments from TCG member during the TCG Review Period: 2013-05-29 to 2013-06-26WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or not the Standard. IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.TCG Chair & Vice Chair ( _Séverin Gaudet, Matthew Graham )Approved -- SeverinGaudet - 2013-09-19Applications Working Group ( _Mark Taylor, Pierre Fernique )Basically approved, but some suggestions to consider for the final version:
Data Access Layer Working Group ( Patrick Dowler, Francois Bonnarel )Approved -- PatrickDowler - 2013-09-18Data Model Working Group ( _Jesus Salgado, Omar Laurino )Approved with comments.
Grid & Web Services Working Group ( Andre Schaaff, Andreas Wicenec )Registry Working Group ( _Gretchen Greene, Pierre Le Sidaner ) | ||||||||
Added: | ||||||||
> > | Approved -- GretchenGreene - 2013-09-20 | |||||||
Semantics Working Group ( _Norman Gray, Mireille Louys )Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )Time Domain Interest Group ( _John Swinbank, Mike Fitzpatrick )Data Curation & Preservation Interest Group ( Alberto Accomazzi )Knowledge Discovery in Databases Interest Group ( George Djorgovski )Theory Interest Group ( _Franck Le Petit, Rick Wagner )Standards and Processes Committee ( Francoise Genova)<--
|
DALI-1.0 RFCThis document will act as RFC centre for the Data Access Layer Interface 1.0 specification. The current version of the document is available at: http://www.ivoa.net/Documents/DALI/index.htmlRFC Review Period: 2013-02-22 to 2013-03-22
TCG Review Period: 2013-05-29 to 2013-06-26Implementation detailsLinks and description of existing interoperable implementations The specification describes common patterns and requirements for DAL services; it does not describe a single service that can be implemented. Still, existing TAP services implement most of the recommended practices with only small technical differences that can be addressed in a future version. Other DAL services like SIA and SSA are also more or less consistent with the recommended practices.Comments from the Communityduring the RFC PeriodPoints by MarkusDemleitner, 2013-03-14
Comment by Arnold RotsIn an attempt to be more specific, I suggest replacing the following text in Section 3.1.2: Values never include a time zone indicator and are always interpreted as UTC [17].In cases where values may be expressed using Julian Date (JD) or Modified Julian Date (MJD), these follow the rules for double precision numbers above and may have additional metadata as described in 4.4. by: Values must never include a time zone indicator and shall be interpreted as stated below. In cases where values may be expressed using Julian Date (JD) or Modified Julian Date (MJD), these follow the rules for double precision numbers above and may have additional metadata as described in 4.4. All date-time values (ISO-8601, JD, and MJD) shall be interpreted as referring to time scale UTC and time reference position UNKNOWN, unless either or both of these are explicitly specified to be different [17]. -- ArnoldRots - 2013-03-15
The VAO has reviewed this document and, aside from Arnold's comment above, has no further comments to make. -- MatthewGraham - 2013-03-19 Comments by Mark Taylor
Comments by Pierre Fernique
Comments from NormanGray (Semantics) 2013-04-04:These refer to version http://www.ivoa.net/Documents/DALI/20121210/WD-DALI-1.0-20121210.html Sect. 2: The table at the top of this section is neither referred to nor explained. Also what does 'required' = 'service specific' mean (does that mean it is or isn't required)?
Comments from TCG member during the TCG Review Period: 2013-05-29 to 2013-06-26WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or not the Standard. IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.TCG Chair & Vice Chair ( _Séverin Gaudet, Matthew Graham ) | ||||||||
Added: | ||||||||
> > | Approved -- SeverinGaudet - 2013-09-19 | |||||||
Applications Working Group ( _Mark Taylor, Pierre Fernique )Basically approved, but some suggestions to consider for the final version:
Data Access Layer Working Group ( Patrick Dowler, Francois Bonnarel )Approved -- PatrickDowler - 2013-09-18Data Model Working Group ( _Jesus Salgado, Omar Laurino )Approved with comments.
Grid & Web Services Working Group ( Andre Schaaff, Andreas Wicenec )Registry Working Group ( _Gretchen Greene, Pierre Le Sidaner )Semantics Working Group ( _Norman Gray, Mireille Louys )Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )Time Domain Interest Group ( _John Swinbank, Mike Fitzpatrick )Data Curation & Preservation Interest Group ( Alberto Accomazzi )Knowledge Discovery in Databases Interest Group ( George Djorgovski )Theory Interest Group ( _Franck Le Petit, Rick Wagner )Standards and Processes Committee ( Francoise Genova)<--
|
DALI-1.0 RFCThis document will act as RFC centre for the Data Access Layer Interface 1.0 specification. The current version of the document is available at: http://www.ivoa.net/Documents/DALI/index.htmlRFC Review Period: 2013-02-22 to 2013-03-22
TCG Review Period: 2013-05-29 to 2013-06-26Implementation detailsLinks and description of existing interoperable implementations The specification describes common patterns and requirements for DAL services; it does not describe a single service that can be implemented. Still, existing TAP services implement most of the recommended practices with only small technical differences that can be addressed in a future version. Other DAL services like SIA and SSA are also more or less consistent with the recommended practices.Comments from the Communityduring the RFC PeriodPoints by MarkusDemleitner, 2013-03-14
Comment by Arnold RotsIn an attempt to be more specific, I suggest replacing the following text in Section 3.1.2: Values never include a time zone indicator and are always interpreted as UTC [17].In cases where values may be expressed using Julian Date (JD) or Modified Julian Date (MJD), these follow the rules for double precision numbers above and may have additional metadata as described in 4.4. by: Values must never include a time zone indicator and shall be interpreted as stated below. In cases where values may be expressed using Julian Date (JD) or Modified Julian Date (MJD), these follow the rules for double precision numbers above and may have additional metadata as described in 4.4. All date-time values (ISO-8601, JD, and MJD) shall be interpreted as referring to time scale UTC and time reference position UNKNOWN, unless either or both of these are explicitly specified to be different [17]. -- ArnoldRots - 2013-03-15
The VAO has reviewed this document and, aside from Arnold's comment above, has no further comments to make. -- MatthewGraham - 2013-03-19 Comments by Mark Taylor
Comments by Pierre Fernique
Comments from NormanGray (Semantics) 2013-04-04:These refer to version http://www.ivoa.net/Documents/DALI/20121210/WD-DALI-1.0-20121210.html Sect. 2: The table at the top of this section is neither referred to nor explained. Also what does 'required' = 'service specific' mean (does that mean it is or isn't required)?
Comments from TCG member during the TCG Review Period: 2013-05-29 to 2013-06-26WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or not the Standard. IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.TCG Chair & Vice Chair ( _Séverin Gaudet, Matthew Graham )Applications Working Group ( _Mark Taylor, Pierre Fernique )Basically approved, but some suggestions to consider for the final version:
| ||||||||
Added: | ||||||||
> > | relaxed the requirement so default version should be the latest version (but services can default to older if they think this is better, eg in the short term) and removed the bit about treating a REC differently than a PR or WD so that a PR could be the default. -- PatrickDowler - 2013-09-19 | |||||||
Data Access Layer Working Group ( Patrick Dowler, Francois Bonnarel )Approved -- PatrickDowler - 2013-09-18Data Model Working Group ( _Jesus Salgado, Omar Laurino )Approved with comments.
| ||||||||
Added: | ||||||||
> > | PhotDM removed -- PatrickDowler - 2013-09-19 | |||||||
| ||||||||
Changed: | ||||||||
< < | clarified to be as described below or service specific | |||||||
> > | clarified -- PatrickDowler - 2013-09-19 | |||||||
-- OmarLaurino - 2013-06-18
Grid & Web Services Working Group ( Andre Schaaff, Andreas Wicenec )Registry Working Group ( _Gretchen Greene, Pierre Le Sidaner )Semantics Working Group ( _Norman Gray, Mireille Louys )Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )Time Domain Interest Group ( _John Swinbank, Mike Fitzpatrick )Data Curation & Preservation Interest Group ( Alberto Accomazzi )Knowledge Discovery in Databases Interest Group ( George Djorgovski )Theory Interest Group ( _Franck Le Petit, Rick Wagner )Standards and Processes Committee ( Francoise Genova)<--
| ||||||||
Added: | ||||||||
> > |
| |||||||
| ||||||||
Added: | ||||||||
> > |
| |||||||
DALI-1.0 RFCThis document will act as RFC centre for the Data Access Layer Interface 1.0 specification. The current version of the document is available at: http://www.ivoa.net/Documents/DALI/index.htmlRFC Review Period: 2013-02-22 to 2013-03-22
TCG Review Period: 2013-05-29 to 2013-06-26Implementation detailsLinks and description of existing interoperable implementations The specification describes common patterns and requirements for DAL services; it does not describe a single service that can be implemented. Still, existing TAP services implement most of the recommended practices with only small technical differences that can be addressed in a future version. Other DAL services like SIA and SSA are also more or less consistent with the recommended practices.Comments from the Communityduring the RFC PeriodPoints by MarkusDemleitner, 2013-03-14
Comment by Arnold RotsIn an attempt to be more specific, I suggest replacing the following text in Section 3.1.2: Values never include a time zone indicator and are always interpreted as UTC [17].In cases where values may be expressed using Julian Date (JD) or Modified Julian Date (MJD), these follow the rules for double precision numbers above and may have additional metadata as described in 4.4. by: Values must never include a time zone indicator and shall be interpreted as stated below. In cases where values may be expressed using Julian Date (JD) or Modified Julian Date (MJD), these follow the rules for double precision numbers above and may have additional metadata as described in 4.4. All date-time values (ISO-8601, JD, and MJD) shall be interpreted as referring to time scale UTC and time reference position UNKNOWN, unless either or both of these are explicitly specified to be different [17]. -- ArnoldRots - 2013-03-15
The VAO has reviewed this document and, aside from Arnold's comment above, has no further comments to make. -- MatthewGraham - 2013-03-19 Comments by Mark Taylor
Comments by Pierre Fernique
Comments from NormanGray (Semantics) 2013-04-04:These refer to version http://www.ivoa.net/Documents/DALI/20121210/WD-DALI-1.0-20121210.html Sect. 2: The table at the top of this section is neither referred to nor explained. Also what does 'required' = 'service specific' mean (does that mean it is or isn't required)?
Comments from TCG member during the TCG Review Period: 2013-05-29 to 2013-06-26WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or not the Standard. IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.TCG Chair & Vice Chair ( _Séverin Gaudet, Matthew Graham )Applications Working Group ( _Mark Taylor, Pierre Fernique )Basically approved, but some suggestions to consider for the final version:
| ||||||||
Added: | ||||||||
> > | changed to may -- PatrickDowler - 2013-09-18 | |||||||
| ||||||||
Added: | ||||||||
> > | removed typeof="more" from link examples -- PatrickDowler - 2013-09-18 | |||||||
| ||||||||
Added: | ||||||||
> > | Two possible solutions: We could just say the default must be the latest version supported by the service, independent of whether it is a WD, PR, or REC? I'm OK with that... do we need to clarify that it is the latest declared version, where declared means the latest one described in the VOSI-capabilities and registry? That way someone could have a non-default prototype as long as they didn't put it in VOSI-capabilities. We could also make it more flexible by saying "SHOULD be the latest" instead of MUST. We could do both... | |||||||
| ||||||||
Added: | ||||||||
> > | fixed -- PatrickDowler - 2013-09-18 | |||||||
| ||||||||
Added: | ||||||||
> > | fixed -- PatrickDowler - 2013-09-18 | |||||||
| ||||||||
Added: | ||||||||
> > | clarified so that there is exactly one resource with type="results" and other resources may be included (either as specified for a service or by an implementer for their own reasons) -- PatrickDowler - 2013-09-18 | |||||||
| ||||||||
Added: | ||||||||
> > | This is partly backwards compat with client expectations and because it is a good practice in the implementation; in the case of an overflow or error during streaming output, having the OK status up front does tell the client that the request worked even if an overflow or error happened later. -- PatrickDowler - 2013-09-18 | |||||||
| ||||||||
Added: | ||||||||
> > | fixed -- PatrickDowler - 2013-09-18 | |||||||
| ||||||||
Added: | ||||||||
> > | removed -- PatrickDowler - 2013-09-18 | |||||||
-- MarkTaylor - 2013-06-05
Data Access Layer Working Group ( Patrick Dowler, Francois Bonnarel ) | ||||||||
Added: | ||||||||
> > | Approved -- PatrickDowler - 2013-09-18 | |||||||
Data Model Working Group ( _Jesus Salgado, Omar Laurino )Approved with comments.
| ||||||||
Added: | ||||||||
> > | text changed -- PatrickDowler - 2013-09-18 | |||||||
| ||||||||
Added: | ||||||||
> > | clarified (footnote at start of Sec 2) that HTTP is currently the only specified protocol but a future version may include other protocols; hopefully that explains the sometimes more flexible wording | |||||||
| ||||||||
Added: | ||||||||
> > | made them all lower case bold -- PatrickDowler - 2013-09-18 | |||||||
| ||||||||
Added: | ||||||||
> > | clarified to be as described below or service specific | |||||||
-- OmarLaurino - 2013-06-18
Grid & Web Services Working Group ( Andre Schaaff, Andreas Wicenec )Registry Working Group ( _Gretchen Greene, Pierre Le Sidaner )Semantics Working Group ( _Norman Gray, Mireille Louys )Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )Time Domain Interest Group ( _John Swinbank, Mike Fitzpatrick )Data Curation & Preservation Interest Group ( Alberto Accomazzi )Knowledge Discovery in Databases Interest Group ( George Djorgovski )Theory Interest Group ( _Franck Le Petit, Rick Wagner )Standards and Processes Committee ( Francoise Genova)<--
|
DALI-1.0 RFCThis document will act as RFC centre for the Data Access Layer Interface 1.0 specification. The current version of the document is available at: http://www.ivoa.net/Documents/DALI/index.htmlRFC Review Period: 2013-02-22 to 2013-03-22
TCG Review Period: 2013-05-29 to 2013-06-26Implementation detailsLinks and description of existing interoperable implementations The specification describes common patterns and requirements for DAL services; it does not describe a single service that can be implemented. Still, existing TAP services implement most of the recommended practices with only small technical differences that can be addressed in a future version. Other DAL services like SIA and SSA are also more or less consistent with the recommended practices.Comments from the Communityduring the RFC PeriodPoints by MarkusDemleitner, 2013-03-14
Comment by Arnold RotsIn an attempt to be more specific, I suggest replacing the following text in Section 3.1.2: Values never include a time zone indicator and are always interpreted as UTC [17].In cases where values may be expressed using Julian Date (JD) or Modified Julian Date (MJD), these follow the rules for double precision numbers above and may have additional metadata as described in 4.4. by: Values must never include a time zone indicator and shall be interpreted as stated below. In cases where values may be expressed using Julian Date (JD) or Modified Julian Date (MJD), these follow the rules for double precision numbers above and may have additional metadata as described in 4.4. All date-time values (ISO-8601, JD, and MJD) shall be interpreted as referring to time scale UTC and time reference position UNKNOWN, unless either or both of these are explicitly specified to be different [17]. -- ArnoldRots - 2013-03-15
The VAO has reviewed this document and, aside from Arnold's comment above, has no further comments to make. -- MatthewGraham - 2013-03-19 Comments by Mark Taylor
Comments by Pierre Fernique
Comments from NormanGray (Semantics) 2013-04-04:These refer to version http://www.ivoa.net/Documents/DALI/20121210/WD-DALI-1.0-20121210.html Sect. 2: The table at the top of this section is neither referred to nor explained. Also what does 'required' = 'service specific' mean (does that mean it is or isn't required)?
Comments from TCG member during the TCG Review Period: 2013-05-29 to 2013-06-26WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or not the Standard. IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.TCG Chair & Vice Chair ( _Séverin Gaudet, Matthew Graham )Applications Working Group ( _Mark Taylor, Pierre Fernique )Basically approved, but some suggestions to consider for the final version:
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
| ||||||||
Deleted: | ||||||||
< < | ||||||||
-- MarkTaylor - 2013-06-05
Data Access Layer Working Group ( Patrick Dowler, Francois Bonnarel )Data Model Working Group ( _Jesus Salgado, Omar Laurino ) | ||||||||
Added: | ||||||||
> > |
Approved with comments.
| |||||||
Grid & Web Services Working Group ( Andre Schaaff, Andreas Wicenec )Registry Working Group ( _Gretchen Greene, Pierre Le Sidaner )Semantics Working Group ( _Norman Gray, Mireille Louys )Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )Time Domain Interest Group ( _John Swinbank, Mike Fitzpatrick )Data Curation & Preservation Interest Group ( Alberto Accomazzi )Knowledge Discovery in Databases Interest Group ( George Djorgovski )Theory Interest Group ( _Franck Le Petit, Rick Wagner )Standards and Processes Committee ( Francoise Genova)<--
|
DALI-1.0 RFCThis document will act as RFC centre for the Data Access Layer Interface 1.0 specification. The current version of the document is available at: http://www.ivoa.net/Documents/DALI/index.htmlRFC Review Period: 2013-02-22 to 2013-03-22
TCG Review Period: 2013-05-29 to 2013-06-26Implementation detailsLinks and description of existing interoperable implementations The specification describes common patterns and requirements for DAL services; it does not describe a single service that can be implemented. Still, existing TAP services implement most of the recommended practices with only small technical differences that can be addressed in a future version. Other DAL services like SIA and SSA are also more or less consistent with the recommended practices.Comments from the Communityduring the RFC PeriodPoints by MarkusDemleitner, 2013-03-14
Comment by Arnold RotsIn an attempt to be more specific, I suggest replacing the following text in Section 3.1.2: Values never include a time zone indicator and are always interpreted as UTC [17].In cases where values may be expressed using Julian Date (JD) or Modified Julian Date (MJD), these follow the rules for double precision numbers above and may have additional metadata as described in 4.4. by: Values must never include a time zone indicator and shall be interpreted as stated below. In cases where values may be expressed using Julian Date (JD) or Modified Julian Date (MJD), these follow the rules for double precision numbers above and may have additional metadata as described in 4.4. All date-time values (ISO-8601, JD, and MJD) shall be interpreted as referring to time scale UTC and time reference position UNKNOWN, unless either or both of these are explicitly specified to be different [17]. -- ArnoldRots - 2013-03-15
The VAO has reviewed this document and, aside from Arnold's comment above, has no further comments to make. -- MatthewGraham - 2013-03-19 Comments by Mark Taylor
Comments by Pierre Fernique
Comments from NormanGray (Semantics) 2013-04-04:These refer to version http://www.ivoa.net/Documents/DALI/20121210/WD-DALI-1.0-20121210.html Sect. 2: The table at the top of this section is neither referred to nor explained. Also what does 'required' = 'service specific' mean (does that mean it is or isn't required)?
Comments from TCG member during the TCG Review Period: 2013-05-29 to 2013-06-26 | ||||||||
Deleted: | ||||||||
< < | !!! SECTION TO BE ADDED ONLY ONCE THE TCG REVIEW PERIOD HAS STARTED !!! | |||||||
WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or not the Standard.
IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.
TCG Chair & Vice Chair ( _Séverin Gaudet, Matthew Graham )Applications Working Group ( _Mark Taylor, Pierre Fernique ) | ||||||||
Added: | ||||||||
> > |
Basically approved, but some suggestions to consider for the final version:
| |||||||
Data Access Layer Working Group ( Patrick Dowler, Francois Bonnarel )Data Model Working Group ( _Jesus Salgado, Omar Laurino )Grid & Web Services Working Group ( Andre Schaaff, Andreas Wicenec )Registry Working Group ( _Gretchen Greene, Pierre Le Sidaner )Semantics Working Group ( _Norman Gray, Mireille Louys )Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )Time Domain Interest Group ( _John Swinbank, Mike Fitzpatrick )Data Curation & Preservation Interest Group ( Alberto Accomazzi )Knowledge Discovery in Databases Interest Group ( George Djorgovski )Theory Interest Group ( _Franck Le Petit, Rick Wagner )Standards and Processes Committee ( Francoise Genova)<--
|
DALI-1.0 RFCThis document will act as RFC centre for the Data Access Layer Interface 1.0 specification. The current version of the document is available at: http://www.ivoa.net/Documents/DALI/index.html | ||||||||
Changed: | ||||||||
< < | Review period: 2013-02-22 to 2013-03-22 | |||||||
> > | RFC Review Period: 2013-02-22 to 2013-03-22 | |||||||
Deleted: | ||||||||
< < | ||||||||
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
Deleted: | ||||||||
< < | ||||||||
In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your WikiName so authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment. Discussion about any of the comments or responses should be conducted on the DAL mailing list (dal@ivoa.net). However, please be sure to enter your initial comments here for full consideration in any future revisions of this document. | ||||||||
Changed: | ||||||||
< < | ||||||||
> > | TCG Review Period: 2013-05-29 to 2013-06-26 | |||||||
Implementation detailsLinks and description of existing interoperable implementations The specification describes common patterns and requirements for DAL services; it does not describe a single service that can be implemented. Still, existing TAP services implement most of the recommended practices with only small technical differences that can be addressed in a future version. Other DAL services like SIA and SSA are also more or less consistent with the recommended practices. | ||||||||
Changed: | ||||||||
< < | Comments from the Community | |||||||
> > | Comments from the Communityduring the RFC Period | |||||||
Points by MarkusDemleitner, 2013-03-14
Comment by Arnold RotsIn an attempt to be more specific, I suggest replacing the following text in Section 3.1.2: Values never include a time zone indicator and are always interpreted as UTC [17].In cases where values may be expressed using Julian Date (JD) or Modified Julian Date (MJD), these follow the rules for double precision numbers above and may have additional metadata as described in 4.4. by: Values must never include a time zone indicator and shall be interpreted as stated below. In cases where values may be expressed using Julian Date (JD) or Modified Julian Date (MJD), these follow the rules for double precision numbers above and may have additional metadata as described in 4.4. All date-time values (ISO-8601, JD, and MJD) shall be interpreted as referring to time scale UTC and time reference position UNKNOWN, unless either or both of these are explicitly specified to be different [17]. -- ArnoldRots - 2013-03-15
The VAO has reviewed this document and, aside from Arnold's comment above, has no further comments to make. -- MatthewGraham - 2013-03-19 Comments by Mark Taylor
Comments by Pierre Fernique
Comments from NormanGray (Semantics) 2013-04-04:These refer to version http://www.ivoa.net/Documents/DALI/20121210/WD-DALI-1.0-20121210.html Sect. 2: The table at the top of this section is neither referred to nor explained. Also what does 'required' = 'service specific' mean (does that mean it is or isn't required)?
| ||||||||
Added: | ||||||||
> > |
| |||||||
Sect. 3.2.3 RESPONSEFORMAT: since this is talking about MIME^WMedia types, it should be explicit about this. RFC 2616 Sect 3.7 (for example) gives a grammar for these, which matches the grammar in RFC 2045 Sect 5.1. It would probably be most appropriate to define the Media types in this specification to be equivalent to RFC 2616 sect 3.7.
| ||||||||
Deleted: | ||||||||
< < | <-- <-- <--
|
DALI-1.0 RFCThis document will act as RFC centre for the Data Access Layer Interface 1.0 specification. The current version of the document is available at: http://www.ivoa.net/Documents/DALI/index.html | ||||||||
Changed: | ||||||||
< < | Review period: 2013-02-22 to 2013-03-22 | |||||||
> > | Review period: 2013-02-22 to 2013-03-22 | |||||||
Added: | ||||||||
> > |
| |||||||
In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your WikiName so authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment.
Discussion about any of the comments or responses should be conducted on the DAL mailing list (dal@ivoa.net). However, please be sure to enter your initial comments here for full consideration in any future revisions of this document.
Implementation detailsLinks and description of existing interoperable implementations | ||||||||
Added: | ||||||||
> > | The specification describes common patterns and requirements for DAL services; it does not describe a single service that can be implemented. Still, existing TAP services implement most of the recommended practices with only small technical differences that can be addressed in a future version. Other DAL services like SIA and SSA are also more or less consistent with the recommended practices. | |||||||
Comments from the CommunityPoints by MarkusDemleitner, 2013-03-14
| ||||||||
Added: | ||||||||
> > |
| |||||||
Comment by Arnold RotsIn an attempt to be more specific, I suggest replacing the following text in Section 3.1.2: Values never include a time zone indicator and are always interpreted as UTC [17].In cases where values may be expressed using Julian Date (JD) or Modified Julian Date (MJD), these follow the rules for double precision numbers above and may have additional metadata as described in 4.4. by: Values must never include a time zone indicator and shall be interpreted as stated below. In cases where values may be expressed using Julian Date (JD) or Modified Julian Date (MJD), these follow the rules for double precision numbers above and may have additional metadata as described in 4.4. All date-time values (ISO-8601, JD, and MJD) shall be interpreted as referring to time scale UTC and time reference position UNKNOWN, unless either or both of these are explicitly specified to be different [17]. -- ArnoldRots - 2013-03-15
The VAO has reviewed this document and, aside from Arnold's comment above, has no further comments to make. -- MatthewGraham - 2013-03-19 Comments by Mark Taylor
Comments by Pierre Fernique
Comments from NormanGray (Semantics) 2013-04-04:These refer to version http://www.ivoa.net/Documents/DALI/20121210/WD-DALI-1.0-20121210.html Sect. 2: The table at the top of this section is neither referred to nor explained. Also what does 'required' = 'service specific' mean (does that mean it is or isn't required)?
<-- <-- <-- <-- <--
| ||||||||
Added: | ||||||||
> > |
| |||||||
DALI-1.0 RFCThis document will act as RFC centre for the Data Access Layer Interface 1.0 specification. The current version of the document is available at: http://www.ivoa.net/Documents/DALI/index.html Review period: 2013-02-22 to 2013-03-22 In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your WikiName so authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment. Discussion about any of the comments or responses should be conducted on the DAL mailing list (dal@ivoa.net). However, please be sure to enter your initial comments here for full consideration in any future revisions of this document.Implementation detailsLinks and description of existing interoperable implementationsComments from the CommunityPoints by MarkusDemleitner, 2013-03-14
Comment by Arnold RotsIn an attempt to be more specific, I suggest replacing the following text in Section 3.1.2: Values never include a time zone indicator and are always interpreted as UTC [17].In cases where values may be expressed using Julian Date (JD) or Modified Julian Date (MJD), these follow the rules for double precision numbers above and may have additional metadata as described in 4.4. by: Values must never include a time zone indicator and shall be interpreted as stated below. In cases where values may be expressed using Julian Date (JD) or Modified Julian Date (MJD), these follow the rules for double precision numbers above and may have additional metadata as described in 4.4. All date-time values (ISO-8601, JD, and MJD) shall be interpreted as referring to time scale UTC and time reference position UNKNOWN, unless either or both of these are explicitly specified to be different [17]. -- ArnoldRots - 2013-03-15
The VAO has reviewed this document and, aside from Arnold's comment above, has no further comments to make. -- MatthewGraham - 2013-03-19 Comments by Mark Taylor
| ||||||||
Added: | ||||||||
> > |
| |||||||
| ||||||||
Added: | ||||||||
> > |
| |||||||
| ||||||||
Added: | ||||||||
> > |
| |||||||
| ||||||||
Added: | ||||||||
> > |
| |||||||
-- MarkTaylor - 2013-03-21
Comments by Pierre Fernique
| ||||||||
Added: | ||||||||
> > |
| |||||||
| ||||||||
Added: | ||||||||
> > |
| |||||||
-- PierreFernique - 2013-03-28
Comments from NormanGray (Semantics) 2013-04-04:These refer to version http://www.ivoa.net/Documents/DALI/20121210/WD-DALI-1.0-20121210.html Sect. 2: The table at the top of this section is neither referred to nor explained. Also what does 'required' = 'service specific' mean (does that mean it is or isn't required)? | ||||||||
Changed: | ||||||||
< < | ||||||||
> > |
| |||||||
"Special requests to modify the phase of the job cause the job to execute or abort." Does this mean "There exist requests intended to cause the job to execute or abort", or "Any phase-changing requests cause (as an error/side-effect) the job to abort"? I'm guessing the former. | ||||||||
Changed: | ||||||||
< < | ||||||||
> > |
| |||||||
Sect 2.1: in the examples, the HTTP transaction is illustrated with a line which looks like an HTTP Request-Line, such as "POST http://example.com/base/async-jobs" and "GET http://example.com/base/async-jobs/123" (that is, apparently illustrating an element of the wire HTTP transaction). However we also see "POST FOO=bar http://example.com/base/async-jobs/123/parameters" which isn't a valid HTTP Request-Line. This subsection should perhaps include a forward reference to section 3. | ||||||||
Changed: | ||||||||
< < | ||||||||
> > |
| |||||||
The reference to the UWS standard ways of associating parameters with a POST is rather elliptical. A more detailed reference, or perhaps an example of each of the mechanisms, would be useful. After having read the text here (noting that the UWS spec describes parameters only in abstract terms), I still don't know how to specify parameters in a DALI request. | ||||||||
Changed: | ||||||||
< < | ||||||||
> > |
| |||||||
Section 2.3: I think there are very few SGML parsers on the web. Perhaps a useful distinction would be against HTML5, which isn't (if I recall correctly) specified in terms of XML. | ||||||||
Changed: | ||||||||
< < | ||||||||
> > |
| |||||||
The http://purl.org/astronomy/vocab/examples namespace doesn't at present exist. I can help set this up. | ||||||||
Changed: | ||||||||
< < | ||||||||
> > |
| |||||||
Sect. 3.2.3 RESPONSEFORMAT: since this is talking about MIME^WMedia types, it should be explicit about this. RFC 2616 Sect 3.7 (for example) gives a grammar for these, which matches the grammar in RFC 2045 Sect 5.1. It would probably be most appropriate to define the Media types in this specification to be equivalent to RFC 2616 sect 3.7. | ||||||||
Changed: | ||||||||
< < | ||||||||
> > |
| |||||||
What's the rationale for including the 'short form' response types? It seems to add only complication. | ||||||||
Changed: | ||||||||
< < | ||||||||
> > |
| |||||||
In this section, the string 'RESPONSEFORMAT' is in a couple of places half-italicised. | ||||||||
Changed: | ||||||||
< < | ||||||||
> > |
| |||||||
This section remarks "Individual DAL services [...] are free to support custom formats by accepting non-standard values"; but earlier it only talks of "the general usage", so appears to neither mandate nor exclude any values, so it's not clear what 'non-standard' means in this context. | ||||||||
Changed: | ||||||||
< < | ||||||||
> > |
| |||||||
"A DAL service [...] should fail ( 4.2 ) where the RESPONSEFORMAT parameter specifies a format not supported by the service implementation." Presumably the HTTP code 406 Not Acceptable would be used here, if the transaction is happening over HTTP -- perhaps this should be spelled out. | ||||||||
Changed: | ||||||||
< < | ||||||||
> > |
| |||||||
What happens if a client makes a DALI request over HTTP, and includes an Accept request header with one Media Type, and a RESPONSEFORMAT parameter with a conflicting one? Is the answer different between synchronous and asynchronous requests? | ||||||||
Changed: | ||||||||
< < | ||||||||
> > |
| |||||||
Sect. 4.2 Errors: 'otehr' -> 'other' | ||||||||
Changed: | ||||||||
< < | ||||||||
> > |
| |||||||
<-- <-- <-- <-- <--
|
DALI-1.0 RFCThis document will act as RFC centre for the Data Access Layer Interface 1.0 specification. The current version of the document is available at: http://www.ivoa.net/Documents/DALI/index.html Review period: 2013-02-22 to 2013-03-22 In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your WikiName so authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment. Discussion about any of the comments or responses should be conducted on the DAL mailing list (dal@ivoa.net). However, please be sure to enter your initial comments here for full consideration in any future revisions of this document.Implementation detailsLinks and description of existing interoperable implementationsComments from the CommunityPoints by MarkusDemleitner, 2013-03-14
| ||||||||
Added: | ||||||||
> > |
| |||||||
| ||||||||
Added: | ||||||||
> > |
| |||||||
| ||||||||
Added: | ||||||||
> > |
| |||||||
| ||||||||
Added: | ||||||||
> > |
| |||||||
| ||||||||
Added: | ||||||||
> > |
| |||||||
| ||||||||
Added: | ||||||||
> > |
| |||||||
| ||||||||
Added: | ||||||||
> > |
| |||||||
| ||||||||
Added: | ||||||||
> > |
| |||||||
| ||||||||
Added: | ||||||||
> > |
| |||||||
| ||||||||
Added: | ||||||||
> > |
| |||||||
| ||||||||
Added: | ||||||||
> > |
| |||||||
| ||||||||
Added: | ||||||||
> > |
| |||||||
| ||||||||
Added: | ||||||||
> > |
| |||||||
| ||||||||
Added: | ||||||||
> > |
| |||||||
| ||||||||
Added: | ||||||||
> > |
| |||||||
| ||||||||
Added: | ||||||||
> > |
| |||||||
| ||||||||
Added: | ||||||||
> > |
| |||||||
| ||||||||
Added: | ||||||||
> > |
| |||||||
Comment by Arnold RotsIn an attempt to be more specific, I suggest replacing the following text in Section 3.1.2: Values never include a time zone indicator and are always interpreted as UTC [17].In cases where values may be expressed using Julian Date (JD) or Modified Julian Date (MJD), these follow the rules for double precision numbers above and may have additional metadata as described in 4.4. by: Values must never include a time zone indicator and shall be interpreted as stated below. In cases where values may be expressed using Julian Date (JD) or Modified Julian Date (MJD), these follow the rules for double precision numbers above and may have additional metadata as described in 4.4. All date-time values (ISO-8601, JD, and MJD) shall be interpreted as referring to time scale UTC and time reference position UNKNOWN, unless either or both of these are explicitly specified to be different [17]. -- ArnoldRots - 2013-03-15 | ||||||||
Changed: | ||||||||
< < | ||||||||
> > |
| |||||||
The VAO has reviewed this document and, aside from Arnold's comment above, has no further comments to make. -- MatthewGraham - 2013-03-19 Comments by Mark Taylor
Comments by Pierre Fernique
Comments from NormanGray (Semantics) 2013-04-04: | ||||||||
Changed: | ||||||||
< < | These refer to version | |||||||
> > | These refer to version http://www.ivoa.net/Documents/DALI/20121210/WD-DALI-1.0-20121210.html | |||||||
Deleted: | ||||||||
< < | http://www.ivoa.net/Documents/DALI/20121210/WD-DALI-1.0-20121210.html | |||||||
Changed: | ||||||||
< < | Sect. 2: The table at the top of this section is neither referred to nor | |||||||
> > | Sect. 2: The table at the top of this section is neither referred to nor explained. Also what does 'required' = 'service specific' mean (does that mean it is or isn't required)? | |||||||
Deleted: | ||||||||
< < | explained. Also what does 'required' = 'service specific' mean (does that mean it is or isn't required)? | |||||||
Changed: | ||||||||
< < | "Special requests to modify the phase of the job cause the job to execute or | |||||||
> > | "Special requests to modify the phase of the job cause the job to execute or abort." Does this mean "There exist requests intended to cause the job to execute or abort", or "Any phase-changing requests cause (as an error/side-effect) the job to abort"? I'm guessing the former. | |||||||
Deleted: | ||||||||
< < | abort." Does this mean "There exist requests intended to cause the job to execute or abort", or "Any phase-changing requests cause (as an error/side-effect) the job to abort"? I'm guessing the former. | |||||||
Changed: | ||||||||
< < | Sect 2.1: in the examples, the HTTP transaction is illustrated with a line which | |||||||
> > | Sect 2.1: in the examples, the HTTP transaction is illustrated with a line which looks like an HTTP Request-Line, such as "POST http://example.com/base/async-jobs" and "GET http://example.com/base/async-jobs/123" (that is, apparently illustrating an element of the wire HTTP transaction). However we also see "POST FOO=bar http://example.com/base/async-jobs/123/parameters" which isn't a valid HTTP Request-Line. This subsection should perhaps include a forward reference to section 3. | |||||||
Deleted: | ||||||||
< < | looks like an HTTP Request-Line, such as "POST http://example.com/base/async-jobs" and "GET http://example.com/base/async-jobs/123" (that is, apparently illustrating an element of the wire HTTP transaction). However we also see "POST FOO=bar http://example.com/base/async-jobs/123/parameters" which isn't a valid HTTP Request-Line. This subsection should perhaps include a forward reference to section 3. | |||||||
Changed: | ||||||||
< < | The reference to the UWS standard ways of associating parameters with a POST | |||||||
> > | The reference to the UWS standard ways of associating parameters with a POST is rather elliptical. A more detailed reference, or perhaps an example of each of the mechanisms, would be useful. After having read the text here (noting that the UWS spec describes parameters only in abstract terms), I still don't know how to specify parameters in a DALI request. | |||||||
Deleted: | ||||||||
< < | is rather elliptical. A more detailed reference, or perhaps an example of each of the mechanisms, would be useful. After having read the text here (noting that the UWS spec describes parameters only in abstract terms), I still don't know how to specify parameters in a DALI request. | |||||||
Changed: | ||||||||
< < | Section 2.3: I think there are very few SGML parsers on the web. Perhaps a | |||||||
> > | Section 2.3: I think there are very few SGML parsers on the web. Perhaps a useful distinction would be against HTML5, which isn't (if I recall correctly) specified in terms of XML. | |||||||
Deleted: | ||||||||
< < | useful distinction would be against HTML5, which isn't (if I recall correctly) specified in terms of XML. | |||||||
Changed: | ||||||||
< < | The http://purl.org/astronomy/vocab/examples namespace doesn't at present exist. | |||||||
> > | The http://purl.org/astronomy/vocab/examples namespace doesn't at present exist. I can help set this up. | |||||||
Deleted: | ||||||||
< < | I can help set this up. | |||||||
Changed: | ||||||||
< < | Sect. 3.2.3 RESPONSEFORMAT: since this is talking about MIME^WMedia types, it should be | |||||||
> > | Sect. 3.2.3 RESPONSEFORMAT: since this is talking about MIME^WMedia types, it should be explicit about this. RFC 2616 Sect 3.7 (for example) gives a grammar for these, which matches the grammar in RFC 2045 Sect 5.1. It would probably be most appropriate to define the Media types in this specification to be equivalent to RFC 2616 sect 3.7. | |||||||
Deleted: | ||||||||
< < | explicit about this. RFC 2616 Sect 3.7 (for example) gives a grammar for these, which matches the grammar in RFC 2045 Sect 5.1. It would probably be most appropriate to define the Media types in this specification to be equivalent to RFC 2616 sect 3.7. | |||||||
Changed: | ||||||||
< < | What's the rationale for including the 'short form' response types? It seems | |||||||
> > | What's the rationale for including the 'short form' response types? It seems to add only complication. | |||||||
Deleted: | ||||||||
< < | to add only complication. | |||||||
Changed: | ||||||||
< < | In this section, the string 'RESPONSEFORMAT' is in a couple of places | |||||||
> > | In this section, the string 'RESPONSEFORMAT' is in a couple of places half-italicised. | |||||||
Deleted: | ||||||||
< < | half-italicised. | |||||||
Changed: | ||||||||
< < | This section remarks "Individual DAL services [...] are free | |||||||
> > | This section remarks "Individual DAL services [...] are free to support custom formats by accepting non-standard values"; but earlier it only talks of "the general usage", so appears to neither mandate nor exclude any values, so it's not clear what 'non-standard' means in this context. | |||||||
Deleted: | ||||||||
< < | to support custom formats by accepting non-standard values"; but earlier it only talks of "the general usage", so appears to neither mandate nor exclude any values, so it's not clear what 'non-standard' means in this context. | |||||||
Changed: | ||||||||
< < | "A DAL service [...] should fail ( 4.2 ) where the RESPONSEFORMAT parameter | |||||||
> > | "A DAL service [...] should fail ( 4.2 ) where the RESPONSEFORMAT parameter specifies a format not supported by the service implementation." Presumably the HTTP code 406 Not Acceptable would be used here, if the transaction is happening over HTTP -- perhaps this should be spelled out. | |||||||
Deleted: | ||||||||
< < | specifies a format not supported by the service implementation." Presumably the HTTP code 406 Not Acceptable would be used here, if the transaction is happening over HTTP -- perhaps this should be spelled out. | |||||||
Changed: | ||||||||
< < | What happens if a client makes a DALI request over HTTP, and includes an | |||||||
> > | What happens if a client makes a DALI request over HTTP, and includes an Accept request header with one Media Type, and a RESPONSEFORMAT parameter with a conflicting one? Is the answer different between synchronous and asynchronous requests? | |||||||
Deleted: | ||||||||
< < | Accept request header with one Media Type, and a RESPONSEFORMAT parameter with a conflicting one? Is the answer different between synchronous and asynchronous requests? | |||||||
Changed: | ||||||||
< < | Sect. 4.2 Errors: 'otehr' -> 'other' | |||||||
> > | Sect. 4.2 Errors: 'otehr' -> 'other' | |||||||
Deleted: | ||||||||
< < | ||||||||
<-- <-- <-- <-- <--
|
DALI-1.0 RFCThis document will act as RFC centre for the Data Access Layer Interface 1.0 specification. The current version of the document is available at: http://www.ivoa.net/Documents/DALI/index.html Review period: 2013-02-22 to 2013-03-22 In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your WikiName so authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment. Discussion about any of the comments or responses should be conducted on the DAL mailing list (dal@ivoa.net). However, please be sure to enter your initial comments here for full consideration in any future revisions of this document.Implementation detailsLinks and description of existing interoperable implementationsComments from the CommunityPoints by MarkusDemleitner, 2013-03-14
Comment by Arnold RotsIn an attempt to be more specific, I suggest replacing the following text in Section 3.1.2: Values never include a time zone indicator and are always interpreted as UTC [17].In cases where values may be expressed using Julian Date (JD) or Modified Julian Date (MJD), these follow the rules for double precision numbers above and may have additional metadata as described in 4.4. by: Values must never include a time zone indicator and shall be interpreted as stated below. In cases where values may be expressed using Julian Date (JD) or Modified Julian Date (MJD), these follow the rules for double precision numbers above and may have additional metadata as described in 4.4. All date-time values (ISO-8601, JD, and MJD) shall be interpreted as referring to time scale UTC and time reference position UNKNOWN, unless either or both of these are explicitly specified to be different [17]. -- ArnoldRots - 2013-03-15 The VAO has reviewed this document and, aside from Arnold's comment above, has no further comments to make. -- MatthewGraham - 2013-03-19 Comments by Mark Taylor
Comments by Pierre Fernique
| ||||||||
Added: | ||||||||
> > |
Comments from NormanGray (Semantics) 2013-04-04:These refer to version http://www.ivoa.net/Documents/DALI/20121210/WD-DALI-1.0-20121210.html Sect. 2: The table at the top of this section is neither referred to nor explained. Also what does 'required' = 'service specific' mean (does that mean it is or isn't required)? "Special requests to modify the phase of the job cause the job to execute or abort." Does this mean "There exist requests intended to cause the job to execute or abort", or "Any phase-changing requests cause (as an error/side-effect) the job to abort"? I'm guessing the former. Sect 2.1: in the examples, the HTTP transaction is illustrated with a line which looks like an HTTP Request-Line, such as "POST http://example.com/base/async-jobs" and "GET http://example.com/base/async-jobs/123" (that is, apparently illustrating an element of the wire HTTP transaction). However we also see "POST FOO=bar http://example.com/base/async-jobs/123/parameters" which isn't a valid HTTP Request-Line. This subsection should perhaps include a forward reference to section 3. The reference to the UWS standard ways of associating parameters with a POST is rather elliptical. A more detailed reference, or perhaps an example of each of the mechanisms, would be useful. After having read the text here (noting that the UWS spec describes parameters only in abstract terms), I still don't know how to specify parameters in a DALI request. Section 2.3: I think there are very few SGML parsers on the web. Perhaps a useful distinction would be against HTML5, which isn't (if I recall correctly) specified in terms of XML. The http://purl.org/astronomy/vocab/examples namespace doesn't at present exist. I can help set this up. Sect. 3.2.3 RESPONSEFORMAT: since this is talking about MIME^WMedia types, it should be explicit about this. RFC 2616 Sect 3.7 (for example) gives a grammar for these, which matches the grammar in RFC 2045 Sect 5.1. It would probably be most appropriate to define the Media types in this specification to be equivalent to RFC 2616 sect 3.7. What's the rationale for including the 'short form' response types? It seems to add only complication. In this section, the string 'RESPONSEFORMAT' is in a couple of places half-italicised. This section remarks "Individual DAL services [...] are free to support custom formats by accepting non-standard values"; but earlier it only talks of "the general usage", so appears to neither mandate nor exclude any values, so it's not clear what 'non-standard' means in this context. "A DAL service [...] should fail ( 4.2 ) where the RESPONSEFORMAT parameter specifies a format not supported by the service implementation." Presumably the HTTP code 406 Not Acceptable would be used here, if the transaction is happening over HTTP -- perhaps this should be spelled out. What happens if a client makes a DALI request over HTTP, and includes an Accept request header with one Media Type, and a RESPONSEFORMAT parameter with a conflicting one? Is the answer different between synchronous and asynchronous requests? Sect. 4.2 Errors: 'otehr' -> 'other' | |||||||
<-- <-- <-- <-- <--
|
DALI-1.0 RFCThis document will act as RFC centre for the Data Access Layer Interface 1.0 specification. The current version of the document is available at: http://www.ivoa.net/Documents/DALI/index.html Review period: 2013-02-22 to 2013-03-22 In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your WikiName so authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment. Discussion about any of the comments or responses should be conducted on the DAL mailing list (dal@ivoa.net). However, please be sure to enter your initial comments here for full consideration in any future revisions of this document.Implementation detailsLinks and description of existing interoperable implementationsComments from the CommunityPoints by MarkusDemleitner, 2013-03-14
Comment by Arnold RotsIn an attempt to be more specific, I suggest replacing the following text in Section 3.1.2: Values never include a time zone indicator and are always interpreted as UTC [17].In cases where values may be expressed using Julian Date (JD) or Modified Julian Date (MJD), these follow the rules for double precision numbers above and may have additional metadata as described in 4.4. by: Values must never include a time zone indicator and shall be interpreted as stated below. In cases where values may be expressed using Julian Date (JD) or Modified Julian Date (MJD), these follow the rules for double precision numbers above and may have additional metadata as described in 4.4. All date-time values (ISO-8601, JD, and MJD) shall be interpreted as referring to time scale UTC and time reference position UNKNOWN, unless either or both of these are explicitly specified to be different [17]. -- ArnoldRots - 2013-03-15 The VAO has reviewed this document and, aside from Arnold's comment above, has no further comments to make. -- MatthewGraham - 2013-03-19 Comments by Mark Taylor | ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
-- MarkTaylor - 2013-03-21 | ||||||||
Changed: | ||||||||
< < | ||||||||
> > | Comments by Pierre Fernique | |||||||
Added: | ||||||||
> > |
| |||||||
<-- <-- <-- <-- <--
|
DALI-1.0 RFCThis document will act as RFC centre for the Data Access Layer Interface 1.0 specification. The current version of the document is available at: http://www.ivoa.net/Documents/DALI/index.html Review period: 2013-02-22 to 2013-03-22 In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your WikiName so authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment. Discussion about any of the comments or responses should be conducted on the DAL mailing list (dal@ivoa.net). However, please be sure to enter your initial comments here for full consideration in any future revisions of this document.Implementation detailsLinks and description of existing interoperable implementationsComments from the CommunityPoints by MarkusDemleitner, 2013-03-14
Comment by Arnold RotsIn an attempt to be more specific, I suggest replacing the following text in Section 3.1.2: Values never include a time zone indicator and are always interpreted as UTC [17].In cases where values may be expressed using Julian Date (JD) or Modified Julian Date (MJD), these follow the rules for double precision numbers above and may have additional metadata as described in 4.4. by: Values must never include a time zone indicator and shall be interpreted as stated below. In cases where values may be expressed using Julian Date (JD) or Modified Julian Date (MJD), these follow the rules for double precision numbers above and may have additional metadata as described in 4.4. All date-time values (ISO-8601, JD, and MJD) shall be interpreted as referring to time scale UTC and time reference position UNKNOWN, unless either or both of these are explicitly specified to be different [17]. -- ArnoldRots - 2013-03-15 The VAO has reviewed this document and, aside from Arnold's comment above, has no further comments to make. -- MatthewGraham - 2013-03-19 | ||||||||
Added: | ||||||||
> > | ||||||||
Changed: | ||||||||
< < |
| |||||||
> > | Comments by Mark Taylor
| |||||||
Added: | ||||||||
> > |
| |||||||
<-- <-- <-- <-- <--
|
DALI-1.0 RFCThis document will act as RFC centre for the Data Access Layer Interface 1.0 specification. The current version of the document is available at: http://www.ivoa.net/Documents/DALI/index.html Review period: 2013-02-22 to 2013-03-22 In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your WikiName so authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment. Discussion about any of the comments or responses should be conducted on the DAL mailing list (dal@ivoa.net). However, please be sure to enter your initial comments here for full consideration in any future revisions of this document.Implementation detailsLinks and description of existing interoperable implementationsComments from the CommunityPoints by MarkusDemleitner, 2013-03-14
| ||||||||
Added: | ||||||||
> > | ||||||||
Comment by Arnold RotsIn an attempt to be more specific, I suggest replacing the following text in Section 3.1.2: Values never include a time zone indicator and are always interpreted as UTC [17].In cases where values may be expressed using Julian Date (JD) or Modified Julian Date (MJD), these follow the rules for double precision numbers above and may have additional metadata as described in 4.4. by: Values must never include a time zone indicator and shall be interpreted as stated below. In cases where values may be expressed using Julian Date (JD) or Modified Julian Date (MJD), these follow the rules for double precision numbers above and may have additional metadata as described in 4.4. All date-time values (ISO-8601, JD, and MJD) shall be interpreted as referring to time scale UTC and time reference position UNKNOWN, unless either or both of these are explicitly specified to be different [17]. -- ArnoldRots - 2013-03-15 | ||||||||
Added: | ||||||||
> > |
The VAO has reviewed this document and, aside from Arnold's comment above, has no further comments to make. -- MatthewGraham - 2013-03-19 | |||||||
<-- <-- <-- <-- <--
|
DALI-1.0 RFCThis document will act as RFC centre for the Data Access Layer Interface 1.0 specification. The current version of the document is available at: http://www.ivoa.net/Documents/DALI/index.html Review period: 2013-02-22 to 2013-03-22 In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your WikiName so authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment. Discussion about any of the comments or responses should be conducted on the DAL mailing list (dal@ivoa.net). However, please be sure to enter your initial comments here for full consideration in any future revisions of this document.Implementation detailsLinks and description of existing interoperable implementationsComments from the CommunityPoints by MarkusDemleitner, 2013-03-14
| ||||||||
Added: | ||||||||
> > | Comment by Arnold RotsIn an attempt to be more specific, I suggest replacing the following text in Section 3.1.2: Values never include a time zone indicator and are always interpreted as UTC [17].In cases where values may be expressed using Julian Date (JD) or Modified Julian Date (MJD), these follow the rules for double precision numbers above and may have additional metadata as described in 4.4. by: Values must never include a time zone indicator and shall be interpreted as stated below. In cases where values may be expressed using Julian Date (JD) or Modified Julian Date (MJD), these follow the rules for double precision numbers above and may have additional metadata as described in 4.4. All date-time values (ISO-8601, JD, and MJD) shall be interpreted as referring to time scale UTC and time reference position UNKNOWN, unless either or both of these are explicitly specified to be different [17]. -- ArnoldRots - 2013-03-15 | |||||||
<-- <-- <-- <-- <--
|
DALI-1.0 RFCThis document will act as RFC centre for the Data Access Layer Interface 1.0 specification. The current version of the document is available at: http://www.ivoa.net/Documents/DALI/index.html Review period: 2013-02-22 to 2013-03-22 In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your WikiName so authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment. Discussion about any of the comments or responses should be conducted on the DAL mailing list (dal@ivoa.net). However, please be sure to enter your initial comments here for full consideration in any future revisions of this document.Implementation detailsLinks and description of existing interoperable implementationsComments from the Community | ||||||||
Added: | ||||||||
> > |
Points by MarkusDemleitner, 2013-03-14
| |||||||
Added: | ||||||||
> > | ||||||||
<-- <-- <-- <-- <--
|
DALI-1.0 RFCThis document will act as RFC centre for the Data Access Layer Interface 1.0 specification. The current version of the document is available at: http://www.ivoa.net/Documents/DALI/index.html | ||||||||
Changed: | ||||||||
< < | Review period: 2013-02-21 to 2013-03-21. | |||||||
> > | Review period: 2013-02-22 to 2013-03-22 | |||||||
In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your WikiName so authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment.
Discussion about any of the comments or responses should be conducted on the DAL mailing list (dal@ivoa.net). However, please be sure to enter your initial comments here for full consideration in any future revisions of this document.
Implementation detailsLinks and description of existing interoperable implementationsComments from the Community
<-- <-- <-- <-- <--
|
DALI-1.0 RFC | ||||||||
Changed: | ||||||||
< < | This document will act as RFC centre for the DALI-1.0 specification. The current version of the document is TBD. | |||||||
> > | This document will act as RFC centre for the Data Access Layer Interface 1.0 specification. The current version of the document is available at: | |||||||
Changed: | ||||||||
< < | Review period: 2013-02-15 to 2013-03-15. | |||||||
> > | http://www.ivoa.net/Documents/DALI/index.html | |||||||
Added: | ||||||||
> > | Review period: 2013-02-21 to 2013-03-21. | |||||||
In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your WikiName so authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment. | ||||||||
Changed: | ||||||||
< < | Discussion about any of the comments or responses should be conducted on the DAL mailing list (dal@ivoa.net). However, please be sure to enter your initial comments here for full consideration in any future revisions of this document. | |||||||
> > | Discussion about any of the comments or responses should be conducted on the DAL mailing list (dal@ivoa.net). However, please be sure to enter your initial comments here for full consideration in any future revisions of this document. | |||||||
Implementation detailsLinks and description of existing interoperable implementationsComments from the Community
<-- <-- <-- <-- <--
|
DALI-1.0 RFCThis document will act as RFC centre for the DALI-1.0 specification. The current version of the document is TBD. Review period: 2013-02-15 to 2013-03-15. In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your WikiName so authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment. Discussion about any of the comments or responses should be conducted on the DAL mailing list (dal@ivoa.net). However, please be sure to enter your initial comments here for full consideration in any future revisions of this document.Implementation detailsLinks and description of existing interoperable implementationsComments from the Community
<-- <-- <-- <-- <--
|