CIP Clarifications History after ICS Telecon November 17th, 2005

1. Correction in Structure Attribute for Use Attributes 2060, 3116, 3117
2. Clarification of value syntax for Period
3. Correction in Structure Attribute for Use Attribute 3906
4. Inside/Outside of Bounding Polygon
5. Clarification of Element 4006, Authoritative.
6. Clarification of identifying Parent Archive Collection
7. OrderingCentreID in Options Element Set
8. OrderingCentreID syntax to use cip_url_prefix
9. Temporal period structure attribute [LOG 01]
10. Local Attributes
11. Infinite Searches
12. Multi-collections in Search request
13. MD_ENTRY_ID in a Collection descriptor
14. Section 3.5.8.8 CIP Order Extended Service, OriginPartToKeep
15. Order Options Amendment page B-3 Compound 4252
16. CIP Context passing in a HTTP-URL
17. FTPDelivery/ftpAddress
18. Specifying a Collection search
19. SUTRS/HTML Record Syntaxes [LOG 07]
20. Thumbnail Graphic in Present Reponse
21. Temporal scene selection options of an order
22. Rectangle scene selection center specification
23. Order Options Clarification [LOG 08]
24. Collection Path Identification [LOG 09]
25. Search found no matches diagnostic
26. Adding a new element "DataURL" to ProductDescriptor
27. BrowseId and OrderingCentreId should be in all Element Sets
28. CIP/GEO Alignment discussion
29. ArchivingCentreId, DataCentreName, ProcessingCentre, ProjectName valids
30. Track/Frame information independence from other SpatialCoverage attributes
31. Orbit information
32. Multiple OrderingCentreId in CollectionDescriptor
33. AquisitionStatus ENUM values
34. Country ENUM values
35. BrowseFormat ENUM values
36. LocalUseAttributesFlag
37. GroupId
38. ResourceControlResponse direction.
39. Z39.50 ANSI standard number
40. GeospatialForm vs. GeoSpatialForm
41. ENUM attributes without valids lists to be converted to STRING
42. BandMode ENUM type
43. BrowseCompression ENUM type
44. GridCoordinateSystemName
45. ItemDeliveryMethod ENUM type
46. Map Projection Name ENUM type
47. ProductFormat/-Compression ENUM types
48. SpatialKeywordsThesaurus, ThemeKeywordThesaurus ENUM types
49. TemporalKeywordThesaurus ENUM type
50. StorageMedium ENUM type
51. Order Option Amendment AlongGridUnitType ENUM type
52. Order Option Amendment PolygonProjection ENUM type
53. Order Option Amendment TemporalResolution type
54. CollectionHierarchyCategory Valids
55. ItemDescriptorLanguage/ItemLanguage - Spanish
56. MissionId - METEOR
57. ThemeKeyword syntax
58. Order Options Amendment: ProcessingOptionRepeatedValues BOOLEAN
59. Mandatory support for InstrumentSensor as searchable attribute in collection searches
60. Mandatory support for TemporalRange as searchable attribute in collection searches
61. Structure Attribute typos
62. "bib-1 100" date versus "CIP 100" time
63. LocalAttributeId structure attribute
64. GPolygon Use attribute structure
65. TemporalCoverage Use attribute structure
66. TemporalPeriod Use attribute structure (deleted)
67. Use attribute structure assignment
68. BoundingRectangle subelements as use attributes
69. TemporalPeriod semantic conflict
70. Editorial comments
71. References to Protocol Task Team (PTT)
72. References to the ICS Guide Protocol (IGP)
73. Value syntax of AltitudeDatumName
74. Valids of Scale
75. Valids for and value syntax of LocalUseAttributesFlag, ProcessingOptionRepeatedValues
76. Order Item Cancellation
77. Manual Order Monitoring
78. CustomerReference should be optional
79. UserDescriptor
80. CollectionDescriptor
81. Extension of ThumbnailData
___________________________________________________________________

#1. Correction in Structure Attribute for Use Attributes 2060, 3116, 3117

Location: Appendix A

Tables A-3 and Table A-7:
Attribute ID# 2060, Bounding Rectangle: change structure from "bib-1 202" to "CIP 202"

Tables A-5 and Table A-9:
Attribute ID# 3116, GPolygon: change structure from "bib-1 202" to "CIP 202"
Attribute ID# 3117 GPolygonOuterGRing: change structure from "bib-1 202" to "CIP 202"

___________________________________________________________________
#2. Clarification of value syntax for Period

Location: Appendix A

Tables A-4 and A-8:

The Value Syntax for Use Attribute 4069 PeriodDefinition is specified as TIME. The value syntax entries in CIP are defined as in CCSDS DEDSL. The CCSDS Time Code Standard does not deal with recurring time intervals.
But, the structure for 4069 is CIP 210 which is defined using ISO 8601.
ISO 8601 covers time periods. Therefore, the reference to ISO 8601 as the structure for 4069 shall override TIME in the value syntax (interpreted to be the CCSDS time standard).

___________________________________________________________________
#3. Correction in Structure Attribute for Use Attribute 3906

Location: Appendix A

Tables A-5 and A-7

The Structure Attribute for Use Attribute 3906, TemporalRange, is CIP 204. CIP 204 is defined as EXTERNAL in Table A-14, but is not resolved anywhere in the specification, e.g., Appendix E. Therefore, change the structure attribute of 3906 to CIP 210 in Tables A-5 and A-7.

___________________________________________________________________
#4. Inside/Outside of Bounding Polygon

Location: Appendix A, Table A-14.

The definition of Structure Attribute CIP 202 BoundingPolygon does not allow to uniquely derive which of the two possible areas enclosed by the sequence of points is the correct one. The BoundingPolygon structure passes the boundary of an area. When the boundary is on the Earth sphere, the boundary splits the sphere into two surfaces. A rule needs to be stated as to what is in and what is out.

Add the following statement to the Meaning column of CIP 202: "To determine the enclosed region, read the points counterclockwise, then the area to the left of the reading direction is the one in question" .

___________________________________________________________________
#5. Clarification of Element 4006, Authoritative

Location: Appendix B, Table b-1

The meaning of Element 4006 Authoritative is unclear. The intent of Element 4006 was based on the assumption that collection descriptors might be copied from one Retrieval Manager to another. 4006 is to be the item descriptor of the collection which is the original descriptor.
The secondary location uses 4006 to point to the original or "authoritative" source. However, it is not a recommended practice to copy descriptors across sites as you introduce redundant data that may then need to be addressed (eliminated or notated) before presenting to the user. The related item descriptors can be used to construct parent-child relationships. Procedures for creation and maintenance of collection descriptors can be found in the ICS Collections Manual.

___________________________________________________________________
#6. Clarification of identifying Parent Archive Collection.

Location: Appendix B, Table B-1.

In the Collections Data Model, each Product Descriptor shall be a member in one and only one Archive Collection. In order to identify the "Parent Archive Collection" the RelatedCollectionDescriptors shall be used.

Add the following to the definition of RelationDescription, item 4100 in Table B-1: "Use of the phrase 'Parent Archive Collection' in a RelationDescription of a collection item in the ReleatedCollectionDesciptors of a Product Descriptor shall be reserved to indicate the one and only archive collection in which the product descriptor is a member."

Note that the Element 4006, Authoritative, is not to be used to identify
the Parent Archive Collection.

___________________________________________________________________
#7. OrderingCentreID in Options Element Set

Location: tables C-2 and C-3.

To support use of the Options element set for Ordering, the Options element set needs to return the OrderingCentreId from the ProductDescriptor and in ProductCollectionSpecific.

In Table C-2, Product Descriptor, Tag Path (4,4080)/(4,4060), in the Options Element Set Name column: change the 'X' to an 'O'

In Table C-3, ProductCollectionSpecific, Tag Path (4,4078)/(4,4060), in the Options Element Set Name column: change the 'X' to an 'O'.

___________________________________________________________________
#8. OrderingCentreID syntax to use cip_url_prefix.

Location: section E.9

This change defines the OrderingCentreID using the CIP URL Prefix of section E.1. This change allows the use of OrderingCentreID in making a TCP connection by including the port of the host. Also the LOHS_id is changed from 'u_chars_max26' to 'u_chars_max256'.

In Section E.9, change the syntax of ordering_centre_id to the following:

ordering_centre_id = cip_url_prefix + LOHS_id

LOHS_id = u_chars_max256
-- the name of the LOHS at which the order will be executed.

___________________________________________________________________
#9. Temporal period structure attribute. [LOG 01]

CIP-2.4 Table A-14 contains a DateRangeString temporal period structure attribute. This clarification has several items. Each item listed below is in the form of a question followed by a clarifying answer:

* The meaning suggests it is a single date, but I assume it is two dates?
- Yes, it is two dates.

* The format is not clear. Is it of the form "startdate enddate", i.e., two dates separated by a space?
- The format is: CCYY-MM-DD[Thh:mm:ss]Z/CCYY-MM-DD[Thh:mm:ss]Z, i.e., two dates separated by a slash where the first date is the start of the continuous temporal range and the last date is the end of the continuous temporal range. As shown, the time part of the date is optional.

* The date format is ISO/8601. Is this exactly the same format as ISO/CCSDS?
- Yes, for the formats that we use in CIP-2.4, they are the same. (We only use the date format that is compatible with earlier versions of CIP.)

* Are both dates mandatory? It does not seem possible to have an optional start or end date with this format.
- At least one date must be specified.

* Table A-17 does not show permissible combinations for DateRangeString. I assume the only valid combinations are with Before, Before or During, During, During or After, After, Always Matches and Never Matches. Correct?
- The permissible combinations are Before, Before or During, During, During or After, After, Always Matches, Never Matches, Equals, Not Equals, Overlaps, Fully Enclosed Within, Encloses and Fully Outside Of.

* Table A-17 does show TemporalPeriod (with the CIP-2.2 permissible combinations). I assume TemporalPeriod should not be present. Correct?
- Yes, it should be replaced by DateRangeString.

___________________________________________________________________
#10. Local Attributes

Location: Appendix C, Table C-2.

Currently neither ProductCollectionSpecific nor LocalProductUseAttributes are part of the Local Attributes element set.

Change Table C-2 to indicate that ProductCollectionSpecific, LocalProductUseAttributes, Local Attribute and LocalAttributeStructure shall be present in the Local Attributes element.

___________________________________________________________________
#11. Infinite Searches

Location: last-paragraph-but-one in CIP-2.4 Section 3.9.2 ("Collection Searches")

The detection method describe here is to be used for both product and collection searches. The current method is described under Section 3.9.2 ("Collection Searches") and the issue is not mentioned under Section 3.9.3 ("Product Descriptor Searches"). Future version of the Spec should describe the method in its own section.

Since the collection hierarchy is more of a directed graph than a tree, it is possible to create a circular section of the collection hierarchy. If the collection hierarchy is distributed across several Retrieval Managers, a collection or product search targeted at a member of a circular section of the collection hierarchy would be forwarded between the Retrieval Managers indefinitely unless action were taken to prevent it.

To identify if a search has already been targeted at a collection, a Retrieval Manager must know the routing history of the search. The additionalSearchInfo field of the SearchRequest is used to store the routing history in the form of a list of collection descriptor identifiers, one identifier per item of additionalSearchInfo. Before a Retrieval Manager routes a particular search to another Retrieval Manager, it must first check if any of the targeted collections are already present in additionalSearchInfo. (For a collection search, the targeted collections are contained in the SearchRequest query field as collection hierarchy search criteria. For a product search, the targeted collections are contained in the SearchRequest databaseNames field.) If so, the Retrieval Manager must respond immediately with a response containing the appropriate diagnostic indicating that the search is recursive (see Section F.2). If not, before routing the search, the Retrieval Manager must append the collection descriptor identifier of each collection targeted by that search to additionalSearchInfo.

For example, suppose there are three Retrieval Managers: RM1, RM2 and RM3. Suppose RM1 owns collection C1, RM2 owns collection C2 and RM3 owns collection C3. Suppose collection C1 includes collection C2, collection C2 includes collection C3 and C3 includes collection C1. There is a circular section of the collection hierarchy across the three Retrieval Managers between these collections. Now, suppose RM1 receives a product search targeted at C1 from a client (i.e., not another Retrieval Manager). This can be called Step 1:

Step 1: RM1 receives a search targeted at C1, additionalSearchInfo is empty.
Step 2: RM1 determines that it must route a search to RM2 targeted at C2. RM1 checks if C2 is in additionalSearchInfo. It is not, so RM1 appends C2 to additionalSearchInfo and routes a search targeted at C2 to RM2.
Step 3: RM2 receives a search targeted at C2, additionalSearchInfo contains C2.
Step 4: RM2 determines that it must route a search to RM3 targeted at C3. RM2 checks if C3 is in additionalSearchInfo. It is not, so RM2 appends C3 to additionalSearchInfo and routes a search targeted at C3 to RM3.
Step 5: RM3 receives a search targeted at C3, additionalSearchInfo contains C2 and C3.
Step 6: RM3 determines that it must route a search to RM1 targeted at C1. RM3 checks if C1 is in additionalSearchInfo. It is not, so RM3 appends C1 to additionalSearchInfo and routes a search targeted at C3 to RM3.
Step 7: RM1 receives a search targeted at C1, additionalSearchInfo contains C2, C3 and C1.
Step 8: RM1 determines that it must route a search to RM2 targeted at C2. RM1 checks if C2 is in additionalSearchInfo. It is, so, rather than routing the search, RM1 returns a diagnostic search response indicating a recursive search and specifying the collection C2.

___________________________________________________________________
#12. Multi-collections in Search request

Summary George Percivall 29 September 1999
------------------------------------------

*** Statement of the problem:

The CIP Specification is unclear on whether the databaseNames structure in the SearchRequest can contain multiple collections.

ASN.1 for SearchRequest (CIP 2.4, section 3.5.2.6.1, page 3-17) contains a 'SEQUENCE OF DatabaseName' which is directly from the ASN.1
of Z39.50-1995 and so cannot be changed. CIP cannot modify the ASN.1 definition of Z39.50 to restrict it (it can extend it, but it cannot
modify a definition). This is why the SEQUENCE OF had to remain.

But the explanatory text in the specification states that databaseNames shall be a collection in CIP.

*** Summary of Issues from previous e-mails:

Issue 1. Merging of result sets in Search Result and Present

For CIP 2.4 the model of a hierarchical result was developed and included in the spec. The issues included how to count the results for
the SearchResult number of hits, how to allow the PresentRequest to specify a specific record, and how to handle resource reports.
The solution involved using the searchResult- 1 User Information Format (Table 3- 27) which existed in Z39.50, and developing
CIP specific APDUs, (See ChildrenResourceReport, section E.6.1 in CIP 2.4).

This approach was based on the assumption of a single collection in the SearchRequest. Changing this assumption would require re-evaluation
of the existing solution for hierarchical result sets. It may be that this is an area that needs to be discussed in more detail at
an implementers workshop.

Issue 2. Common Query across previously unrelated collections

What would happen when a user included attributes in a query which are valid for some but not all collections identified in a SearchRequest?
This problem is not an issue with the single collection in a SearchRequest, assuming that the ISA does their job in Collection set-up.

Issue 4. Performance: RM-to-RM

The performance Query TN assumed that a RM would "generate a single subquery for each distinct Retrieval Manager, translator, and/or
GEO-server that is a target of the query." If practical experience demonstrates that performance is not affected by having multiple
search requests to the same target this would become a non-issue. That RM/RM performance will not be an issue seems to be the situation
suggested by the previous e-mails.

Issue 5. Performance RM-to-Gateway

Certainly, if you send multiple messages to the gateway, the gateway has no way of optimizing the multiple searches/presents into, say,
a single search/present. But is it true that if you send a single search request with multiple separate collections identified that
the gateway can optimize the search?

*** Summary

Although not decisive, the issues above point to the "single collection in a SearchRequest" as a simpler solution. The changes for
a system to go from a multiple-to-single are less than single-to-multiple. The issue of hierarchical result sets was dealt with in 2.4
and should stand although they need to be discussed further. Performance improvement is an unknown and so not a driver.

Telecon 28 October 1999
-----------------------
Discussion:
- It was agreed that searching of multiple collections is a user requirement, but not directly a protocol requirement. The protocol
requirement is to be able to search a collection structure. A user may ask to search two previously unrelated collections for which
the protocol has no means, in general, to merge the result sets. The client must be able to accept this user request. Merging of
secondary result sets based on collection hierarchy was addressed in CIP 2.4 assuming a single collection in the search request.
- There was agreement that when a local implementation can make use of additional knowledge to optimize a search, that the protocol
not rule this out. The particular example is a search request to a gateway/translator where the Retrieval Manager knows by some
local information, that sending multiple collections in the search request will allow the gateway to perform a single SQL query against
a database.

Potential Resolution:
The CIP specification syntax shall allow multiple collections in a search request, but unless there is prior agreement between the client
and server outside of the specification, a single collection in a search request shall be used. Without such a prior agreement, a server
may reject a search request containing multiple collections, by provding an error with a TBD diagnostic.

Subsequent suggestion (6 Dec 1999)
----------------------------------
Can't we use the "options" field in the Initialise request/response to communicate whether or not multiple collection search is supported?
I don't know what is possible without loosing compliance to Z39.50, but in the CIP-spec I see that bit 9 is reserved for something
(but not used so far?); alternatively, maybe a bit 15 can be added?

Update 15 May 2000:
------------------
Based on referral from ZIG, Percivall contacted Ralph Levan OCLC concerning any history on bit 9 in the Options of InitRequest, InitResponse.
Ralph has no recollection of the history of bit 9. CINTEX should consider proposing use of bit 9 to ZIG.

Telecon 17 May 2000
------------------
There is agreement that bit 9 in the Options of InitRequest, InitResponse is to be used to indicate if multi-collections in a Search Request
are supported by a server. The specific wording of the clarification needs to be developed.

Maurice klein Gebbinck, 14/09/2004
----------------------------------
The CIP spec text for this clarification still needed to be developed. I checked the Z39.50-1995 and Z39.50-2003 specs, and bit 9 of
the Options is still unused. Therefore I propose the changes I made to Table 4:
- in the Options definition, "-- (9) (reserved)" was changed into "multipleDatabaseNames (9),"
- in the Meaning column on the right hand side I added "Extending the Z39.50-1995 specification (which leaves bit 9 unused) a CIP server
sets the multipleDatabaseNames bit if it can handle Search requests containing more than one DatabaseName. Accepting several DatabaseNames
in a single Search request allows a CIP server to optimize the search process by performing a single SQL query against a database."
Furthermore, I added the following text to Table 6:
- databaseNames, column meaning: "Only if the target has set the multipleDatabaseNames bit in the InitializeResponse the origin may send
more than DatabaseName in the same SearchRequest."

Telecon 13/10/2004
------------------
Discussion was postponed on this item, allowing Archie to re-check the z39.50 specs

Telecon 17/11/2004
-------------------
Archie is waiting for an answer on the ZIG mailing list, so discussion on this item is postponed.

Archie, 17/11/2004 after telecon
--------------------------------
Regarding the use of Option bit 9 in the Z39.50 InitResponse to denote
server support for searching multiple databases. I have received some
useful comments from the ZIG mailing list.

First, note that simply saying that the server supports such a
capability doesn't really give a client all the information necessary to
formulate an intelligable query to the server because there may be only
certain combinations of databases which may be queried simultaneously.
The suggested implementation for this would use the Explain facility, in
which the server could tell the client which combinations are permitted.
Alternatively, it could be handled by an outside agreement. In
neither case would the client gain any useful knowledge from examining
the proposed option bit.

Additionally, the Z39.50 standard actually suggests that this capability
is permitted, although not mandatory. Note that there are error message
relating to "too many databases" and "specified combination of databases
not supported". Note that this issue is addressed in 3.2.2.1.2
("Database-names") of the standard, particularly the 1995 and 2003
versions available from the maintenance agency site at the US Library of
Congress (http://www.loc.gov/z3950/agency/document.html).

Finally, Ray Denenberg at LoC suggests that this might actually be
handled through the use of the negotiation facility (see Appendices 14 &
15 of the 2003 version of the standard), although he is unaware of
anyone having implemented it at this point. He has offered to propose
to reserve Option bit 9 for our purpose if desired, however.

I don't think it's necessary, for the reasons stated above. I think the
standard gives us leeway to assume - and document via a clarification -
that servers will support searching multiple databases by default.
Those that don't already have the ability to issue a diagnostic error
message to that effect. Those that do support it require additional
information to allow clients to utilize it anyway - they must define
what combinations of databases are available and what syntax is expected
in order to declare them in the SearchRequest.

I recommend that we avoid an impact on the basic Z39.50 standard and not
use InitResponse Option bit 9 in this way. I further recommend that we
explore ways to provide the additional information necessary to
formulate a sensible query against multiple databases so as to avoid an
unnecessary flurry of diagnostic messages to the (perhaps unsuspecting)
client.

Telecon 15/12/2004
------------------
Archie gives an overview of the answers of the ZIG. Jolyon/Maurice agree that the use of the diagnostic messages mentioned is a better
solution since it stays within the z39.50 standard.

Telecon 19/01/2005
------------------
Maurice reports that the INFEO RM supports multiple collections in the databaseName field and would like to retain this functionality. He suggests that a RM returns bib-1 diagnostic 111 (Too many databases specified) in case it does not support multiple collections in the databaseName field, and bib-1 diagnostic 23 (Specified combination of databases not supported) in case the searching the combination of collections in the databaseName field is not supported. No attempt is made to use the explain database to inform a client which combinations of collections can be put in a single search request; if this is needed client and server should agree on this outside the CIP. Archie agrees, adding that a RM probably either does not support multiple collections in the databaseName field or it supports any combination.

Maurice, after telecon
----------------------
The following changes to the CIP spec are proposed:

- Table 6, Meaning databaseNames: add the phrase "A CIP server may accept multiple DatabaseNames in a single Search request to optimize the search process by performing a single SQL query against a database. If the CIP server does not accept multiple DatabaseNames or the search request contains too many DatabaseNames, bib-1 diagnostic 111 'Too many databases specified' should be returned. If the CIP server cannot handle the specific combination of DatabaseNames, bib-1 diagnostic 23 'Specified combination of databases not supported' should be returned. Establishing agreement between client and server on what combinations of DatabaseNames are supported is outside the CIP."

Telecon 09/02/2005
------------------
No further comments on proposed changes.

Telecon 06/04/2005
------------------
Closed as suggested.

STATUS: closed.

___________________________________________________________________
#13. MD_ENTRY_ID in a Collection descriptor

Background

As part of a discussion in a CEOS Access Subgroup meeting about interoperability between the CEOS IDN and CEOS CIP-based-catalogs, it was identified that the CIP Collection Descriptor may need to reference an IDN dataset. This note provides a standard method to reference IDN datasets from a CIP Collection Desciptor. IDN Datasets are identified by an MD_ENTRY_ID which is part of the DIF schema used in IDN. Listed below is the method for placing an MD_ENTRY_ID in a CIP Collection Descriptor.

Change

Location: CIP 2.4, Table C-2, Page C-11
Add the following as a footnote to RelatedGuidePointer:

'When referencing a CEOS IDN DIF, the MD_ENTRY_ID shall reside in the "URL Pointer" (4,4096)/4,4124) which is part of the compound element "RelatedGuidePointer" (4,4096). The format of the "URLPointer" string will be that defined by the MD_ENTRY_ID. Additionaly in the "RelatedGuidePointer", the "RelationDescription", (4,4096)/4,4100), will be set equal to the string "MD_ENTRY_ID".
For example, an MD_ENTRY_ID equal to "CEOS_SATELLITE_DATA" with an associated URL equal to "http://SomeMoreUsefulData.com" is to be included in a Descriptor in the following fashion: In the RelatedGuidePointer compound, the URLPointer would have a value of "CEOS_SATELLITE_DATA" and the RelationDescription would have a value of "MD_ENTRY_ID". A second occurence of RelatedGuidePointer would be used to handle the URL, where the URLPointer would have a value of "http://SomeMoreUsefulData.com" and the RelationDescription would have a value of "MISC".'

___________________________________________________________________
#14. Section 3.5.8.8 CIP Order Extended Service, OriginPartToKeep

The Explanation for 'orderSpecification' says that it is '...in principle ... unstructured, i.e., it contains a list of item descriptor identifiers and the order options related to them...'.
The subsequent ASN.1 does not make clear how an OHS should interpret 'in principle' or how these item descriptor identifiers and order options have to be submitted. The following statements clarify how 'orderSpecification'.

a. Initially an order specification contains one instance of DeliveryUnitSpec for each user selected ItemDeliveryMethod (from the opt. Element Set).

b. The instances of DeliveryMethod (in a DeliveryUnitSpec) have to be derived from ItemDeliveryMethod and user input eg. "eMail" plus an E-Mail address supplied by the user.
In case of DeliveryMethod being "ftp" an FTPDelivery instance has to be generated. If the transferDirection is "pull" the ftpAddress is "Not provided" or any other InternationalString of similar meaning since ftpAddress is mandatory but the user cannot know from which address (s)he may pull her/his data. The ftpAddress is ignored by the CIP target in this case.

c. The valids list for ItemDeliveryMethod is:
"eMail", "mail", "ftp-push" and "ftp-pull".

d. There is one instance of PackageSpec per DeliveryUnitSpec.
The package is an instance of AdHocPackage since the formatted order options don't support the selection of predefined packages in a semantically clean way (of course an option could code package information but which generic CIP client could interpret that?)

e. The productId in each instance of OrderItem is the same as the ItemDescriptorId of the corresponding ProductDescriptor.

___________________________________________________________________
#15. Order Options Amendment page B-3 Compound 4252

Location: Order Options Amendment page B-3 Compound 4252
Issue: Compound 4252 is named 'HorizontalSceneSelectionDefinition' inside the Compound 4032 definition and 'HorizontalSelectionDefinition' at its own definition location.
Change: Use 'HorizontalSelectionDefinition' in both locations.

___________________________________________________________________
#16. CIP Context passing in a HTTP-URL

Background:
A method is needed to uniformly reference a CIP Descriptor using an HTTP URL. This would allow a user to retrieve a CIP Collection (or product) descriptor from a WWW-to-CIP gateway using an http-url.
This URL could be used to list a CIP collection in GCMD/IDN. The GCMD would return URL's for all collections matching a search (e.g CIP keyword). The DIF would contain the CIP-HTTP URL for the collection.

Add the following Clarification to Section E.
A CIP-HTTP URL shall be defined identically to the CIP URL defined in Section E.1 with one change: In place of the zscheme "z39.50s", the URL shall begin with "http" as is conventional for http URLs. The remainder of the CIP-HTTP URL shall be identical to the CIP-URL with the zscheme.
When presented a CIP-HTTP URL, a compliant http server shall return a web page containing elements of the requested descriptor, i.e., collection descriptor or product descriptor. The format of the web page is not specified by this specification.

___________________________________________________________________
#17. FTPDelivery/ftpAddress

Discussion: The meaning/definition of FTPDelivery in Table 3-36 (page 3-88 in my copy) has not been completed. The meanings of transferDirection and ftpAddress are pretty obvious but the problem is that the format of ftpAddress is not defined.

Clarification: Define the format of ftpAddress as a URL of the form:

ftp://[[:]@][:][/]

where the Order Handling server receiving such a URL should use username=anonymous and password= if not otherwise specified. This format is as defined in this IETF RFC:
http://www.ietf.org/rfc/rfc2396.txt

___________________________________________________________________
#18. Specifying a Collection Search

Issue: I am now confronted with the problem of specifying that the search request I intend to send is a collection search. Although it is very clear in the CIP Specs that it should be specified in the "Other Info"field of the Search request, I still have some doubts on how it should be implemented:

- If I understand things correctly, the Other info object should contain an external object which is a CIP specific Info object : do we know which is the OID of this external?

- A new relation attribute "IncludedIn" has been defined in CIP 2.4. Is it supposedto replace the attribute "Below" as used in Search A and in that case shall we consider that there is an alternate way of specifying a collection search?

- In Z39.50, the other Info may contain several objects (It is a sequence of sequence), is it still true in CIP or should we expect only one per request?

Status: The following text was adopted to close this item

When specifying a collection search, three fields have to be considered:
- The targeted database
- The RPN Query
- The CipSpecificInfo object in the OtherInfo field

For a collection search these 3 fields have to be filled in this manner:
- The targeted database must be "IR-Collection 1"
- The RPN Query may include " CollectionDescriptor.ItemDescriptorId included in collection descriptor id" to specify that the search is conducted through the collections within the specified collection otherwise, the search is conducted through the entire collection DB
- The CipSpecificInfo object in the OtherInfo field must be used and specify that the search is a "collection search" (and also whether the search is local or wide).

For a product search, the following rules apply:
- The targeted database can be "IR-Collection 1" in the case of "IR-Collection 1" being the name of the root collection
- The CipSpecificInfo object in the OtherInfo field must be used and specify that the search is a "product search".
In either the collection or the product search case, there shall be one and only one CipSpecificInfo object in the OtherInfo field of a product or a collection search request.

19. SUTRS/HTML Record Syntaxes [LOG 07]

Issue: CIP mandates the use of the SUTRS record syntax ({Z39-50-recordSyntax 5 101}) for interoperability with Version 2 clients and servers, e.g., GEO. In Section 3.5.3.3.4 it suggests that a SUTRS record is simply a string of textual data, i.e., unstructured text, but in Section 3.5.3.5.4 it suggests that it is possible to have a string ofHTML in a SUTRS record and that this format should always be used when responding to a Version 2 client. However, GEO uses the SUTRS record syntax as a simple string of textual data and the MIME/HTML record syntax ({Z39-50-recordSyntax 5 109 3}) for a string of HTML.

So it seems there is a potential interoperability problem here: CIP does not require support for the MIME/HTML record syntax and supports the use of SUTRS that is incompatible with GEO (or any other profile).

It is possible that GEO has changed since CIP-2.4 was produced. (The unreliable Changes section of GEO 2.2 alludes to this.) So perhaps we need a clarification here? That CIP should use the MIME/HTML record syntax for HTML records, rather than SUTRS?

Status: The following text was adopted to close this item.

SUTRS should only be used to return textually formatted records. The record syntax MIME/HTML ({z39-50-recordSyntax 5 109 3}) should be used to return HTML formatted MIME-type records.

___________________________________________________________________
#20. [27 Jan 2000 - Bernhard Buckl]
Thumbnail Graphic in Present Reponse

*** Summary by G. Landgraf omitting discussion of solutions leading to a dead end

CIP spec change request - add element thumbnailData to the Brief Element Set

...

Draft Solution (Telecon 20/12/00):
The element thumbnailData shall be included as an optional element in the Brief attribute set, in the same way as BrowseId (see #27).

GL comment (17/1/2001)
_______________________
I think we have kept the 'Brief' Element set very short to allow transfer of even big result sets without facing network bottleneck problems.
If some providers include the optional thumbnail this might be put in danger.
I suggest therefore to change the 'Sum.' element set instead. It is identical to the brief, but includes also the Browse. I suggest to not include the Browse, but the thumbnail instead. Like this the user could choose if he wants Thumbnails included in the 'initial list of short results' by selecting either 'Brief' or 'Sum.' element set.

AW comment (24/1/2001)
_______________________
Putting the thumbnails into the B (brief) element set wouldn't be a bad idea if there were some way for the requesting client to know a priori how big the returned record would be. Putting an image in is probably a bad idea, although I don't suppose it would do too much violence to the notion of "brief" to optionally include a link to the thumbnail image.

Still, the original purpose of the S (summary) element set for FGDC was to provide a mechanism for a more intelligent display of results. It's not quite correct to say that the S element set "is identical to the brief, but includes also the Browse" - it also includes spatial and temporal information, but I'd be inclined to leave the interpretation of what a browse graphic is (thumbnail? other small image?) to the choice of the server. So I think putting thumbnails into the S element set is entirely consistent.

A bigger question would be if there is, or needs to be, a way to distinguish between various types of browse graphics - thumbnails, dynamically-generated sub-images, other browse products. If it _is_ necessary or desirable, we could follow the CEOnet precedent of putting that distinguishing information in the BROWSED element, but we then get dangerously close to combining a free-text field with one that really ought to be a controlled vocabulary.
Perhaps at that point, it would be worthwhile to discuss a new element in the Browse Graphic element.

Telecon Discussion (12/1/2000)
______________________________
Bernhard reasoned that it should be the provider who should be responsible to ensure that the network load remains aceptable.
Lou supported the proposal to use the SUM element set, as the brief one should not be overloaded (already the latest decisions on OrderingCenteId and BrowseId were hard to accept and onlt tolerated being faced with the INFEO 'de facto' implementation.
Bernhard confirmed then by email to adopt the view that to add thumbnailData to the Summary ES

Proposed Solution:
__________________
The Thumbnail attribute shall be included instead of the Browse one in the Sum. element set.

Status: CLOSED on 27/01/2000 (the clarification's anniversary) as per proposed solution

___________________________________________________________________
#21. Temporal scene selection options of an order.

Issue: In Table B3 of the Order Options Amendment, the temporal Selection Definition is composed of:
Temporal Resolution (integer corresponding to a valid list specifying the units used)
Temporal Unit Min (Integer)
Temporal Unit Max (Integer)
Temporal Unit Step(Integer)
Now in the formattedSceneSelectionOptions definition in a CIP ordering extended service (Table C-3) a start date and an end date have to be provided as two Time objects where the Time object is a compound of six integers (year, month, day, hour, minutes, and seconds).

And we are supposed to use the first one to fill the second one.

First we object to the use of a new way of specifying a date when there is already a format for that. So we chose to specify Time as a String. Then we do not see why we have to get the options in one format and specify the value in another one. It is confusing for both the server and the client.

We suggest to send the chosen value using the following format:
The chosen value is set between the min and the max integer values provided and according to the step. And we simply send this value along with the resolution number. "resolution=XX/value=XXXX" as a String.

Let the server deal with its strange format if you follow me

Status: The following analysis (by Guenther Landgraf) was adopted and closes this issue.

Basically these temporal scene selection allows to cut out a segment of a full acquisition by indicating the start and end time.
It is necessary that the OrderOptions definition is relative to the acquisition, which is providing the absolute possible start and end.
Obviously it would be possible that the finally selected scene is also indicated in relative terms, but this is not advisable, as the relative expression is somehow 'cryptic', while the absolute start and end are really clear.

The Time format is the one generally used in the CIP spec, so there should not be any problem.

In conclusion: the specification should stay as is, also because there is no real problem highlighted and we should have discussed about preferences during the spec review.

___________________________________________________________________
#22. Rectangle scene selection center specification.

Issue: The specification of the rectangleSceneSelection in the formattedSceneSelectionOptions definition in a CIP ordering extended service (Table C-3) includes the two following fields
AcrossCenter and AlongCenter both are integers which have to be specified in grid units (along and across) This works fine when the along size and the across size are both even numbers otherwise AcrossCenter and AlongCenter can no longer be integers. For example, if the user selects a to left region of 5 squares by 3 squares, the centre will be ( 2.5; 1.5)
As a solution we suggest to round off the value to the integer value immediately below. In our example that would give (2; 1). The server is aware of the adjustments it has to do because odd numbers it gets as sizes.
And that should do it

Status: The following analysis and text (from Guenther Landgraf) was adopted andcloses this issue.

I disagree to put this load on the server.
The change is not necessary, as in this case the 'Grid' should be defined as 10x6 with a minimum scene size of 2.

However, the comment is very valuable, and I suggest to add a comment to the order options amendment, stating that the Grid units have always to be even.

___________________________________________________________________

#23. [16 Mar 2000 - Simon Marshall]
Order Options Clarification [LOG 08]

Conclusion:

* A product may have a ProductServiceOptions and therefore many ProductOrderOptions.
* Each ProductOrderOptions may have many OrderOptionsGroup.
* Each OrderOptionsGroup may have many ProductProcessingOption, SceneSelectionOption and ProductDeliveryOption.

* As in the selected ProductProcessingOptions formatted and unformatted ones cannot be mixed, they can also not be mixed within a single OrderOptionsGroup
* In case of FormattedProcessingOptions, each option represents an independent processing option with its own list of selectable values
* In case of UnformattedProductProcessingOptions, each option represents a selectable value
* Each ProductDeliveryOption has a ItemDeliveryMethod, a ProductMedium and ProductFormat.

The intention is:

* To have user options restricted to specific user groups, i.e., options for one user cannot be chosen with options for another user.
* To have option groups that are indivisible and self-consistent, i.e., options from one group cannot be chosen with options from a different group.
* To have options that are indivisible, self-consistent and can be collated, i.e., options of the same type can be chosen (e.g., two product processing options for channel and correction).
* UnformattedProccessingOptions can be used to represent simple cases, where the all types of processing can be listed (as different UnformattedProccessingOptions) in a single list.
The user is expected to select exactly one value
* For FormattedProcessingOptions there may exist different options (identified by the ProcessingOptionName). The user has to select exactly the number of values indicated by 'ProcessingOptionNumberOfValues' for each option
* A user can select zero or more product processing options.
* If there are scene selection options, the user has to select exactly one
* A user has to select exactly one product delivery option, with
- the ItemDeliveryMethod to be inserted as 'deliveryMethod' into the DeliveryUnitSpec
- the ProductMedium to be inserted as 'packageMedium' into the PackageSpec
- the ProductFormat to be inserted into the orderItem/productDeliveryOptions

"Indivisibility" implies that options cannot be selected from more than one group at any option group level. That is, options from two different ProductOrderOptions cannot be chosen for a single product any more than options from two different ProductProcessingOption.

To use an example, suppose a product has an OrderOptionsGroup which contains:

* A product option OrderOptionsGroup1
* A product option OrderOptionsGroup2
* OrderOptionsGroup1 contains SceneSelectionOption1,
UnformattedProductProcessingOption1.1, UnformattedProductProcessingOption1.2,
ProductDeliveryOption1.1, ProductDeliveryOption1.2.
* OrderOptionsGroup2 contains SceneSelectionOption2,
UnformattedProductProcessingOption2.1, UnformattedProductProcessingOption2.2,
ProductDeliveryOption2.1, ProductDeliveryOption2.2.

A user can select items from OrderOptionsGroup1 or OrderOptionsGroup2.
For example, a user can select
- UnformattedProductProcessingOption1.1 or UnformattedProductProcessingOption1.2
together with
- ProductDeliveryOption1.1 or ProductDeliveryOption1.2.

Similarly, a user can select
- UnformattedProductProcessingOption2.1 or UnformattedProductProcessingOption2.2
together with
- ProductDeliveryOption2.1 or ProductDeliveryOption2.2.

But a user cannot select items from both OrderOptionsGroup1 and OrderOptionsGroup2. For example, a user cannot select UnformattedProductProcessingOption1.1 and ProductDeliveryOption2.1 because they are items from different options groups.

The reason we are raising this clarification is the client interface example in Section 2.1 of the Order Options Amendment.
It seems to show that the Medium and Format can be chosen independently from each other.
However, the ProductMedium and ProductFormat are part of a ProductDeliveryOption and therefore, are indivisible and not independent of each other. The example has to be interpreted such, that there were the following delivery options (Medium/Format):
- Floppy/JPEG
- Floppy/GIF
- photo/11x11 cm
- photo/ .....

So the interface is achieved by a pre-analysis, grouping the delivery options by medium and displays for each medium the list of found formats.

Status: CLOSED on 20/12/2000

___________________________________________________________________

#24. [24 Mar 2000 - Simon Marshall]
Collection Path Identification [LOG 09]

The retrieval_manager_path part of a collection path is defined as "/" + host + local_path, i.e., it does not contain the port of the host. I think it should, because otherwise (in general) there is no way to identify the true collection descriptor for any collection in the collection path, e.g., for the purposes of extracting (from the appropriate databaseInfo records) the collection names for the collections in the path. So, following the way cip_url_prefix is defined, I propose that the format should be:

retrieval_manager_path = "/" + host [+ ":" + port] + local_path

where the port must be specified if it is not the default CIP port.

Status: CLOSED on 24/01/2000 as per Simon's proposal

___________________________________________________________________
#25. Search found no matches diagnostic [LOG 10]

Issue: "CIP-2.4 has introduced two diagnostics for collection and product searches that find no matching records. I don't understand what this is supposed to be used for given the existing mechanisms.
What is the difference between returning (say) a search response indicating zero hits and including no records, and a search response indicating zero hits and including a product-search-found-no-matches diagnostic record?
What is the difference between returning (say) a present response with the more general present-request-out-of-range diagnostic, and a present response with the product-search-found-no-matches diagnostic?"

Percivall response: The additional diagnostics are needed for the solution to distributed searching. In order to provide detail on the secondary searches and the distributed results set, the records were defined. See section 3.9.7. in CIP 2.4

Simons First Response: Table 3-54 case 1 scenario that there are 0 or more matches to the search: it states that no diagnostics should be returned.

Table 3-54 case 2 scenario that there are 0 or more matches to the search for A and the search cannot be processed for B: it states that 1 diagnostic is returned for B but no diagnostic is returned for A (even if it matches 0 results).

Similarly for Table 3-55 and presenting. The tables seem to be stating that no diagnostic is used when there are no matches to the original search (which could be processed).

As for your point that the search-found-no-matches diagnostics are there to providedetail in the case of secondary distributed searches: I could understand that if the diagnostics' addInfo included the collection id(s) for the collection(s) that matched no records. But if they were used as you suggest, following a search of several collections one of which matched no records, they would lead to theuser question: "OK, but *which* collection had no hits?" (I suppose the clientcould then use the SearchInfoReport to get details of named collection-by-collection match counts and result sets. ;-)

Simons Second Response: I'm guessing that they are there so that a search response can indicate those collections that did not match any hits.

* First, the diagnostic (according to CIP-2.4 Appendix F) does not require the diagnostic to contain the collection id, so the diagnostic does not indicate forwhich collection it is applicable.

* Second, Tables 3-54 and 3-55 (Section 3.9.7) suggest that the diagnostic should not be sent in the case of zero matches to a search anyway (see below for a more detailed explanation). Section 3.9.7 does not otherwise suggest that the diagnosticshould be used.

* Third, the existing SearchInfoReport can already be included in a search responseto provide collection-by-collection search result information, such as the match count.

So, assuming my understanding of the purpose of the diagnostics' job is correct, my pointis that: the diagnostic (as defined in CIP-2.4) does not seem to do the job adequately;the spec doesn't suggest it should be used for this purpose either; there is another mechanism (defined in CIP-2.4) that does the job already.

Status: The following text was suggested to close this item

The newly introduced diagnostic conditions 610 (Collection search found no matches)are redundant. The existing SearchInfoReport can already be used to provide status on search operations including match count.

___________________________________________________________________

#26. [28 Jul 2000 - Lakshmi Kumar]
Adding a new element "DataURL" to ProductDescriptor

Adding a new element "OnLineLinkage" to Product Descriptor
This item was reviewed and a draft table showing the new element in the product descriptor (as it would appear in CIP 2.4 Specification Tables B-1 and C-2) was distributed. There was no dissent on the addition of this optional element.

In the telecon on 15/11 the following changes were agreed
- OnLineLinkage will not be used as Use attribute
- In the Brief result set OnLineLinkage will be treated the same way as BrowseId and OrderingCentreId

Status: CLOSED on 20/12/2000 as per #26_OnlineLinkage.doc (attached to email of 23/11/2000
___________________________________________________________________

#27 [22 Sep 2000 - Simon Marshall]
BrowseId and OrderingCentreId should be in all Element Sets

There was general agreement (Lou and Guenther) that the CIP 2.4 Specification should not be modified at this point to include these elements (if there are to be considered mandatory).
However the last e-mail from Simon suggests that this title should in fact read "BrowseID and OrderingCenterID can be in all element sets" and this was in fact what INFEO were doing - these elements are included in the Brief element set as optional elements.

Status: CLOSED on 20/12/2000 as per #26_OnlineLinkage.doc (attached to email of 23/11/2000

___________________________________________________________________
#28. [18 Jul 2000 - Doug Nebert and Archie Warnock]
CIP/GEO Alignment discussion

A. We need to clarify the term order for specifying the 4 bounding coordinates. It sounds like GEO and CIP may be doing slightly different things. GEO specifies a term ordering in such cases to be N,W S,E for use attribute 2060, and was N S E W for the (obsolete) use attribute 3111.

CIP features attribute 2060 with term ordering W,E,N,S, which corresponds to the GILS definition (see www.gils.net).

Archie commented the reasoning for the FGDC order is given by expressing the coordinates as if two opposite corners (NW and SE) had been selected. Also there had been some discussions with GILS to align this way.

Final Analysis:
- GILS does not mandate WENS, but alway uses this order in the spec.
- GEO spec used for CIP/GE alignment is contradictory: specifies WENS, bu provides examples in order NWSE
- CIP/GEO aligment defines WENS
- OGC defines WENS

Conclusion on 20/12: No change to CIP seems justifiable. The problem has to be handled in the CIP/GEO and GEO/CIP gateways

AW comment (24/1/2001)
_______________________
This seems fine to me. Note that there will be some implementation impact, but I think it's justified. Making this work relies on recognizing the attribute set ID. From my direct experience, many implementation do not do this and more specifically, many clients do not allow the user to even select attribute set IDs. To guard against this, in the FGDC we have implemented a "generous" server which attempts to resolve search requests which include the BIB-1 attribute set ID with a use attribute that appears to come from GILS or GEO. This difference between CIP and GEO will require more attention to the attribute set ID. This is not necessarily A Bad Thing - just a cautionary note for implementors.

LR comment (24/1/2001)
_______________________
OGC will probably redefine NWSE in accordance with GML. This should probably not influence the decision.

Status: CLOSED on 24/01/2000 without change to the CIP spec.

Additonal Observation from 23/05/2001 telecon:
CIP spec. (Tabl A-14) states that "a bounding polygon with only 2 (coordinate) pairs entered shall represent a bounding rectangle where the NW and the SE corners of a described area are provided". At least this is in line with Archies reasoning.
___________________________________________________________________

#29. [13 Dec 2000 - Guenther Landgraf]
ArchivingCentreId, DataCentreName, ProcessingCentre, ProjectName valids

I have gone through these lists and basically feel that they are unmaintainable at a global level, in particular assuming a growth of the remote sensing sector. I also wonder if it is really worthwhile to do such an effort. The pro's and con's, in particular considering that the first 3 attributes should become 'transparent' for the end-user (who should rather see either an 'OrderingCentreId' or an ftp address for data download, should be discussed.

Jingli Yang commented on 14 Dec.:
I agree with Guenther. We use only Data Center_ID in V0 valids and we do not have Archiving Center, nor Processing Center attributes because it is true that users do not care about where the data sets are archived or processed. We do have an attribute called Campaign(or project), but I do not think many users use it for data search.

Cintex discussion on 23/05/2001:
- Jingli asked about the seareability of the attributes and all of them will remain searchable.
- Jingli mentioned that some people want to restrict the search by DataCentreName and the possibility to define a pick-up list
- Guenther stated that pick-up lists would be typically supported by the explain database
- Yonsook explained that in CIP philosophy such a restriction would have to be achieved by targeting the product search at a specific subset of collections (corresponding to this DataCentreId)
- Jolyon explained that to identify these collections the user would typically first do a collection search (e.g. limiting to a specific DataCentreName) to obtain this subset
- it was clarified that also without a set of specified valids DataCentreNames would be passed between CIP and IMS and fully supported without limitations

There seems to be consensus that no global valid lists can be supported for the 4 attributes in discussion.

Jingli has taken an action to check the INFEO site and send any objections by mail.

Proposed closure: Valid Source flag to be changed to 'X' in CIP 2.4 appendices A and B for attributes ArchivingCentreId, DataCentreName, ProcessingCentre, ProjectName

Status: closed on 01/08/2001 as defined in 'Proposed Closure'
___________________________________________________________________
#30. [11 Jan 2001 - Guenther Landgraf]
Track/Frame information independence from other SpatialCoverage attributes

With the Current Definition of SpatialCoverage, e.g. a WRSGRSScene cannot be given if the GPolygon is returned (the '|' is an exclusive or).

Instead it would be useful that WRSGRSScene and WRSGRSPass can be given in addition to the GPolygon.
I see two possible solutions that are both backwards compliant:

1) Make the SpatialCoverage attribute multiple (0..n)
This way in the first instance the SpatialCoverage can be supplied geographically (e.g. BoundingRectangle or GPolygon),
in the secand instance WRS Scene (Track/Frame) or PassInformation can be supplied

2) Redefine SpatialCoverage as
[ BoundingRectangle |
GPolygon |
1 { Circle } n |
1 { Point } n ] +
[ WRSGRSScene |
WRSGRSPass ]

This basically allows to optionally add the WRS Scene or PassInformation

Archie Warnock, email 12/11/01:
-------------------------------
I believe that option #2, to redefine the SpatialCoverage, is the preferred approach. It is possible that some clients might encounter
the Scene or Pass information and not understand how to process it, but I wouldn't expect a robust client to fail in such a case.
Option #1 leaves open the question of associating the two (or more) SpatialCoverage attributes in a way that makes clear that they are
related. Placing them within SpatialCoverage as optional element makes the association clear.

Guenther Landgraf, 12/11/01:
----------------------------
I also prefer solution #2 if we want to make the extension as minimal as possible.
Solution #1 was added as it would also give the possibility to express the SpatialCoverage with different accuracies that might be useful
in different situations or for different clients, e.g. in extreme cases:
- as approximate Bounding rectangle
- as 4 corner coordinates
- as GPolygon with lots of intermediate points for very precise display.

Telecon, 16/11/01:
----------------------------
It was shortly discussed if it was worthwhile to further exploit the oppurtunities of solution #1, defining the semantic as the varios
instances of SpatialCoverage being different representations of the same product coverage. Final decision was made to not proceed in
this direction as the solution represents a larger implementation risk for CIP clients.

Telecon, 16/01/02:
----------------------------
closed as per proposed option #2:
Redefine SpatialCoverage as
[ BoundingRectangle |
GPolygon |
1 { Circle } n |
1 { Point } n ] +
[ WRSGRSScene |
WRSGRSPass ]

Maurice klein Gebbinck, 13/12/2004:
-----------------------------------
Clarificaton #30 changes the Abstract Record Structure of SpatialCoverage such that it is possible to specify Track/Frame information
in addition to another SpatialCoverage subelement. However, with the current definition it has become obligatory to specify, in addition
to one of the "basic" SpatialCoverage elements BoundingRectangle, GPolygon, Circle or Point, also one of the elements WRSGRSScene or
WRSGRSPass. This was probably not the intention of clarification #30. Since modification of the solution (#2) chosen by clarification #30
seems to become a bit ugly, I would like to suggest to reconsider the other solution (#1) instead.

Telecon 15/12/2004
------------------
Archie agrees that the current definition of SpatialCoverage makes it mandatory for a provider to return either WRSGRSScene or WRSGRSPass,
and that this was not intended. A problem with solution #1 may be however that it also allows a provider to return e.g. two disjoint
bounding rectangles, which might confuse the client.

After telecon 15/12/2004
------------------------
Jolyon notes that CollectionDescriptor/ProductCollectionSpecific already allows multiple occurrences of the SpatialCoverage element.

Telecon 19/01/2005
------------------
Archie agrees that a client that supports multiple occurrences of SpatialCoverage in the CollectionDescriptor is very likely to support it also in the ProductDescriptor, and that therefore the original solution #1 is acceptable.

Maurice, after telecon
----------------------
The following changes to the CIP spec are proposed:

- Table 79: revert to the original definition of SpatialCoverage, i.e.
[ BoundingRectangle |
GPolygon |
1 { Circle } n |
1 { Point } n |
WRSGRSScene |
WRSGRSPass ]

- Table 78: make SpatialCoverage repeatable in ProductDescriptor:
1 { SpatialCoverage } n

- Table 78: add an endnote to ProductDescriptor/SpatialCoverage stating that:
"The various instances of SpatialCoverage in the ProductDescriptor are different representations of the same product coverage."

Telecon 09/02/2005
------------------
No further comments on proposed changes.

Telecon 06/04/2005
------------------
Closed as suggested.

STATUS: closed.
___________________________________________________________________
#31. [17 Jan 2001 - Guenther Landgraf]
Orbit information

I wonder why we have not included OrbitNumber as a standard GIP
attribute.

I suggest to include it with Tag Value 4131 and insert it as an optional element in the ProductDescriptor.Acquisition compound after 'AcquisitionStatus'

Archie Warnock, email 12/11/01:
-------------------------------
This seems to me to be the correct place to include the OrbitNumber, and the tag value is the next available one.

Telecon 16/01/02
----------------
closed on as per suggestion:
OrbitNumber attribute is added with Tag Value 4131 and inserted as an optional element in the ProductDescriptor.Acquisition compound
after 'AcquisitionStatus'

Maurice klein Gebbinck, 14/09/2004
----------------------------------
In Table 76 the SUTRS tag has been set to "orbitnum" with meaning "The number of the satellite's orbit."

Telecon 17/11/2004
------------------
Closed with additional change suggested 14/09/2004.

STATUS: closed.
___________________________________________________________________
#32. [17 Jan 2001 - Guenther Landgraf]
Multiple OrderingCentreId in CollectionDescriptor

I see that multiple OrderingCentres are allowed for the ProductDescriptors, so the same should apply for the OrderingCentre in the CollectionDescriptor

Cintex discussion on 23/05/2001: no objection

Proposed closure: In CIP 2.4 spec, App.C, ProductCollectionSpecific: multiplicity of OrderingCentreId changed to 0..n

Status: closed on 01/08/01 as defined in 'Proposed Closure'

___________________________________________________________________
#33. [18 Jan 2001 - Guenther Landgraf]
AquisitionStatus ENUM values

I suggest to define allowed values as:
- visible/potential (can be acquired, but is not planned)
- planned
- presumably acquired (is in the past, but acquisition has not yet been confirmed)
- acquired
- archived (the relevant level 0 acquisition has been stored in the archive, so the product canbe produced)
- produced (the relevant level of this item has been produced and is readily available)

23/05/2001: action Yonsook to involve relevant NASA people

Archie Warnock, email 12/11/01:
-------------------------------
These seem fine. Are there additional values that would be useful? My preference would be to keep the granularity coarse so that it is is easier to make the relevant determination.

16/11/01: action all: review suggested values
16/01/02: no further values were suggested

Status: closed as per suggestion on 6 March 2002

___________________________________________________________________
#34. [18 Jan 2001 - Guenther Landgraf]
Country ENUM values

I suggest to use the ISO-3166 ASCII 2-char country code

Cintex discussion on 23/05/2001: no objection

Proposed closure: In CIP 2.4 spec, App.B, Country: change Meaning to
"The country of the address as ISO-3166 ASCII 2-char country code"

Status: closed on 01/08/01 as defined in 'Proposed Closure'
___________________________________________________________________
#35. [18 Jan 2001 - Guenther Landgraf]
BrowseFormat ENUM values

I suggest to standardize to the following values for the time being:
- JPEG
- GIF
- HDF
- TIFF
- GEOTIFF

I think that this attribute should be included into the 'Valids'

Cintex discussion on 23/05/2001:
- Ananth remembers that the values are defined somewhere (e.g. as a footnote)

Status: Action Ananth, Guenther to check
Action Ananth, Guenther to check CIP spec: done email Ananth 25/05/2001:
I have taken a look at the CIP spec, and there is no mention of Browse Format Identifiers. The URD(defunct?) makes mention of three supported browse formats i.e JPEG, GIF and HDF-EOS. This is probably out of date.
I think Guenther's proposal looks fine, with the exception that HDF be changed to HDF-EOS (since the two are different, HDF-EOS having added some extensions and thus being a super set of HDF).

Ben mailed on 11 Jun 2001:
NASDA/RESTEC would like to follow up this proposal with an addition. We suggest that PNG format be added to the list, since this format is progressively replacing GIF.

Telecon 01/08/01: It was agreed to maintain both HDF as well as HDF-EOS as seprate valids

Proposed closure:
Valid Source flag to be changed to 'O' in CIP 2.4 appendix B for BrowseFormat.
Valids to be defined inthe valids document version as:
- JPEG
- GIF
- PNG
- HDF
- HDF-EOS
- TIFF
- GEOTIFF

Status: closed on 12/09/01 as per proposed closure
___________________________________________________________________
#36. [1 Oct 2001 - Guenther Landgraf]
LocalUseAttributesFlag

LocalUseAttributesFlag Valid Source flag to be changed to 'X' in CIP 2.4 appendix B
(The CIP spec already defines the allowed values exhaustively)

This was basically already agreed in CINTEX telecon 01/08/01 during the Valids discussion.

Status: closed as per proposal, 16/11/01

___________________________________________________________________
#37. [1 Oct 2001 - Guenther Landgraf]
GroupId

GroupId Valid Source flag to be changed to 'X' in CIP 2.4 appendix B and 'anonymous' to be defined as special value

This was basically already agreed in CINTEX telecon 01/08/01 during the Valids discussion.

Telecon 16/11/01
----------------
closed as per proposal

Maurice klein Gebbinck, 14/09/2004
----------------------------------
The Value Syntax has been changed from ENUM to STRING since apart from the special value "anonymous" no valids exist.

Telecon 17/11/2004
------------------
Closed with additional change suggested 14/09/2004.

STATUS: closed.
___________________________________________________________________
#38. [02 Jan 2003 - Maurice klein Gebbinck]
ResourceControlResponse direction.

I noticed the following error in the CIP 2.4 spec:

On page 3-50, table 3-22, first sentence of the column Meaning: the words "target" and "origin" have been swapped.

The sentence should read "The ResourceControlResponse is provided by the origin in response to a ResourceControlRequest from the target."

Status: closed as per suggestion in telecon of 14 Jan 2003
___________________________________________________________________
#39. [02 Jan 2003 - Maurice klein Gebbinck]
Z39.50 ANSI standard number

On page 3-106, table 3-45, column Meaning: the CIP tagSet should be "ANSI-standard-Z39.50 14 1000 99 1" instead of "ANSI-standard-Z39.50 14 2000 99 1".

SStatus: closed as per suggestion in telecon of 14 Jan 2003
___________________________________________________________________
#40. [02 Jan 2003 - Maurice klein Gebbinck]
GeospatialForm vs. GeoSpatialForm

CIP 2.4 spec uses GeospatialForm while Valids 1.0 document uses GeoSpatialForm.

The Valids document shall be updated to use 'GeospatialForm'

Status: closed as per suggestion in telecon of 14 Jan 2003
___________________________________________________________________
#41. [02 Jan 2003 - Maurice klein Gebbinck]
ENUM attributes without valids lists to be converted to STRING

Elements that have no valids lists associated with them should not be of type ENUM, but of type STRING, INTEGER, REAL, etc.

In detail the type of the following attributes should be updated to STRING:
- AcquisitionStation
- ArchivingCentreId (as discussed in clarification #29)
- DataCentreName (as discussed in clarification #29)
- ProcessingCentre (as discussed in clarification #29)
- ProjectName (as discussed in clarification #29)
- SensorMode

Status: closed as per suggestion in telecon of 14 Jan 2003
___________________________________________________________________
#42. [02 Jan 2003 - Maurice klein Gebbinck]
BandMode ENUM type

CIP 2.4 spec says "Set of flags describing the status of activity for each band (active or not active)".
It is not fully clear how this is to be converted into an ENUM type

Guenther Landgraf, 02 Jan 2003:
-------------------------------

BandMode element path is

ProductDescriptor.
DataOriginator.
0 {Platform} n.
0 {InstrumentSensor} n.
0 {Band} n.
BandId + BandMode

I think only one flag is needed for each Band and suggest to revise the above "Meaning" information in CIP 2.4, Appendix B to "flag describing the status of activity for the band ("active" or "not active")"

Jolyon Martin, telecon 14 Jan 2003:
----------------------------------
Alternatively only the active bands should be included, making the BandMode information obsolete (i.e. Band could take the definition of BandId and BandId and BandMode could be eliminated from the spec.)

ACTION(all) to comment Jolyon's proposal

Maurice klein Gebbinck, 21 Jan 2003:
------------------------------------
It may be confusing to omit BandMode. Suppose that one of the bands of Landsat TM becomes defective. Users know that Landsat TM has 7 bands but get the status of only 6 bands; they may think that there is something wrong with the catalogue? Furthermore, Jolyon's suggestion is only possible when the number of valids for BandMode remains 2; if it ever becomes >=3 (e.g. not active, active, partially defective) then we are in trouble.

telecon, 19 Feb 2003:
---------------------
Maurice's comment was found valid, solution suggested 02 Jan 2003 should be endorsed

Status: closed in telecon 19 March 2003 with the following update to the CIP spec:
Change BandMode "Meaning" information in CIP 2.4, Appendix B to "flag describing the status of activity for the band ("active" or "not active")"
___________________________________________________________________
#43. [02 Jan 2003 - Maurice klein Gebbinck]
BrowseCompression ENUM type

Elements that have no valids lists associated with them should not be of type ENUM, but of type STRING, INTEGER, REAL, etc.

Guenther Landgraf, 02 Jan 2003:
-------------------------------

From its characteristics "BrowseCompression would be of type "ENUM".

I suggest to
- add it to the Valids doc with the following initial list of possible values:
- zip
- gz
- change the 'Valids Source' flag to 'O'

Ananth Rao, telecon 14 Jan 2003:
----------------------------------
also "bz2" shall be added to the initial list

Archie Warnock, telecon 14 Jan 2003:
------------------------------------
the list should be harmonized with the MIME types

G.Landgraf, in preparation for telecon 18 Feb:
-----------------------------------------------
The following MIME type subset is proposed:

zip (ZIP compressed data)
gz (GNU Zip Compressed Data)
bz2 (bzip2 Compressed Data)
Z (Compressed data)
tar (UNIX tape archive)
gtar (GNU tape archive)
tar.gz (GNU Zip Compressed UNIX tape archive)
tar.bz2 (bzip2 Compressed UNIX tape archive)
tar.Z (Compressed UNIX tape archive)

Archie Warnock, for telecon 19 Jan 2003:
------------------------------------
Suggest using proper MIME terminology (see http://www.ltsw.se/knbase/internet/application.htp)
application/zip
application/x-gtar
application/x-gzip
application/x-tar
Others...

Guenther Landgraf, for telecon 19 Mar 2003:
------------------------------------------
Found more updated list on http://www.asahi-net.or.jp/en/guide/cgi/mimetype.html and
http://www.spinnaker.de/mutt/mime.types and
http://www.procmail.org/SmartList-3.15/SmartList/examples/mimencap.local

I have preferred to leave the redundant 'application' away. This would result in

zip (ZIP compressed data)
x-gzip (GNU Zip Compressed Data)
x-tar (UNIX tape archive)
x-gtar (GNU tape archive)
x-bzip2 (bzip2 Compressed Data)
x-compress (Z Compressed data)
x-tar-gz (GNU Zip Compressed UNIX tape archive)
x-tar-compress (Compressed UNIX tape archive)

Archie Warnock, telecon 19 March 2003:
------------------------------------
ommitting the implicit 'application/' is ok

Status: closed in telecon 18 June 2003 with the following updates:
- to the CIP spec: change the 'Valids Source' flag for BrowseCompression to 'O'
- to the Valids Document: add BrowseCompression with the following initial list of possible values:
zip (ZIP compressed data)
x-gzip (GNU Zip Compressed Data)
x-tar (UNIX tape archive)
x-gtar (GNU tape archive)
x-bzip2 (bzip2 Compressed Data)
x-compress (Z Compressed data)
x-tar-gz (GNU Zip Compressed UNIX tape archive)
x-tar-compress (Compressed UNIX tape archive)
___________________________________________________________________
#44. [02 Jan 2003 - Maurice klein Gebbinck]
GridCoordinateSystemName

Elements that have no valids lists associated with them should not be of type ENUM, but of type STRING, INTEGER, REAL, etc.
CIP 2.4 spec mentions explicitly that a controlled list is supported.

Guenther Landgraf, 02 Jan 2003, some additional info:
-----------------------------------------------------
The element appears in an optional compund Product Descriptor attribute "SpatialReference" (The description of the reference frame for coordinates for the item descriptor) which supports the interpretations of the SpatialCoverage attribute, which contains coordinates and/or WRS/GRS frame numbers.

The compound structure path is decomposed as follows:

SpatialReference.
HorizontalCoordinateSystem.
PlanarSystem. (alternative to "GeographicSystem", which describes only Latitude and Longitude Resolution)
GridCoordinateSystem (alternative to "Map Projection"; described as "a plane rectanglular coordinate system usually based on, and mathematically adjusted to, a map projection so that geographic positions can be readily transformed to and from plane coorinates)

To make it shorter, I assume that it is simply the WRS/GRS track/frame system description, but is is unclear to me how it would be described with a "Parameter=Value" syntax as stated in CIP 2.4 for the related element "GridCoordinateSystemDescription"

telecon 19 March 2003:
----------------------
It is proposed to change the type of GridCoordinateSystemName to STRING

Status: closed in telecon 18 June 2003 with the following updates to CIP 2.4 spec:
change the type of GridCoordinateSystemName to STRING
___________________________________________________________________
#45. [02 Jan 2003 - Maurice klein Gebbinck]
ItemDeliveryMethod ENUM type

Flag in Valids Source column should be removed using a Clarification?

Guenther Landgraf, 02 Jan 2003:
-------------------------------

CIP Clarification #14, point c) defined the following
The valids list for ItemDeliveryMethod is:
"eMail", "mail", "ftp-push" and "ftp-pull".

I suggest to insert this into the Valids document

Status: ACTION (all): provide updates to the list to agree closure readiness at next telecon

G.Landgraf, in preparation for telecon 18 Feb:
-----------------------------------------------
propose to add "dvb"

Ananth Rao, telecon 19 Jan 2003:
--------------------------------
other methods supprted by ECS are secure ftp and secure copy

Maurice klein Gebbinck, telecon 19 Jan 2003:
--------------------------------------------
It might be useful to distinguish active and passibve FTP

Action Ananth/Maurice: assess need for additional Valids and if yes send an email with the precise valid string to be used

Ananth Rao, email 27 Feb 2003:
--------------------------------
I checked with the ECS system and it looks like encryption is done outside the protocol level. In other words, protocol traffic is tunnelled through SSL and/or SSH. With this in mind, I have to agree with Guenther's suggestion that we leave the valids as-is (at a high level) and not try and put in too much implementation specific information into it - also given that if we try something like secure-ftp-push/pull, it would be meaningless unless we also specify the underlying security provider information (protocol, version etc.).
My suggestion is to leave the ItemDeliveryMethod valid as already specified for CIP clarifiaction #14.

Maurice klein Gebbinck, email 27 Feb 2003:
--------------------------------------------
I think the criterium should be whether or not the customer needs a special client program to get the software. The situation I mentioned during the telecon - active or passive ftp - is a problem that can be solved *within* the client software, one just has to set some options (or give the PASV command when using a cli). However, wrt secure copy or secure ftp the situation is different: one cannot do secure copy without e.g. the client program scp. That there exist different versions of scp/sftp is unfortunate, but I agree that we should not put too much detail into the valids.
Ultimately, however, it is your call. If you are using an item delivery method that is not on the list currently, you may want to add it. On the other hand, the list is not static, so it can always be added later.

Status: closed in telecon 19 March 2003 as per CIP clarification #14 to be inserted into the Valids document
___________________________________________________________________
#46. [02 Jan 2003 - Maurice klein Gebbinck]
Map Projection Name ENUM type

Elements that have no valids lists associated with them should not be of type ENUM, but of type STRING, INTEGER, REAL, etc.

G.Landgraf: sources found
- MIL-STD-2411-1, 1994: only few (11) entries "Lambert Conformal Conic"
- EPSG Guidance Note 7, updated ISO 19111 in 8/02: 12 projections, 4 in addition to MIL-STD-2411, 1 id clash "Lambert Conic Conformal"
- EPSG Projection DB V4.200 (25-Nov-98) (from www.opengis.org): some more, naming in contradiction with EPSG Guidance Note, "Lambert Conformal Conic 1SP"
- www.remotesensing.org/geotiff (refers to EPSG guidance Note and codes): 40 codes, 6 are spzialisations, "Lambert Conic Conformal (1SP)", "Lambert Conic Conformal (2SP)", "Lambert Conic Conformal (2SP Belgium)"
- OpenGISProject document 99-050: OpenGIS Simple Features Specification for OLE/COM, Rev. 1.1, May 18, 1999, Chapter 4.6 Supported MapProjections: 44 projections, UTM missing, some clashes, sometimes upeer-/lower case only. "Lambert conformal conic"
- EC WS on Map projections,2001: 7 projections identified, 4 in addition to MIL-STD-2411, overlapping have same id, but new ones sometimes differ in id from EPSG, "Lambert Conformal Conic"

Archie Warnock, for telecon 19 Jan 2003:
------------------------------------
Values specified in GEO:
"Albers Conical Equal Area"
"Azimuthal Equidistant"
"Equidistant Conic"
"Equirectangular"
"General Vertical Near-sided Projection"
"Gnomonic"
"Lambert Azimuthal Equal Area"
"Lambert Conformal Conic"
"Mercator"
"Modified Stereographic for Alaska"
"Miller Cylindrical"
"Oblique Mercator"
"Orthographic"
"Polar Stereographic"
"Polyconic"
"Robinson"
"Sinusoidal"
"Space Oblique Mercator"
"Stereographic"
"Transverse Mercator"
"van der Grinten"
"other projection"

Action Guenther: draft a list for discussion from available input

Guenther Landgraf, for telecon 19 Jan 2003:
-------------------------------------------
seems obsolete given Archie's input. I suggest to start with the GEO list.

Status: closed in telecon 18 June 2003 with the following updates:
- to the CIP spec: change the 'Valids Source' flag for Map Projection Name to 'O'
- to the Valids Document: add Map Projection Name inheriting above list of GEO values as initial set

___________________________________________________________________
#47. [02 Jan 2003 - Maurice klein Gebbinck]
ProductFormat/-Compression ENUM types

Elements that have no valids lists associated with them should not be of type ENUM, but of type STRING, INTEGER, REAL, etc.

CIP 2.4 spec only lists some example valids for ProductFormat: "CEOS Superstructure", "HDF", "SDTS".

Archie Warnock, for telecon 19 Jan 2003:
------------------------------------
From GEO:
File Decompression Technique -- 6.4.2.1.6
recommendations of algorithms or processes (including means of obtaining these algorithms or processes) that can be applied to read or expand data sets to which data compression techniques have been applied.

Type: text
Domain: "No compression applied" free text

telecon 19 Jan 2003:
--------------------
It shall be decided by majority vote if this attribute shall be of type ENUM or STRING. Email voting to the cintex email account is open until 14 March 2003

Action ALL: vote STRING or ENUM for ProductFormat/-Compression attributes

Votes received for "STRING": 5 individuals/3 Agencies
- Guenther Landgraf
- Archie Warnock
- Jean-Marie Wallut
- Maurice klein Gebbinck
- Jolyon Marting

No votes were received for ENUM

Status: closed telecon 19 March 2003 with resolution "change Value syntax for ProductFormat and ProductCompression to STRING in CIP 2.4 Appendix B"

___________________________________________________________________

#48. [02 Jan 2003 - Maurice klein Gebbinck]
SpatialKeywordsThesaurus, ThemeKeywordThesaurus ENUM types

Elements that have no valids lists associated with them should not be of type ENUM, but of type STRING, INTEGER, REAL, etc.

Guenther Landgraf, 02 Jan 2003:
-------------------------------
I suggest to change the source to 'O' and add the relevant information in the Valids document. For the time being, only one thesaurus "IDN" should be supported for both.

Archie Warnock, for telecon 19 Jan 2003:
------------------------------------
From GEO:
Theme Keyword Thesaurus -- 1.6.1.1
reference to a formally registered thesaurus or a similar authoritative source of theme keywords.

Type: text
Domain: "None" free text

Status: closed as per suggestion (initial support for single value "IDN") in telecon 19 Feb 2003

___________________________________________________________________
#49. [02 Jan 2003 - Maurice klein Gebbinck]
TemporalKeywordThesaurus ENUM type

Elements that have no valids lists associated with them should not be of type ENUM, but of type STRING, INTEGER, REAL, etc.

Archie Warnock, telecon 19 Jan 2003:
------------------------------------
In the past it has not proven feasible to define a finite number of values for this type of keyword

Guenther Landgraf, telecon 19 Jan 2003:
----------------------------------------
Proposed Resolution:
- currently support only Value "None" for TemporalKeywordThesaurus and clarify that in this case the value of TemporalKeyword is free text
- delete current valid list from Valids document, as it is not proven to be used.

Status: closed in telecon 18 June 2003 with the following updates:
- to the CIP spec: change the 'Valids Source' flag for TemporalKeywordThesaurus to 'O'
- to the Valids Document:
- add TemporalKeywordThesaurus with a single initial value "None" and clarify that in this case the value of TemporalKeyword is free text
- delete current valid list for Temporalkeyword

___________________________________________________________________
#50. [02 Jan 2003 - Maurice klein Gebbinck]
StorageMedium ENUM type

Elements that have no valids lists associated with them should not be of type ENUM, but of type STRING, INTEGER, REAL, etc.

Guenther Landgraf, 02 Jan 2003:
-------------------------------
I suggest to change the source to 'O' and add the relevant information in the Valids document, defining a shared list for 'StorageMedium' and 'ProductMedium', adding a comment for values that are not supposed to be used for ProductMedium.

Status: closed as per suggestion in telecon 19 Feb 2003

___________________________________________________________________
#51. [02 Jan 2003 - Maurice klein Gebbinck]
Order Option Amendment AlongGridUnitType ENUM type

OOA lists valids as "relative", "time based". I think it would be clearer to remove the pseudo-valids "0" and "1" from the Meaning column (at least it seems unclear which is the real valid).

Archie Warnock, telecon 14 Jan 2003:
------------------------------------
0/1 would provide for language-independence and there is some push to use such code lists in TC211.
However, for the CIP valids a different philosophy has been applied so it would be preferable to use the self-explaining text values

Status: closed in telecon 19 Feb 2003: allowed values are "relative" and "time based", pseudo-valids 0/1 shall be eliminated from OOA.

___________________________________________________________________
#52. [02 Jan 2003 - Maurice klein Gebbinck]
Order Option Amendment PolygonProjection ENUM type

Valid values are identical to MapProjection, but that element has no valids.
Instead the list should be identical for "MapProjectionName" (for which the list still needs to be defined).

Status: closed as per suggestion in telecon of 14 Jan 2003

___________________________________________________________________
#53. [02 Jan 2003 - Maurice klein Gebbinck]
Order Option Amendment TemporalResolution type

In the CIP 2.4 spec an element TemporalResolution with tagvalue 4119 exists that is a searchable and of type STRING with no valids. In the OOA another element TemporalResolution exists with tagvalue 4292, not searchable, of type INTEGER (instead of ENUM), and it is listed as having valids. In fact, table A-4 of the OOA lists these valids, which maybe should be moved to the Valids document?

Guenther Landgraf, 02 Jan 2003:
-------------------------------
For the Order Options Amendment I suggest to: change the name of the element in the OOA to 'SubsettingTemporalResolution' and its Value Syntax to ENUM

If for the CIP2.4 spec the type of "TemporalResolution is changed to ENUM, then I suggest to move the OOA table A-4 TemporalResolution values into the Valids document as controlled list shared between TemporalResolution and SubsetTemporalResolution with slow rate of modification.

telecon 19 March 2003:
----------------------
changes to OOA were presented and agreed. Guenther to detail the valid list for discussion on TemporalResolution.

Guenther Landgraf, 20 Mar 2003:
-------------------------------
Temporal resolution Valid list defined in OOA
s single second
h single hour
d single day
w one-week interval
m one-month interval
y one-year interval
W one calendar week (Monday to Sunday)
M one calendar month
Y one calendar year (January to December)

telecon, 18 June 2003:
----------------------
Guenther Landgraf: Probably we should not to be too limitative in the CIP spec and leave the type as string:

Archie Warnock: agreed, as a general principle there should not be a need to limit the attribute to a controlled value list for attributes that are not used for searching

Maurice klein Gebbinck: actually TemporalResolution is an optionally supported search attribute for collections

Gene Major: In GCMD there exists a controlled list for Temporal resolution

Gene Major, 19/06/2003: provided proposal to GCMD for Temporal Resolution controlled value list

telecon, 18 February 2004:
-------------------------
Gene Major reports that GCMD Temporal Resolution controlled value list has been approved by the required quorum

Gene Major, 24/02/2004 (condensed version of original email)
------------------------------------------------------------
the following set of valids ranges for "Temporal_Resolution_Range"
(further details at http://gcmd.gsfc.nasa.gov/pipermail/interop/2003-September/000014.html)

< 1 second
1 second - < 1 minute
1 minute - < 1 hour
Hourly - < Daily
Daily - < Weekly
Weekly - < Monthly
Monthly - < Annual
Hourly Climatology
Daily Climatology
Pentad Climatology
Weekly Climatology
Monthly Climatology
Annual
Annual Climatology
Decadal
Climate Normal (30-year climatology)

Proposed solution, telecon 17 Mar 2004:
=======================================
CIP spec temporal Resolution: GCMD list shall be adopted as Valids list changing TemporalResolution to ENUM and adding it to CIP Valids document
OOA spec temporal Resolution: change the name of the element to 'SubsettingTemporalResolution' and its Value Syntax to ENUM

Status: closed in telecon 21 April 2004 as per proposed solution of 17 March 2004
___________________________________________________________________
#54. [08 Jan 2003 - Maurice klein Gebbinck]
CollectionHierarchyCategory Valids

In CIP 2.2 the valids for CollectionHierarchyCategory were "product" and "guide". Since guide is no longer considered in CIP 2.4, it seems logical that the new list only contains "product", which is how I have implemented it in INFEO (before it was either "Product" or "Theme", which was wrong alltogether). Instead the meaning of CollectionHierarchyCategory has been changed to be identical to CollectionCategory?

Guenther Landgraf, 09 Jan 2003:
-------------------------------
In fact, during revision of the Valids document the scope of the CollectionHierarchyCategory had been discussed and it had not been clear what it was. Thnks to Maurice's backtracking to CIP2.2 it seems clear that it was to offer a collection model that could be expanded also to other objects than EO products, and it was correct the for the purpose of EO catalogue only a single valid 'product' is supported.

I suggest to:
- delete CollectionHierarchyCategory from the valids document
- change the 'Valids Source' column to 'X' in the CIP 2.4 spec.
- define the valid 'product' for EO catalogues in the 'Meaning' column
- better define the 'Meaning' as "type of resource for which the collection tree is defined, e.g. EO products, guide documents, etc. For geospatial products the fixed value 'product' is to be used."

Status: closed in telecon 16/July/2003 as per proposed solution of 09 Jan 2003

___________________________________________________________________
#55. [08 Jan 2003 - Maurice klein Gebbinck]
ItemDescriptorLanguage/ItemLanguage - Spanish

The valid for Spanish is listed as "ese" while the others all consist of 2 characters. This should probably be "es".

Guenther Landgraf, 09 Jan 2003:
-------------------------------
to be corrected to "es".

Status: closed as per suggestion in telecon of 14 Jan 2003
___________________________________________________________________
#56. [08 Jan 2003 - Maurice klein Gebbinck]
MissionId - METEOR

The number for platform "METEOR2-" is "N24" only. If this is correct, then the platform can be listed directly as "METEOR2-N24". However, it may be that the possible numbers should be "N2-N4"?

Guenther Landgraf, 09 Jan 2003:
-------------------------------
The information was taken from the CEOS Dossier which contained the futute satellite numbering scheme.

I suggest the METEOR MissionIds to the list of actually past and current operational satellites:

METEOR2: 01 to 21
METEOR3: 04 to 06
METERO3M: no further numbering is required anymore

Status: closed as per suggestion in telecon of 14 Jan 2003
___________________________________________________________________
#57. [08 Jan 2003 - Maurice klein Gebbinck]
ThemeKeyword syntax
In the Rules/Naming Conventions the format is described as "TOPIC > TERM > VARIABLE".
It is not clear if the spaces are just editorial.
I suggest to delete the spaces to make this clear and as it is implemented like this in INFEO.

Maurice klein Gebbinck, telecon 14 Jan 2003:
------------------------------------
Checking GCMD, there the used separator is ">". Even is this implies a change to INFEO, we shoudl stick to the GCMD convention

Status: closed in telecon 19 Feb 2003 as per GCMD convention: <"greater" symbol">

___________________________________________________________________
#58. [08 Jan 2003 - Maurice klein Gebbinck]
Order Options Amendment: ProcessingOptionRepeatedValues BOOLEAN

In element ProcessingOptionRepeatedValues in Table A-2 is the only element throughout the CIP 2.4 specification that has the value syntax BOOLEAN. Maybe we should change it to ENUM, which is also the value syntax of other flag elements (e.g. LocalUseAttributesFlag, AlongGridUnitType)?

Guenther Landgraf, 09 Jan 2003:
-------------------------------
Seems like a good idea. I suggest to change to ENUM with the following allowed values
0: in case of multiple selections the selected values have to be distinct
1: in case of multiple selections two or more selected values may be identical

Status: closed in telecon 18 June 2003 as per proposal of 09 Jan 2003

___________________________________________________________________
#59. [08 Jan 2003 - Maurice klein Gebbinck]
Mandatory support for InstrumentSensor as searchable attribute in collection searches

In the schema of table C-3 support for InstrumentSensor as a searchable attribute is mandatory for collection searches ('Use Attribute CD column' flagged as 'O'). However, InstrumentSensor is a compound and there is no mandatory child attribute listed. Therefore I think that the child attribute SensorId should be made mandatory for collection searches?
Note that for product searches the support for this attribute is optional('Use Attribute CD column' flagged as 'O')

Guenther Landgraf, 09 Jan 2003:
-------------------------------
I suggest to change the 'Use Attribute CD column' entry for SensorId from '(O)' to 'O' in table C-2 of the the CIP2.4 spec.
Alternatively the entry for InstrumentSensor could be changed to '(O)'.

telecon, 19 March 2003:
----------------------
Guenther: second alternative might be preferable as this attribute typically is not supported for geographic providers and it is aim of CIP to support them
Maurice: this just propagates the problem further up

Action Maurice/Guenther: impact assessment

Maurice klein Gebbinck, 20 March 2003:
-------------------------------------
Changing InstrumentSensor support to (O), i.e. optional would imply:
- it has to be changed to (O) also as part of platform
- at this point the same problem occurs for platform which also would need to become optional (as already for PD)
- this further propagated to Platform within DataOriginator which also would need to become optional (as already for PD)
- DataOriginator would become optional in ProductCollectionSpecific

Maurice, 16 July 2003 during editing:
------------------------------------
Section A.1.1.3 should become A.1.1.2.1, section A.1.1.3.1 should become A.1.1.2.2.

Status: closed in telecon 16/July/2003 with the following updates to CIP 2.4:
Table C-3 Use Attribute/CD column:
- change InstrumentSensor entry from 'O' to (O)
- change Platform/InstrumentSensor entry from 'O' to (O)
- change Platform entry from 'O' to (O)
- change DataOrginator/Platform entry from 'O' to (O)
- change DataOrginator entry from 'O' to (O)
- change ProductCollectionSpecific/DataOrginator entry from 'O' to (O)
Table A-3/A-5:
- move InstrumentSensor, Platform, and DataOrginator from Table A-3 to Table A-5.

___________________________________________________________________
#60. [08 Jan 2003 - Maurice klein Gebbinck]
Mandatory support for TemporalRange as searchable attribute in collection searches

In the schema of table C-3 support for TemporalCoverage as a searchable attribute is mandatory for collection searches ('Use Attribute CD column' flagged as 'O'). However, TemporalCoverage is a compound and there is no mandatory child attribute listed (both TemporalRange and TemporalPeriod are flagged as options '(O)'.
The TemporalRange entry in the 'Use Attribute CD column' should be changed to 'O' (both in the entry for TemporalCoverage as well as TemporalRange), as
- already TemporalRange children StartDate and EndDate are flagged as 'O'
- this change aligns the definition with the definition chosen for the PD column

Consequently TemporalRange has to be moved from table A-5 to table A-3

Status: closed in telecon 18 June 2003 as per proposal of 09 Jan 2003

___________________________________________________________________
#61. [08 Jan 2003 - Maurice klein Gebbinck]
Structure Attribute typos

Everywhere in tables A-2 to A-9 the following changes should be made to be compliant with the list in Appendix A.4
o "bib-1 201" must become "CIP 201"
o "bib-1 205" must become "CIP 205"
o "bib-1 206" must become "CIP 206"

Ananth Rao, telecon 14 Jan 2003:
------------------------------------
Remembers a similar situation for bib-1 202 BoundingRectangle. This should be verified

Maurice klein Gebbinck, 21 Jan 2003:
------------------------------------
Ananth's remark is probably covered by clarification #1, which included the following:
Tables A-3 and Table A-7:
Attribute ID# 2060, Bounding Rectangle: change structure from "bib-1 202" to "CIP 202"

Status: closed in telecon 19 Feb 2003 as per original suggestion

___________________________________________________________________
#62. [08 Jan 2003 - Maurice klein Gebbinck]
"bib-1 100" date versus "CIP 100" time

The structure attributes "bib-1 100" and "CIP 100" are both listed in table A-14, but their difference is not clear (to me). In tables A-2 to A-9 only "bib-1 100" is used, so maybe we should remove "CIP 100" from table A-14? Intuitively, however, I think that in tables A-2 to A-9 the same error has been made as before, and that all occurrences of "bib-1 100" should be changed to "CIP 100".

Guenther Landgraf, 09 Jan 2003:
-------------------------------
Although both are using ISO/8601 Date/Time format, I understand from the specification that "bib-1 100" limits itself to the date, while "CIP 100" extends it to the time also. Both are therefore useful.

Checking tables A-2 to A-9 and also B-1, I suggest to make the follwing corrections:

- StartDate, EndDate: ok to limit to date for the search (bib-1 100) in A-2, but in the Meaning column of B-1 it should be clarified that it can contain time also

- RevisionDate: It seems that - as suggested by the text in "Meaning" time is important for this attribute also (e.g. to check if there were updates since last logon). "bib-1 100" (date only) in A-2 should be changed to "CIP 100".

- FutureReviewDate: "bib-1 100" (date only) in A-4 seems correct. "indicates a time" to be rephrased to "indicates a date" within "Meaning" of A-4 and B-1.

- ScienceReviewDate: "bib-1 100" (date only) in A-4 seems correct. In this case "and time" should be deleted from "Meaning" of A-4 and B-1.

telecon, 18 June 2003:
----------------------
- StartDate, EndDate:
Archie: time is possible in GEO but not supported in implementations - until now no complaints; might be useful in extreme cases
Jolyon: agrees that the possibility to supply time should be given
Ananth: in IMS it is possible to optionally specify alo time
Maurice: optional time would meen that for start date the default is 00:00:00.00 and for end date 23.59.59.99

suggested solution: chnge to CIP 100 to allow optionally also time

- RevisionDate: as per suggestion of 09 Jan 2003

- FutureReviewDate, ScienceReviewDate: Action Ananth Rao to check if time is used in EDG

Ananth Rao, 07 July 2003:
-------------------------
I checked into the Date datatypes used by EDG and it appears that the comment I made was not accurate - I was using an old ODL specification document and the semantics of this attribute have changed. It turns out that in the EDG, the start_date/stop_date, time is NOT optional. The date and time are mandatory and take the form:

yyyy-mm-ddThh:mm:ss
or
yyyy-mm-ddThh:mm:ssZ

Maurice's comment on default values is also relevant to common usage patterns - time values of 00:00:00Z for start_date and 23:59:59Z for stop_date are most commonly used.

So, it looks like that for compatibility purposes at least and if indeed Bib-1 100 is Date only, I would support the change of StartDate/EndDate to CIP 100 or even your original suggestion to leave it as bib-1 100 and include a note in the meaning column that it may contain time values (this option is less likely to break existing software such as the IMS Facility which does attribute mapping).

The ECS Metadata Schema has the FutureReviewDate and ScienceReviewDate attributes defined as datetime while RevisionDate is defined as a date with an optional time portion.

Archie Warnock, 15 July 2003:
----------------------------
The Z39.50 (1995) standard says that structure attribute 100 under BIB-1 is "un-normalized date". Attribute #5 is "normalized date" (which I would interpret as the ISO 8601 form. There is nothing in the Z39.50 standard to indicate that this structure attribute is to be limited to time. In fact, there is no separate structure attribute for time, which indicates to me that a time component would be acceptable.

The ATTRIBUTE SET BIB-1 (Z39.50-1995) SEMANTICS at ftp://ftp.loc.gov/pub/z3950/defs/bib1.txtftp://ftp.loc.gov/pub/z3950/defs/bib1.txt says this:

Date (normalized) 5 The day, month, year and time when a transaction or event takes place. The date search term structure is as defined for Generalized Time in ASN.1 (ISO 8824) except that the only mandatory portion of the string is the four-digit representation of the year.

Date (un-normalized) 100 The day, month, and year when a transaction or event takes place. The un-normalized search term is unstructured.

Note also that the GEO profile finesses the entire issue by declaring its own date structure "GEO 210" (Date String).

telecon, 16 July 2003:
----------------------
Ananth: in the IMS internals a time is mandatory for StartDate and StopDate, however a user can specify a date only and the software will add a time to it.

Archie: it is up to the implementor to decide what to do if a search term is missing the time part. ISO 8824 is unknown to me (but probably different from ISO 8601).

Jolyon: it does not make sense to incorporate default values for missing times in the spec because this also depends on the relation attribute used.

Maurice: proposed solution: all attributes dealing with date or time get the same structure attribute, corresponding to the ISO 8601 Date/Time standard. This means that time can be provided but is not mandatory. Implementors can take their own default values if they need a time part that is missing in the search term. The structure attribute that is most suitable for the purpose is CIP 100, but the Meaning column may have to be changed to clarify that time is optional.

Status: to be discussed in the next telecon based on the following proposed changes to the CIP 2.4 spec:
- Tables A-2 to A-9: change all occurrences of bib-1 100 to CIP 100
- Table A-14: change the Meaning column of CIP 100 to "The date and possibly time at which an event takes place. The date and time are formatted according to the ISO 8601 Date/Time standard following the ASCII presentation defined in [TIME]"

Guenther Landgraf, for telecon 20 August 2003:
--------------------------------------------
that time is allowed optionally everywhere should be consistently applied in Appendix B

I also suggest to generally easy the life of the CIP implementor defining generally for CIP100 and TIME value syntax:
- times shall be UTC times
- the time part is optional
- time may contain optionally fractions of seconds, up to millisecond precision
- dates/time shall therefore be represented according to ISO8601 format as YYYY-MM-DD["T"hh:mm:ss[,s[s][s]]Z]

Archie Warnock, telecon 20 August 2003:
--------------------------------
1) we should conciously agree that we really limit representation to the above (ISO 8601 foresees various alternatives)

2) For queries it shall be allowed to have also month and day optional

Proposed solution, 20 Aug 2003:
--------------------------------
The following changes to the CIP spec. shall apply:

1) App. B: clarify that time always intends UTC time
2) App. B: clarify that the following ISO [TIME] representations are supported:
- date only: YYYY-MM-DD
- date and time: YYYY-MM-DD"T"hh:mm:ss"Z"
- date and time with fractions of seconds up to millisecond precision: YYYY-MM-DD"T"hh:mm:ss,s[s][s]"Z"

3) App.B: Systematically clarify for all elements with data type TIME, time can be optionally supplied

4) App.A, Tables A-2 to A-9: change all occurrences of bib-1 100 to CIP 100

5) App.A, Table A-14: change the Meaning column of CIP 100 to
"The date and possibly time at which an event takes place.
The date and time are formatted according to the ISO 8601 Date/Time standard,
with the following subset of ASCII representation defined in [TIME]:
- year only: YYYY
- year and month: YYYY-MM
- date: YYYY-MM-DD
- date and time: YYYY-MM-DD"T"hh:mm:ss"Z"
- date and time with fractions of seconds up to millisecond precision: YYYY-MM-DD"T"hh:mm:ss,s[s][s]"Z"
"

Maurice klein Gebbinck, email 17 Dec 2003:
==========================================
Here you can find a date/time discussion of the W3 Consortium:
http://www.w3.org/TR/NOTE-datetime
They use a full stop intead of a comma to specify fractions of a second, which is as I expected it (the comma was a surprise for me).

Next, http://www.cl.cam.ac.uk/~mgk25/iso-time.html
Here they say both full stop and comma are possible, but the example is with full stop.

Lastly, http://www.mcs.vuw.ac.nz/technical/software/SGML/doc/iso8601/ISO8601.html
This looks to be the document being most close to ISO 8601.
It says that both full stop and comma are possible, but comma is preferred.
Fractions of a second are given in 1 decimal only(?).

Archie Warnock, 20/01/2004:
===========================
Note that in ISO 8601, the punctuation in date is optional.
That is, both YYYY-MM-DD and YYYYMMDD are acceptable. I don't really see any reason to rule those out for CIP.

Guenther Landgraf, 21/01/2004:
==============================
Some citations from ISO8601 standard:
"... decimal fraction shall be divided from the integer part by the decimal sign specified in ISO 31-0: i.e. the comma [,] or full stop [.]. Of these the comma is the preferred sign."
"... with as man digits as necessary following the decimal sign."
"5.2.1 Calendar Date ... Basic format: YYYYMMDD .... Extended format: YYYY-MM-DD"

telecon discussion, 21/01/2004:
===============================
Primary decision is on if CIP shoudl support more flexibility or of it should rather opt for a single format to be used commonly.
In the first case "Basic" and "Example" combined with both representations of the decimal sign should be supported.
A unique format has the advantage, that there is no risk that some servers support only a subset of all possibilities.

After discussion it was decided that a single format shall be supported, inheriting ECS definitions (i.e. ISO extended format) and using the period/fullstop character as decimal sign, as this woudl coincide with the majority of the software implementor communities (it was noted that some COTS tools support only period).

Proposed solution, 21 Jan 2004:
--------------------------------
The following changes to the CIP spec. shall apply:

3) App.B: Systematically clarify for all elements with data type TIME, time can be optionally supplied

4) App.A, Tables A-2 to A-9: change all occurrences of bib-1 100 to CIP 100

Status: closed as per proposed solution of 21 Jan 2004
___________________________________________________________________
#63. [08 Jan 2003 - Maurice klein Gebbinck]
LocalAttributeId structure attribute

In table A-4 the structure attribute of LocalAttributeId is listed as "bib-1 101" while its value syntax is Integer. The structure attribute probably should be changed to "CIP 206".

Status: closed in telecon 19 Feb 2003 as per suggestion

___________________________________________________________________
#64. [08 Jan 2003 - Maurice klein Gebbinck]
GPolygon Use attribute structure

In tables A-5 and A-9 the structure attribute of GPolygon is listed as "CIP 202", similar to the structure attribute of its child GPolygonOuterGRing. Although this may be correct as GPolygonOuterGRing is the only child attribute of Gpolygon (and thus it may be some sort of shortcut), I find it more logical to follow the SpatialCoverage/BoundingRectangle approach, where SpatialCoverage has structure attribute "CIP 204" (Composite) and BoundingRectangle has "CIP 202" (BoundingPolygon). Therefore I suggest to change the structure attribute of GPolygon to "CIP 204".

Guenther Landgraf, 09 Jan 2003:
-------------------------------
Defining the Gpolygon as plain "CIP202" it is not possible to specify within the search term the optional GPolygonExclusionGRing(s) which is the second part of the GPolygon compound. If this is intentional we should leave the definition as is. If not we should promote Maurice's recommendation.

In any case the spec "bib-1 202" has to be changed to "CIP 202" also for GPolygonOuterGRing

G.Landgraf, 18 Feb 2003 in preparation for telecon
--------------------------------------------------
bib-1 comment does not apply, as clarification #1 already mandated the following:
Tables A-5 and Table A-9:
Attribute ID# 3116, GPolygon: change structure from "bib-1 202" to "CIP 202"
Attribute ID# 3117 GPolygonOuterGRing: change structure from "bib-1 202" to "CIP 202"

Archie Warnock, for telecon 19 Jan 2003:
------------------------------------
Fine if intent is to disallow the GPolygonExclusionGRing. Note that GEO permits CoordinateString (GEO 201), defined as "A Coordinate String is a character string containing an ordered list of coordinates as y (latitude) and x (longitude) pairs expressed with a space or comma delimiter between the y and x and a space between the pairs, as so: y,x y,x y,x ... or 45.003,-102.32 46.007,-103.45 46.141,-103.79... If a Coordinate String is used to define an enclosing region, the terminal pair shall be encoded with the same values as the initial pair to define full enclosure. A Coordinate String with only two pairs entered shall represent a bounding rectangle where the northwest and southeast corners of a described area, using a system orthogonal to the axes of latitude and longitude. The Use Attribute Bounding Coordinates (2060) can thus be queried as a shortcut to querying the four properties that it references (i.e. North, West, South, and East Bounding Coordinates). A search region defined by the area of 23 degrees North to 5 degrees South and 70 degrees West to 10 degrees East could be expressed as either "23 -70 -5 10" or "23,-70 23,10 -5,10, -5,-70 23,-70"."

telecon 18 June 2003:
---------------------
suggested solution: no change to spec., which implies that only simple polygon is usable for search.

Maurice klein Gebbinck, 15 July 2003 in preparation for telecon
---------------------------------------------------------------
In contrast to Guenther's remark of 09/Jan/2003 it is never possible to search on GPolygonExclusionGRing because it is not a use attribute, so changing the structure attribute of GPolygon to "CIP 204" does not change anything for the status of GPolygonExclusionGRing.

telecon 16 July 2003:
---------------------
Maurice: this is largely an aesthetic issue: for the user/implementor it may be more easy if the SpatialCoverage/BoundingRectangle approach (i.e. SpatialCoverage not searchable as a leaf attribute) is used for GPolygon/GPolygonOuterGRing as well. However, if GEO allows searching GPolygon as a leaf attribute maybe CIP should allow that as well.

Archie Warnock, 17 July 2003:
---------------------
Well,

Here's a fragment from the GEO v2.2 DTD:

And, from the metadata standard:
Data Set G-Polygon -- 1.5.2
coordinates defining the outline of an area covered by a data set.
Compound.

Data Set G-Polygon Outer G-Ring -- 1.5.2.1
the closed nonintersecting boundary of an interior area. Compound.

G-Ring Latitude -- 1.5.2.1.1
the latitude of a point of the G-ring.
Type: real
Domain: -90.0 <= G-Ring Latitude <= 90.0

G-Ring Longitude -- 1.5.2.1.2
the longitude of a point of the G-ring.
Type: real
Domain: -180.0 <= G-Ring Latitude < 180.0

Data Set G-Polygon Exclusion G-Ring -- 1.5.2.2
the closed nonintersecting boundary of a void area (or "hole") in an interior area. Compound.

G-Ring Latitude -- (1.5.2.1.1)
G-Ring Longitude -- (1.5.2.1.2)

So GPolygon requires GPolygon Outer G-Ring, and the Exclusion G-Ring is optional and the associated structure attribute is 204 ("Composite").

OTOH, in FGDC we currently implement spatial searches using Bounding instead of GPolygon - at least that's what is in Isite right now. I try to be a flexible in terms of implementation, so I'd be inclined to treat GPolygon as a leaf attribute for searching because I can pretty much assume that the client probably means to search the Outer G-Ring. I do the same thing with temporal searches - I accept Time Period of Content as if it were a leaf node, even though I know it must contain either begin_date/end_date or calendar_date as child elements. I just parse accordingly because I know what children to look for.

Guenther Landgraf, for telecon 20 August 2003:
--------------------------------------------
Summary of current situation:

App. B:
SpatialCoverage [Use: CD, PD]
[ BoundingRectangle | [Use: CD, PD]
GPolygon | [Use: CD, PD - optional]
1 { Circle } n | [Use: CD, PD - optional]
1 { Point } n ] + [Use: CD, PD - optional]
[ WRSGRSScene | [Use: CD, PD - optional]
WRSGRSPass ] [Use: CD, PD - optional]

Note: SpatialCoverage is redefined as per clarification #30

GPolygon [Use: CD, PD]
GPolygonOuterGRing [Use: CD, PD]
+ {GPolygonExclusionGRing}* [Use: none]

App. A: Use attributes:
SpatialCoverage (CIP 204 - Composite )

BoundingRectangle (CIP 202 - BoundingPolygon)
NorthBoundingCoordinate (CIP 200)
SouthBoundingCoordinate (CIP 200)
WestBoundingCoordinate (CIP 200)
EastBoundingCoordinate (CIP 200)

GPolygon (CIP 202 - BoundingPolygon)
GPolygonOuterGRing (CIP 202 - BoundingPolygon)

Point (CIP 201 - Point)

It seems there is anyhow not a 1:1 match between the descriptor structure and the use attribute: see e.g. the different representations of Bounding Rectangle, or the simple fact that searching with GPolygon you of course expect also to find items where the spatial coverage is defined e.g. as BoundingRectangle.

Proposed solution, 20 Aug 2003:
----------------------------------------------------------
No changes to the CIP structure attrubute for GPolygon, but the foillowing clarifications shall be apoplied to Appendix A:

1) clarify that Use Attributes
- BoundingRectangle
- NorthBoundingCoordinate
- SouthBoundingCoordinate
- WestBoundingCoordinate
- EastBoundingCoordinate
- GPolygon
- GPolygonOuterGRing
- Circle
- Point
are to be applied to the Product- or CollectionDescriptor "SpatialCoverage" element

2) clarify that when supplying "GPolygon" Use Attribute, the semantic is identical to "GPolygonOuterGRing"

Status: closed as per proposed solution of 20 Aug 2003

___________________________________________________________________
#65. [08 Jan 2003 - Maurice klein Gebbinck]
TemporalCoverage Use attribute structure

In tables A-* TemporalCoverage Use attribute structure should be changed to "CIP 204" (from "CIP210"), because its child TemporalRange already has structure attribute "CIP 210".

Guenther Landgraf, 09 Jan 2003:
-------------------------------
with this re-definition it would be possible to search also for TemporalPeriod using the TemporalCoverage structure

Maurice klein Gebbinck, 17 June 2003:
-------------------------------------
Having made TemporalRange a mandatory use attribute (see #60), it would automatically mean that a provider has to support a search for TemporalRange with a CIP 210 structure as well.

Two cases are observed as example:
- a search for e.g. ProductDescriptor/TemporalCoverage/TemporalRange supplying a CIP 210 structure
- a search for ProductDescriptor/TemporalCoverage/TemporalRange/StartDate

Adding to the confusion is that in the first case the role of TemporalRange is that of a leaf use attribute, whereas in the second case its role is that of a compound use attribute. What does this mean for the structure attribute assigned to TemporalRange in table A.1.2.1.2, should it be CIP 210 or CIP 204 (personally my first reaction is that the structure attribute should correspond to the case in which the use attribute is used in its leaf form, so TemporalRange should have the CIP 210 structure attribute)

Maurice klein Gebbinck, 15 July 2003 in preparation for telecon
---------------------------------------------------------------
Even though formally the use attributes and the CIP schemas are independent, in reality we often consider them together. Therefore it is unclear what product properties should be matched when a search with use attribute TemporalCoverage and structure attribute CIP 210 is received: should it be treated similarly to 1) the use attribute TemporalRange or 2) the use attribute PeriodDefinition, which are both children of TemporalCoverage (according to the CIP schema) with structure attribute CIP 210, or 3) even in a completely different manner?

This confusion can be avoided by changing the structure attribute of TemporalCoverage to CIP 204, so that one can search on TemporalRange, PeriodDefinition, TemporalCoverage/TemporalRange, TemporalCoverage/TemporalPeriod/PeriodDefinition, ..., but not on TemporalCoverage only. This situation is also more in alignment with the SpatialCoverage situation, where one can search on BoundingRectangle, SpatialCoverage/BoundingRectangle, ..., but not SpatialCoverage only.

Guenther Landgraf, for telecon 20 August 2003:
--------------------------------------------
Summary of current situation:

App. B:
TemporalCoverage [Use: CD, PD]
TemporalRange [Use: CD, PD]
StartDate [Use: CD, PD] (InternationalString, Date/Time in ISO/8601 Date/Time format)
EndDate [Use: CD, PD] (InternationalString, Date/Time in ISO/8601 Date/Time format)
| TemporalPeriod [Use: CD, PD]
PeriodName, opt. [Use: none]
PeriodDefinition [Use: CD, PD] (InternationalString, recurring time interval ISO/8601 Date/Time format)

App. A: Use attributes:
TemporalCoverage (CIP 210 - DateRangeString[recurring time interval in ISO/8601 Date/Time format])
TemporalRange (CIP 204 - Composite [date recurring time interval in ISO/8601 Date/Time format])
TemporalPeriod (CIP 210 - DateRangeString[recurring time interval in ISO/8601 Date/Time format])
PeriodDefinition (CIP 210 - DateRangeString[recurring time interval in ISO/8601 Date/Time format])

Note that Temporal Coverage is in "Compound Use Attributes"

Maurice klein Gebbinck, after telecon of 18 February 2004
---------------------------------------------------------
If the TemporalPeriod element (and its children) is removed from the list of attributes as proposed by clarification #69, only TemporalRange remains as a child attribute of TemporalCoverage. In this case we can follow the same strategy that we used for Gpolygon/GpolygonOuterGRing (clarification #64), i.e. leave the CIP specification as it is but clarify that when the "TemporalCoverage" Use Attribute is supplied, its semantic is identical to that of "TemporalRange".

proposed solution, 17 March 2004 (adopting Maurice's proposal):
---------------------------------------------------------------

Clarify that when the "TemporalCoverage" Use Attribute is supplied, its semantic is identical to that of "TemporalRange".

Status: closed in telecon 21 April 2004 as per proposed solution of 17 March 2004
___________________________________________________________________
#66. [08 Jan 2003 - Maurice klein Gebbinck]
TemporalPeriod Use attribute structure

In tables A-* TemporalPeriod Use attribute structure should be changed to "CIP 204" (from "CIP210"), because its child PeriodDefinition already has structure attribute "CIP 210".

Guenther Landgraf, 09 Jan 2003:
-------------------------------
However, the only other child element of TemporalPeriod is "PeriodName", which is not searchable. So functionally there would not be any change.

Status: deleted in telecon 17 Mar 2004

___________________________________________________________________
#67. [08 Jan 2003 - Maurice klein Gebbinck]
Use attribute structure assignment

Apart from "bib-1 101", which is used often, and "bib-1 100", which may need to be changed to "CIP 100", the following bib-1 structure attributes have been assigned to the use attributes:
bib-1 2 Word ScienceReviewStatus
bib-1 6 Word list GeneralKeyword, SpatialKeyword, TemporalKeyword, ThemeKeyword, Progress, UpdateFrequency
bib-1 102 Name (unnormalised) Originator
bib-1 108 String AbstractPurpose, TemporalResolution

o Since an example valid for ScienceReviewStatus is "QA within Software", the structure attribute Word clearly is wrong as the valid contains a space.
o The same holds for SpatialKeyword, ThemeKeyword and UpdateFrequency, while GeneralKeyword and Progress can be wrong as well (in that case let's change TemporalKeyword as well).
o I don't see a justification for the special status of Originator.
o I don't see a justification for the special status of TemporalResolution.

Note that I did not study the use attributes that were assigned structure attribute bib-1 101, some of them may need to be assigned a different structure attribute.

Archie Warnock, for telecon 19 Jan 2003:
------------------------------------
Structure attributes define the type of search term. Word and WordList are generally used inchangeably (at least, in a robust implementation).
Although the profiles draw a distinction, if you think about it, what should a target do if it received a query term "QA within Software" with a structure of "Word"? To throw an error seems unduly pedantic. Word List exists to draw a distinction from Phrase.

I'm not quite sure what to do with controlled lists of valids - Phrases are probably appropriate, or String (although I'm not sure how String differs from Phrase).

Word List is permitted for keywords, in general usage, anyway, since multiple values can be included and specifying Word List as the structure allows this usage (rather than a single value, interpreted as a phrase including a space).
The distinction seems clear enough to me in this case.
I've never understood the distinction about "Name" (normalized or not), and String seems redundant.

Guenther Landgraf, for telecon 18 June 2003:
--------------------------------------------
To eliminate some doubts I suggest to perform the following changes in the structure values in section A.1:
- ScienceReviewStatus: change to bib-1 6 Word list
- Originator: change to bib-1 108 String

Archie Warnock, 15 July 2003:
-----------------------------
Again, from the BIB-1 Semantics document (make of it what you will - at this point, my eyes are glazing over...).
To be perfectly honest, I've never had need for anything more than Phrase, Word list and Word, and Word is probably unnecessary, too (I can't imagine where I'd need to use Word instead of Word list):

Phrase 1 A phrase consists of one or more groups of characters separated by blanks (for example, ASCII hex "20"). The value to be searched is exactly as it appears in the search term with respect to order and adjacency. Word(s) in the phrase may be explicitly truncated. (See "Truncation" -- section 2.5 below.) To indicate that additional words may appear in the access point, use the completeness attribute.

Word list 6 A word list consists of one or more words separated by blanks (for example, ASCII hex "20"). No order of the words is implied. The attributes (other than structure) that are associated with the search term apply to each word in the word list. Any words in a word list may be explicitly truncated. (See "Truncation" -- section 2.5 below.) The relationship between the words in a word list is target-specific.

Name (normalized) 101 A name search term that is structured in a particular order (e.g., last_name, first_name). The resulting term is subject to special matching rules on the target system that differ from those applied to names structured as phrases or unstructured names.

Name (un-normalized) 102 A name search term that is unstructured (e.g., first_name last_name), however, the resulting term is subject to matching rules on the target system that differ from those applied to phrases or structured names (e.g., the term "john smith" might be searched by the target as "smith, j#").

String 108 The entire term is to be treated as a string, rather than a sequence or set of individual words.

Status: suggestion to be discussed at next telecon

Guenther Landgraf, for telecon 20 August 2003:
--------------------------------------------
Considering Archie's findings on word list, applying it like this to GeneralKeyword, SpatialKeyword, TemporalKeyword, ThemeKeyword, Progress, UpdateFrequency seems simply wrong (in fact there may be blanks between the words and the order is relevant.

For Originator instead we have to consider that is could alos be the name of an organisation (CIP 2.4 p.B-7)

Therefore I suggest to revise the assignment as follows:

ScienceReviewStatus: change from "bib-1 2 Word" to "bib-1 108 String"

GeneralKeyword,
SpatialKeyword,
TemporalKeyword,
ThemeKeyword,
Progress,
UpdateFrequency: change from "bib-1 6 Word list" to "bib-1 108 String"

Originator: change from "bib-1 102 Name (unnormalised)" to "bib-1 108 String"

telecon 20 August 2003:
---------------------------------------
Archie: limiting to String would find anly exact matches which might be an excessive limitations for some terms. "Phrase" would be already better as it would eliminate differences in use of punctuation, spacing , etc, still finding a match only if the words appear in the same order. "Word list" is preferred in free-text search, as the order of words could be inverted.
"String" seems appropriate only for elements where a fixed controlled keyword list exists.

Proposed solution, 20 Aug 2003:
--------------------------------
The following provisions for CIP spec. App.A Use Attribute structure assignment shall apply:

- ScienceReviewStatus: change to "bib-1 108 String" (features controlled keyword list)
- GeneralKeyword: remains to "bib-1 6 Word list" (element is free text)
- SpatialKeyword: change to "bib-1 108 String" (features controlled keyword list)
- TemporalKeyword: remains to "bib-1 6 Word list" (element is free text as per clarification #49)
- ThemeKeyword: remains to "bib-1 6 Word list" (features controlled keyword list, but with multiple levels)
- Progress: change to "bib-1 108 String" (features controlled keyword list)
- UpdateFrequency: change to "bib-1 108 String" (features controlled keyword list)
- Originator: change to "bib-1 6 Word list"
- Abstract: change to "bib-1 6 Word list"
- Purpose: change to "bib-1 6 Word list"
- TemporalResolution: change to "bib-1 6 Word list" (may feature controlled keyword list, but with multiple words)

Maurice Klein Gebbinck, 21/08/2003:
===================================
I think for ThemeKeyword (#67) we should use String instead of Wordlist, since all ThemeKeyword valids contain spaces.
But maybe I don't understand what you intend to say with the "with multiple levels" remark, so I may be wrong.

Guenther Landgraf, 16/09/2003:
==============================
Some examples to clarify my understanding:

Let's take 3 Theme keywords:

1) Hydrosphere>GroundWater>Land Subsidence
2) Hydrosphere>Snow/Ice>Snow/Ice Temperature
3) Hydrosphere>Water Quality>Water Temperature

setting to "String" you will find any hit only providing exactly the same string.

using word list instead, you can find all 3 with "Hydrosphere", only 2)+3) with "Hydrosphere Temperature" and only 2) with "Snow Temperature"

So it depends if we assume that the valid to be searched is selected from a list or if we allow a kind of "free search". This latter one might be useful, as the list is quite long.

Maurice Klein Gebbinck, 15/10/2003:
===================================
To avoid confusion as well as to simplify implementation, in INFEO we use the approach that the search term - string in our case - always needs to include the beginning of the ThemeKeyword, but thanks to a right truncation attribute not the ending. Example: a search term "Hydrosphere > Ground Water" with right truncation attribute would match "Hydrosphere > Ground Water > Land Subsidence" as well as all other collections having ThemeKeywords that start with "Hydrosphere > Ground Water".

Just to be complete - though not really relevant: a search on "Hydrosphere > Ground Water > Land Subsidence" with right truncation attribute does not match collections with the ThemeKeyword "Hydrosphere > Ground Water".

A problem with the approach you described is best explained with an example. See the following piece of the valids document, which ThemeKeywords all fall under Biosphere:
Microbiota > Biomass
Microbiota > Chlorophyll
Microbiota > Pigments
Microbiota Taxonomy > Amoebae
Microbiota Taxonomy > Bacteria
Microbiota Taxonomy > Blue-green Algae
Microbiota Taxonomy > Ciliates

How can I specify that I want to start all ThemeKeywords that start with "Biosphere > Microbiota" but not the ones that start with "Biosphere > Microbiota Taxonomy"? Okay, also INFEO's approach would have a problem, but thinking of it I could resolve that by specifying "Biosphere > Microbiota >" (OR-ed with another term "Biosphere > Microbiota" without right truncation attribute).

Archie Warnock, 20/01/2004:
===========================
OK, this one is really hard. First off, many search engines will ignore the ">" symbol as punctuation, even in a phrase. I leave it as an exercise to the reader to make the case as to whether that's a bug or a feature. But it seems to me that a single element is unsuited to handling hierarchical data, so we're really trying to hack together a solution out of tools that are unsuited to the job.

It may be most appropriate to add a new structure attribute, to indicate that the query term is to be interpreted as a hierarchy, and leave the implementation up to the search engine. Just a reminder - the purpose of the protocol is, largely, to unambiguously transmit the origin's intention to the target, and to unambiguously transmit the results back.
I'm not convinced we have an unambiguous way to do that in this case except to defer to literal strings, which is highly likely to induce frustration in users who fail to get the syntax exactly right.

telecon 21/01/2004:
===================
As indicated in Archies email there are 2 options:
- properly "engineer" the hierachy aspect, restructuring the Themkeyword properly
drawback is the potential impact om search engine implementation and or the riks that it will not be implemented unambiguously
- step back and defer to literal strings
drawback is the user problem to get the Themekeyword string correct, which is probable to lead to user frustrations,unless it is assumed that the user uses a client that allows him to pick up the keywords from a list.

G.Landgraf, 18/02/2004
======================
We have to consider that the ThemeKeyword valid valuu list depends on the ThemeKeywordThesaurus.
We have deliberately left the door open to oter thesauri, e.g. from application communities.
These thesauri are not necessarily hierarchical and therefore it seems not advisable to restructure the Themekeyword hierarchically.

Proposed solution, 18 Feb 2004:
--------------------------------
The following provisions for CIP spec. App.A Use Attribute structure assignment shall apply:

- ScienceReviewStatus: change to "bib-1 108 String" (features controlled keyword list)
- GeneralKeyword: remains to "bib-1 6 Word list" (element is free text)
- SpatialKeyword: change to "bib-1 108 String" (features controlled keyword list)
- TemporalKeyword: remains to "bib-1 6 Word list" (element is free text as per clarification #49)
- ThemeKeyword: change to "bib-1 108 String" (features controlled keyword list)
- Progress: change to "bib-1 108 String" (features controlled keyword list)
- UpdateFrequency: change to "bib-1 108 String" (features controlled keyword list)
- Originator: change to "bib-1 6 Word list"
- Abstract: change to "bib-1 6 Word list"
- Purpose: change to "bib-1 6 Word list"
- TemporalResolution: change to "bib-1 6 Word list" (may feature controlled keyword list, but with multiple words)

Status: closed as per proposed solution from 18/02/2004
___________________________________________________________________
#68. [20 Aug 2003 - Guenther Landgraf]
BoundingRectangle subelements as use attributes

App. A features (among others) the following use attributes:

BoundingRectangle (CIP 202 - BoundingPolygon)
NorthBoundingCoordinate (CIP 200)
SouthBoundingCoordinate (CIP 200)
WestBoundingCoordinate (CIP 200)
EastBoundingCoordinate (CIP 200)

While these last four make full sense in App.B, where the BoundingRectangle structure is defined, their usefulness as separate "Use" (i.e. searchable attributes) can be disputed.

If the user wished to search for products (or collections) south of 55 degrees N, it is very simple and natural to express this as BoundingRectangle N+55, S-90, W-180, E+180. I would not necessarily share the opinion that the user will prefer to look for a dedicated Use Attribute to be used for a special case.

Moreover, the validity to specify an isolated West- and EastBoundingCoordinate can even be disputed.

What means a Search with WestBoundingCoordinate=-5 ? Does it end at the 0-meridian? or at the international Dateline (+180)?
In both cases it seems quite strange that if I specify an additional "constraint" EastBoundingCoordinate = -170 suddenly the search area becomes larger. As in many of the early COTS geospatial indices it seems forgotten that the world is round !

I feel there is no real relevant additional comfort and it is preferable to simply (the already overloaded) CIP spec. by deleting N-, S-, W-, E-BoundingCoordinates from the Use attributes.

Ananth Rao, 20/01/2004:
=======================
I looked into the ECS system and it looks like the BoundingRectangle subelements are closely tied to the top-level element.
BoundingRectangle is defined as an llbox (Lat/Long Box) and the four individual coordinates are mandatory from the search side.
This implies that you cannot use the subelements as "use attributes" individually.
From the EDG side, while the client allows you to specify individual subelements alone, the underlying ODL protocol fills in any missing values with default (global) values.

Archie Warnock, 20/01/2004:
===========================
Many people (naively) assume that a bounding box spatial query can be represented by a Boolean combination of the four bounding coordinates. It can't (it's hard to handle the dateline and the orientation that way), but you'll see it nonetheless. For interoperability purposes, it's probably best to assume you'll see it, even if you don't want to make the individual coordinates searchable.

I actually agree that any search on a single coordinate necessarily implies limits on the other four, as well, and we may as well let the profile reflect that. But as always, code the implementation defensively.

Proposed solution, telecon 21 Jan 2003:
--------------------------------------
In App.A the following BoundingRectangle subelements shall be removed from the use attributes:
- NorthBoundingCoordinate (CIP 200)
- SouthBoundingCoordinate (CIP 200)
- WestBoundingCoordinate (CIP 200)
- EastBoundingCoordinate (CIP 200)

Status: closed as per proposed solution of 21 Jan 2004
___________________________________________________________________
#69. [21 Aug 2003 - Guenther Landgraf]
TemporalPeriod semantic conflict

Current structure for TemporalCoverage is:

TemporalCoverage =
[ TemporalRange =
StartDate +
(EndDate)
| TemporalPeriod
(PeriodName) +
PeriodDefinition
]

App. B defines PeriodDefinition as "recurring time interval" with syntax "TIME", i.e. as of ISO8601.
ISO 8601 defines "recurring time interval" as "series of CONSECUTIVE time-intervals of the same duration".

This seems to clash with the intentions of TemporalPeriod, as the example for PeriodName (see App.B, Meaning) features e.g. "Spring - Northern hemisphere), implying non-consecutive periods, which syntactically cannot be expressed by PeriodDefinition.

Furthermore the above example for Periodname is a semantic replication of "TemporalKeyword".

I suggest to eliminate the element PeriodName completely. If found appropriate, the TemporalKeyword can be introduced instead as optional element into the ProductDescriptor, but I would rather leave it at CollectionDescriptor level.

For what regards the PeriodDefinition, it does not make sense at all like this and could simply be replace by allowing multiple Temporal Ranges. I suggest to delete also the PeriodDefinition element and instead re-define TemporalCoverage as:

TemporalCoverage =
1{ TemporalRange =
StartDate +
(EndDate)
}n

Proposal telecon 17 Dec 2003:
============================
1) delete PeriodName from TemporalCoverage attribute and instead allow optional TemporalKeywork for the ProductDescriptor
2) delete support of TemporalPeriod as Use attribute
3) completely delete TemporalPeriod from TemporalCoverage, if not operationally used somewhere
4) Make TemporalRange attribute multiple inside TemporalCoverage to allow for multiple periods (however only a single instance shoudl be allowed as use attribute

Maurice Klein Gebbinck, 17 Dec 2003:
===================================
At the end you can find some examples of recurring period definitions. Not that I think anybody is going to use it, but in theory now it is possible to search for data that starts on a certain date and is refreshed e.g. every week (using the PeriodDefinition use attribute). If PeriodDefinition is deleted from the CIP spec (clarification #69) this is not possible anymore unless you supply a search request containing infinitly many TemporalRange use attributes chained using AND. In any case, it would be hard to implement the PeriodDefinition logic at the RM: if I search for a period starting the 1st of January 2002 that recurs every 7 days, would this match an item starting the 2nd of January 2000 recurring every day? I guess yes, but implementing it...
Therefore I would agree with you to drop it, making the spec more simple.

Repeating the TemporalRange element, however, is not a perfect substitute for PeriodDefinition. Theoretically, an item that is repeated e.g. every hour would lead to an infinite list. Practically, even if the measuring device would exist for only 1 year and one measurement would be done every day, the list would become very/too long to display. In such a case, as a provider, I would define a single TemporalRange covering the whole period.

Ananth Rao, 20/01/2004:
=======================
ECS supports the following Temporal types:
- Periodic : Regularly occuring periods of time
- Point In Time : A single date and time, usually used for in-situ measurements
- Continuous Range : A single continuous range of time with a discrete start date time and stop date time.
- Discontinuous Multiple Range: A span of time with irregular temporal coverage gaps, requiring the use of multiple start/stop datetime pairs to denote the complete coverage.
- Multiple Point in Time : Multiple occurences of single date and time points.

My feeling is that the PeriodDefinition/PeriodName was intended to support regular recurring time intervals.
The App. B Meaning for PeriodName (Spring-Nothern Hemisphere) probably came directly from the ECS spec - reproduced below:
The ECS attribute DsMdRegularPeriodic is defined as:
CollectionId
PeriodName
Period1stDate
Period1stTime
PeriodDurationUnit
PeriodDurationValue
PeriodCycleDurationUnit
PeriodCycleDurationValue
The example given is:
With a PeriodName defined as 'spring-north hemi', it might have a
PeriodDurationUnit =month
PeriodDurationValue=3.0
PeriodCycleDurationUnit=year
PeriodCycleDurationValue=1.0
indicating that Spring-North Hemi lasts for 3.0 months and has cycle duration of 1.0 year.

telecon, 21/01/2004:
====================
It was decided to give priority to CIP spec simplification and maybe add features for which it is not clear that there is an important user need when such a need arises.

The proposed solution is therefore to delete Temporalperiod (with subelements PeriodName and PeriodDefinition) from the TemporalCoverage attribute, without making this last one multiple.

Status: closed as per proposed solution from 21/01/2004
___________________________________________________________________
#70. [November 2004 - Ananth Rao, Bernhard Buckl]
Editorial comments (section, page, and line numbers refer to draft version 2.4.69)

1. [AR] Section 1.4, page 1-12, references [TIME]
Referenced ISO specification is incorrect. It should read ISO 8601 and not ISO 860.

2. [AR] Page 3-93, ASN.1 for PaymentMethod
The line "privateNotKnown [4] IMPLICIT EXTERNAL}," does not parse with ASN.1 parser, it should read "privateNotKnown [4] IMPLICIT EXTERNAL".

3. [BB] Section 1.3.1, page 1-4, line 11
"Deutsche Forschungsanstalt für Luft und Raumfahrt" should be "Deutsches Zentrum für Luft- und Raumfahrt".

4. [BB] Section 1.3.2.2, page 1-10, line 39
"allow and origin" should be "allow an origin".

5. [BB] Section 1.3.2.2, page 1-10, line 40
"Z390.50" should be "Z39.50".

6. [BB] Section 1.3.2.2, page 1-10, line 40ff
The definition of Facility is somehow imprecise: The Initialization Facility consists of one service, the init service, which is
composed of InitializeRequest and InitializeResponse while the explain facility consists of services defined by other facilities
(Search and Present Service).

7. [BB] Section 2.3.1, page 2-4, line 38
"for which the were" should be "for which they were".

8. [BB] Section 2.3.4, page 2-6, line 40
"a authentication" should be "an authentication".

9. [BB] Section 2.3.4, page 2-6, line 41
"or an public key" should be "or a public key".

10. [BB] Section 3.5.1, page 3-5, line 3
"Z39.59" should be "Z39.50".

11. [BB] Section 3.5.2.1, page 3-11, graph
CreationDate is no product use attribute.

12. [BB] Section 3.5.2.1, page 3-11, graph
SensorId has the attribute value 4113 and not 4112.

13. [BB] Section 3.5.2.1, page 3-11, line 22
"where an attributes" should be "where an attribute".

14. [BB] Section 3.5.2.6, page 3-17, line 31
There should be a reference to the table where the element set names are defined.

15. [BB] Section 3.5.3.1, page 3-26, line 16
"Point has value 4071" should be "Point has value 4072".

16. [BB] Section 3.5.3.5, page 3-33, line 1
"Retrieval Service" should be "Retrieval Facility".

17. [BB] Section 3.5.3.5, page 3-37, line 3
"segmentRequest" should be "SegmentRequest".

18. [BB] Section 3.5.3.5, page 3-37, line 22
"number of records" should be "number of complete/unfragmented records".

19. [BB] Section 3.5.6.1, page 3-49, line 3
"Association" should be "A-Association" or "Z-Association"?

MkG, 13/12/2004:
----------------
This should probably be "Z-Association" since resource reporting is negotiated by the Initialisation Facility,
which establishes a Z-association.

Telecon 15/12/2004
------------------
No objections (and Archie agrees).

20. [BB] Section 3.5.6.4, page 3-52, line 18, construction "Either ... or"
"Either" might not be useful because ResourceReport is not a CHOICE.

MkG, 13/12/2004:
----------------
I assume that since the estimates field is an IMPLICIT SEQUENCE of Estimate, one can also supply the empty sequence if one wants to return
only a simple message (as INFEO does). To point this out to the reader we might write "Both an estimates structure and a simple message
are provided, either of which may be empty."

Telecon 15/12/2004
------------------
No objections.

21. [BB] Section 3.5.7, page 3-56, line 14
"allows origin to" should be "allows an origin to" or "allows origins to".

MkG, 13/12/2004:
----------------
I will change this to "allows origins to" to stay in line with the rest of the text.

22. [BB] Section 3.5.7.1, page 3-58, line 2
"or groups or users" should be "or groups of users".

23. [BB] Section 3.5.7.1, page 3-61, line 20
"the element parameter" should be "the elements parameter".

24. [BB] Section 3.5.7.1, page 3-63, line 6
"see ... in Table 30" should be "see ... in Table 28".

25. [BB] Section 3.5.7.3, page 3-64, line 26
"storing the a result set" should be "storing a result set".

26. [BB] Section 3.5.8.1, page 3-73, line 24
"privileged users user" should be "privileged users".

27. [BB] Section 3.5.8.3, page 3-79, line 11
"so far as possible" should be "as far as possible".

28. [BB] Section 3.5.8.4, page 3-80, line 12
"may also indicates" should be "may also indicate".

29. [BB] Section 3.5.8.8, page 3-85, line 20
"by proxy for the" should be "as a proxy for the".

30. [BB] Section 3.5.8.8, page 3-85, line 32
"user's identifiers" should be "user's identifier".

31. [BB] Section 3.5.8.8, page 3-87, line 31
"Retrieval Manage" should be "Retrieval Manager".

32. [BB] Section 3.5.8.9, page 3-92
"FTPMethod ... is one of the following" should be "FTPDelivery ... is composed of the following"/

33. [BB] Section 3.5.8.9, page 3-92
transferDirection has nothing to do with e-mail.

MkG, 13/12/2004:
----------------
What about the following Meaning:
"transferDirection, which specifies whether the delivery unit will be retrieved by the user himself ('pull')
or will be delivered by the provider ('push') on the FTP-server specified by the user."

Telecon 15/12/2004
------------------
No objections.

34. [BB] Section 3.5.9.2, page 3-102, line 29
"list of ... are given" should be "list of ... is given".

35. [BB] Section 3.5.9.2, page 3-116, line 16
"field in the its" should be "field in its".

36. [BB] Section 3.5.9.2, page 3-117, line 23
"provides details on the attribute value" should be "provides details of the attribute values".

37. [BB] Section 3.5.9.2, page 3-118, line 27
"field in the its" should be "field in its".

38. [BB] Section 3.5.9.2, page 3-121, line 19
"in which order ... is used" should be "which order ... is used".

39. [BB] Section 3.5.9.2, page 3-123, line 14
"which are that are" should be "that are".

40. [BB] Section 3.5.9.2, page 3-124, line 5
"can provided" should be "can be provided".

41. [BB] Section 3.6, page 3-131, line 6
"a single a Z-association" should be "a singe Z-association".

MkG, 13/12/2004:
----------------
Same thing in Section E.5, page E-3.

42. [BB] Section 3.9, page 3-131, line 32
"and collection tree" should be "and the collection tree".

43. [BB] Section 3.9.1, page 3-132, line 6
"same target than" should be "same target as".

44. [BB] Section 3.9.3, page 3-134, 3rd paragraph
This should be described in more detail: The information is contained in NamePlusRecord in the element records
of either a Search- or PresentResponse.

45. [BB] Section 3.9.5, page 3-135, line 20
"which included in its" should be "which includes in its".

46. [BB] Section 3.9.6, page 3-136, line 26
Reference to Annex D is irrelevant, it should be (???).

MkG, 13/12/2004:
----------------
No idea what the authors wanted to refer to, I think we can simply delete the phrase.

Telecon 15/12/2004
------------------
Ananth suggests maybe Annex D of the z39.50 spec was referred to.
Maurice already checked this some time ago and found this is not the case.
No objections to delete the phrase.

47. [BB] Section 3.9.7, page 3-136, line 36
"This section provide" should be "This section provides".

48. [BB] Section 3.9.7.1, page 3-136, line 43/44
"piggyback feature" should be "piggybacking feature".

49. [BB] Section 3.9.7.4.1, page 3-139, line 43
"LocalProductUserAttributes" should be "LocalProductUseAttributes".

50. [BB] Section 3.9.8, page 3-141, line 22
"Next record ... of 0" should be "Next record ... or 0" (twice).

51. [BB] Section 3.9.9.8, page 3-153, graph
"Z-operation" should be "Z-operation response".

52. [BB] Section A, page A-1, line 32
"or the by the CIP" should be "or by the CIP".

53. [BB] Section E.9, page E-10
"CIP_order = " should be "CIP_order_prefix = ".

54. [BB] Section C.3, page C-13
"AcrossGridUnitType" should be "AlongGridUnitType".

55. [BB, from minutes telecon 13 October 2004] Valids document, section 5.3.1
Bernhard says "DVD" should be added. Archie says we cannot possible add all media. Maurice suggests to add them on demand (Archie agrees).

56. [BB, from minutes telecon 13 October 2004] Valids document, section 5.3.2
Bernhard says certain MissionIds are missing (BIRD, SRTM, TerraSAR-X). Maurice did not change the list wrt version 1.0, but will request
a new list from the administrator of alto-stratus.wmo.ch (see comment JM below) and include it in the valids document.

Jolyon Martin, when writing minutes:
------------------------------------
Apart from SRTM these omissions can be found in the CEOS dossier (URL reported in valids document as
http://alto-stratus.wmo.ch/sat/stations/SatSystem.html), in any case the valids document should be updated.

Telecon 15/12/2004
------------------
Maurice contacted Donald Hinsman from the WMO, who said they were currently doing the yearly database update but would be able to send the
list of Missions and Instruments after that.

57. [BB, from minutes telecon 13 October 2004] Valids document, section 5.3.3
Bernhard says certain SensorIds are missing (XSAR). Maurice did not change the list wrt version 1.0, but will request a new list from the
administrator of alto-stratus.wmo.ch and include it in the valids document.

Telecon 19/01/2004
------------------
Closed as suggested.

STATUS: closed.
___________________________________________________________________
#71. [17 November 2004 - Yonsook Enloe]
References to Protocol Task Team (PTT)

Throughout the CIP specification, in particular on the cover page as well as in the header and footer of each subsequent page,
the Protocol Task Team is mentioned. However, the PTT does no longer exist but has been followed up by the Interoperable Catalogue
System taskteam (ICS). Therefore references to the PTT should be substituted by references to the ICS, with a short note
in the beginning of the document that credits the PTT.

Telecon 15/12/2004
------------------
Closed as suggested.

STATUS: closed.
___________________________________________________________________
#72. [17 November 2004 - Yonsook Enloe]
References to the ICS Guide Protocol (IGP)

Since the ICS Guide Protocol has been abandoned, all references to it should be removed from the CIP spec.

Telecon 15/12/2004
------------------
Closed as suggested.

STATUS: closed.
___________________________________________________________________
#73. [14 September 2004 - Maurice klein Gebbinck]
Value syntax of AltitudeDatumName

The value syntax of AltitudeDatumName should be changed from REAL to STRING.

Telecon 17/11/2004
------------------
Closed as suggested.

STATUS: closed.
___________________________________________________________________
#74. [from minutes telecon 13 October 2004, Bernhard Buckl]
Valids of Scale

Bernhard says the smaller-than signs in the Valids document, section 5.1.3, should be changed into greater-than signs. Archie agrees,
but proposes in addition to remove the smaller-than sign completely when the valid refers to a range (i.e. for all except the first and
last valid).

Maurice klein Gebbinck, after telecon but before minutes
--------------------------------------------------------
On the Internet I found http://www.es.mq.edu.au/courses/GEOS264/maps/mapch2/lscale.htm. It says that:

A large amount of confusion is caused by the two terms "large scale" and "small scale". "Large scale" refers to maps on which objects are
relatively large, "small scale" to maps on which objects are relatively small. Large scale and small scale are subjective terms.
For example a town planner who is used to working with plans at 1:1000, may consider 1:25 000 a small scale map, while an atlas compiler
commonly working with maps of scales 1:5 000 000 would consider 1:25 000 a large scale map. To understand the use of the terms, first think
about the ratio method of showing map scale:
the ratio 1:10 000 - means that the size of objects on the map is 1/10 000 of their size on the ground.
the ratio 1:250 000 - means that the size of objects on the map is 1/250 000 of their size on the ground.
1/10 000 is a larger fraction than 1/250 000, so 1:10 000 is the large scale map. (In the same way that 1/2 of an apple is a large piece of
apple when compared to 1/8 of an apple).

So this supports Bernhards remark, if I look for a map with scale 1:400 than I should look for Scale = "greater-than-or-equal to 1:500"
instead of Scale = "smaller-than-or-equal to 1:500". Although originally I agreed with Archie's remark about removing the smaller-than sign
for ranges I have changed my mind. Either we should leave them, or valid "< 1:500 - 1:5000" should become "1:501 - 1:5000" to avoid confusion
for maps having scale 1:500.

Archie Warnock, 17/11/2004
--------------------------
I have now recalled my objection, which was semantic. I don't know (and
we certainly haven't documented) what it means to have a scale less than
some range. Forgive me if I've got the signs backwards in the following
- I'm just quoting from the notes at this point.

Perhaps it's clear to everyone but me what "< 1:500 - 1:5000" means and
if that's the case, someone please enlighten me. Does it mean that the
target scale is less than every value in the range (ie, less than 1:500)
or does it mean that it's less than some value _in_ the range?

If the former, "< 1:500" would be a better way to express it. If the
latter, wouldn't "< 1:5000" would be a better way to express it? In
what sense is specifying the entire interval less ambiguous than
specifying it in terms of one or the other of the endpoints?

Regardless, we need to carefully document the semantics.

Maurice klein Gebbinck, 17/11/2004
----------------------------------
I think you should read the valid as "less than 1:500"; "to (inclusive)";
"1:5000", in other words the less-than sign only applies to the first scale but
not to the range as a whole.

I saw that Scale is also a use attribute for collection searches: give me all
collections where Scale equals "<1:500 - 1:5000". Using valids like "<1:500" and
"<1:5000" do not do the trick because if the search term contains Scale equals
"<1:500" then a collection which has scale 1:6000 and therefore in the
collection database has been assigned the Scale value "<1:5000" would not match
textually, although semantically it does have a scale smaller than 1:500.

I think part of the confusion comes from the fact that Scale is a string, if it
was a real it would have been more easy because a user could specify in his
search request that Scale < 0.002 (note that 1:500=0.002). Certainly 0.002 is
visually less attractive than 1:500, but this could be handled by the client
interface.

Archie Warnock, 17/11/2004
--------------------------
> I think you should read the valid as "less than 1:500"; "to
> (inclusive)"; "1:5000", in other words the less-than sign only
> applies to the first scale but not to the range as a whole.

So in this case, it's an inclusion symbol, requiring that the target
scale is supposed to be inside the range? In that case, I'd suggest
that what it really needs is a new relation attribute of "within."

I hope I'm not coming off as overly argumentative. I just don't (or
didn't) understand what the notation "< 1:500 - 1:5000" actually means -
either as a value to search against, nor as a significant value to
interpret as a reader.

My personal opinion is that the use of the "<" symbol in that context of
range is incorrect at worst, misleading at best. I can live with it but
either way, we haven't given a definition in the document itself.
That's the ultimate point - even if we all agree on the interpretation,
we have to document the semantics because I don't think it's going to be
obvious to some who will read the specification.

> I think part of the confusion comes from the fact that Scale is a
> string, if it was a real it would have been more easy because a user
> could specify in his search request that Scale < 0.002 (note that
> 1:500=0.002). Certainly 0.002 is visually less attractive than 1:500,
> but this could be handled by the client interface.

If Scale is a string, then it's not clear to me (at least, from an
implementation standpoint) how one would actually search on it, nor is
it necessarily clear to me that, for presentation purposes, the "<" and
">" characters - used as prefixes - represent inclusion. Doug Nebert's
point of how GEO uses scale-denominator makes searching simple - it's a
numeric search and translation to a readable scale value is easily left
to the client.

Bernhard Buckl, 17/11/2004
--------------------------
I propose to keep your
range suggestion and turn the first and last comparison signs:

>= 1:500 for scale greater than or equal to 1:500
i.e. 1:500, 1:499 to 1:10E-infinity ;probably 1:1 is big enough ?

1:501 - 1:5000
1:5001 - 1:10000
...
< 1:1000000 for scale smaller than 1:1000000, i.e. 1:1000001 to 1:10E+infinity

and ommit the spaces in scales like "1:1 000 000".

Maurice klein Gebbinck, 17/11/2004
----------------------------------
I also thought of that but what if the scale of a product is 1:5000.5 ?I know,
the likelihood is small but this way the valids don't seem to cover all cases.
Or can we in this case appeal to the significance of numbers (I vaguely remember
from my physics course many years ago that 500 does not mean 500.0, it means
499.5 to 500.49999999999)?

Doug Nebert, 17/11/2004
-----------------------
In our practice (FGDC metadata) we use a term of scale-denominator and
then we can restrict it as an integer rather than a string. Then one
need not worry whether it is less or larger or small, as one is looking
at a pure numeric inequality operator (< <= = => >). We can always
display the result with a 1: in front of it, but the confusion is reduced.

Bernhard Buckl, 17/11/2004
--------------------------
That's the way we should do it too, I think.

Telecon 15/12/2004
------------------
Archie and Jolyon/Maurice agree that Doug's suggestion could be a good solution. Archie suggests to investigate what the impact of
this change to current clients would be; agencies are invited to report their findings at the next telecon. Maurice confirms that INFEO
would have to be changed, but the extent of the changes would be limited.

Telecon 19/01/2005
------------------
INFEO needs minor changes, the Isite client supports searching on a numerical scale denominator already. No reports detailing client problems have been received from other agencies.

Maurice, after telecon
----------------------
The following changes to the CIP spec are proposed:

- Table 61: substitute the Scale row by:
4108 2.3 Scale Scale Denominator INTEGER X CIP 206 The denominator of the scale of the data (e.g. map).

- Table 65:
4108 2.3 Scale Scale Denominator INTEGER X CIP 206 The denominator of the scale of the data (e.g. map).

- Table 76:
4 4108 Scale scale Scale Denominator INTEGER X CIP 206 The denominator of the scale of the data (e.g. map).

- Remove all traces to Scale from the Valids document.

Telecon 09/02/2005
------------------
No further comments on proposed changes.

Telecon 06/04/2005
------------------
Closed as suggested.

STATUS: closed.
___________________________________________________________________
#75. [13 December 2004 - Maurice klein Gebbinck]
Valids for and value syntax of LocalUseAttributesFlag, ProcessingOptionRepeatedValues

One of our contractors asked what the format of the LocalUseAttributesFlag attribute should be. Table B-1 of the CIP 2.4 spec says
it has the Value Syntax ENUM and defines values 0, 1, and 2. Table A-4 again lists the values 0, 1, and 2, but also defines the
Structure attribute to be bib-1 101, which is Name (normalised). This indicates LocalUseAttributesFlag in a search request should be coded
as a string not as an integer. I assume the same conclusion is valid for LocalUseAttributesFlag in the present response, but how can we
formally derive this from Table B-1? The same observation can be made for the element ProcessingOptionRepeatedValues in Table A-2
of the OOA, which has values 0 and 1.

1. I propose, analogue to CIP clarification #51, to substitute the numerical strings by alfanumerical strings,
e.g. for LocalUseAttributesFlag :
0 -> "no local attributes"
1 -> "defined within collection descriptor"
2 -> "defined within explain database"
and for ProcessingOptionRepeatedValues:
0 -> "no repetition"
1 -> "repetition allowed"

2. Inclusion of a Str(ucture) column in Table B-1 similar to Tables A-2 to A-11.

Telecon 15/12/2004
------------------
Maurice says that it is unclear to him what the Value Syntax column exactly defines. If it defines the ASN.1 datatype as may be derived
from table 58, it is imprecise because z39.50-1995 does not seem to know REAL and ENUM? Archie would like to think a bit more about the
impact of changing numeric (but string?) valids into string valids, as well as about how the ASN.1 datatype the various elements can be
derived.

Telecon 19/01/2005
------------------
Archie says the proposed change from numeric to string values is in line with how other valids have been dealt with in the past. He will have a look at how the ASN.1 datatype of the various elements can be derived.

Maurice, after telecon
----------------------
The following changes to the CIP spec are proposed:

- Tables 61 & 76: change the Meaning column of LocalUseAttributesFlag to "Flag indicating whether a collection has 'no local attributes', local attributes 'defined within collection descriptor', or local attributes 'defined within explain database'."

- Table 76: change the Meaning column of ProcessingOptionRepeatedValues to "Flag indicating whether in case of multiple selections the selected values have to be distinct ('no repetition') or two or more selected values may be identical ('repetition allowed')."

- Table 76: include a Str(ucture) column based on the Value Syntax column and the following mapping:

Value Syntax Structure ASN.1
==========================================================================
compound CIP 204 EXTERNAL
STRING bib-1 108 InternationalString
INTEGER CIP 206 INTEGER
REAL CIP 200, if a Coordinate or Lat/Lon InternationalString
REAL CIP 205, otherwise InternationalString
ENUM bib-1 108 InternationalString
TIME CIP 100 InternationalString
EXTERNAL External, with in footnote ASN.1 type OCTET STRING

The result of applying these rules can be seen in http://styx.esrin.esa.it:5000/CINTEX/CIP-FOR-REVIEW/table76_with_Structure.pdf.

Telecon 09/02/2005
------------------
No further comments on proposed changes.

Telecon 06/04/2005
------------------
Closed as suggested.

STATUS: closed.
___________________________________________________________________
#76. [from CIP - DLR Clarification Requests, issue 1.0 13/04/2005, Bernhard Buckl]
Order Item Cancellation (3.5.8.6)

See CIP - DLR Clarification Requests for the current text of this clarification request. The original text of this clarification request was sent out on the ICS mailing list on 13/04/2005.

Telecon 11/05/2005
------------------
Jolyon suggests that it may be more elegant to implement this using the same approach used for updating an order, but this needs to be looked into further. Ananth says that also ECHO has this functionality at order item level, and that this clarification should be considered together with functionality to monitor an order at item level (which is in fact is clarification #77). Maurice notices after the telecon that if the same field order is to be kept in OriginPartToKeep and OriginPartNotToKeep, orderItemsIds in OriginPartNotToKeep should be element [2] instead of [3].

Telecon 08/06/2005
------------------
Bernhard agrees on the minor change in field order suggested. Action on Jolyon to formulate alternative solution.

Telecon 13/07/2005
------------------
Jolyon was unable to complete his action. Bernhard agrees that is postponed to the next teleconference.

Telecon 24/08/2005
------------------
Jolyon unable to formulate the alternative approach in a clear way, the original approach from DLR acceptible.

Telecon 06/10/2005
------------------
No further comments, therefore closed as suggested by Bernhard.

STATUS: closed.
___________________________________________________________________
#77. [from CIP - DLR Clarification Requests, issue 1.0 13/04/2005, Bernhard Buckl]
Manual Order Monitoring (chapter 3.5.8.5.1/9, fig 19, table 38)

See CIP - DLR Clarification Requests for the current text of this clarification request. The original text of this clarification request was sent out on the ICS mailing list on 13/04/2005.

Telecon 11/05/2005
------------------
To Maurice it is unclear which optional tags on the path OrderSpecification > deliveryUnits > packages > [predefinedPackage > orderItems | adHocPackage] > orderItem are to be omitted.

Telecon 08/06/2005
------------------
Bernhard proposes to add the following text: "This leaves a minimum structure of:
orderSpecification
-> deliveryUnits (SEQUENCE of DeliveryUnitSpec)
-> packages (SEQUENCE of PackageSpec)
-> package (CHOICE {predefinedPackage [1] PredefinedPackage, adHocPackage [2] AdHocPackage})
-> orderItem (SEQUENCE of OrderItem)
-> orderStatusInfo
Only these tags plus the mandatory tags PackageSpec.packageMedium, PackageSpec.packageKByteSize and PredefinedPackage.collectionId, OrderSpecification.orderingCentreId and OrderItem.productId shall be returned by the target."

Telecon 13/07/2005
------------------
No further comments were made.

Telecon 24/08/2005
------------------
Ditto

STATUS: Closed.
___________________________________________________________________
#78. [from CIP - DLR Clarification Requests, issue 1.0 13/04/2005, Bernhard Buckl]
CustomerReference should be optional (3.5.8.9, table 38)

See CIP - DLR Clarification Requests for the current text of this clarification request. The original text of this clarification request was sent out on the ICS mailing list on 13/04/2005.

Telecon 11/05/2005
------------------
Maurice asks if this change would also allow the target to not return CustomerReference, in which case a comment would need to be added to disallow that. Archie suggests that it may be possible to make CustomerReference optional in the request part but mandatory in the response.

Telecon 08/06/2005
------------------
All agree on Archie's suggestion to make CustomerReference optional for the origin but mandatory for the target

Telecon 13/07/2005
------------------
No further comments were made.

STATUS: closed.
___________________________________________________________________
#79. [from CIP - DLR Clarification Requests, issue 1.0 13/04/2005, Bernhard Buckl]
UserDescriptor

See CIP - DLR Clarification Requests for the current text of this clarification request. The original text of this clarification request was sent out on the ICS mailing list on 13/04/2005.

Telecon 11/05/2005
------------------
Maurice asks if this needs coordination with the GEO profile (wrt tag numbers, SUTRS tags). Archie will have a look at this. There is a typo in Table 2 of DLR's document: "VATReigstrationNumber" (tagnumber 5011) should be "VATRegistrationNumber".

Telecon 08/06/2005
------------------
Bernhard acknowledges the typo. Archie confirms that no coordination is necessary (since it not part of GEO/GILS).

Telecon 13/07/2005
------------------
No further comments were made.

STATUS: closed.
___________________________________________________________________
#80. [from CIP - DLR Clarification Requests, issue 1.0 13/04/2005, Bernhard Buckl]
CollectionDescriptor

See CIP - DLR Clarification Requests for the current text of this clarification request. The original text of this clarification request was sent out on the ICS mailing list on 13/04/2005.

Telecon 11/05/2005
------------------
Maurice says that although the INFEO software would need to be updated to implement this, it would probably be a relatively small effort. Archie says that care has to be taken that this does not introduce ambiguities when the client is parsing the response (in case multiple Processing elements are returned, or non even though the client is expecting one). Agencies are invited to report on the ICS mailing list whether or not this change would cause problems to their clients.

Telecon 08/06/2005
------------------
No agency raised further comment.

Telecon 13/07/2005
------------------
No further comments were made.

STATUS: closed.
___________________________________________________________________
#81. 81. [27 June 2005 - Maurice klein Gebbinck]
Extension of ThumbnailData

In the course of operating the INFEO system, ESA has found out that handling
image data like browse images or thumbnails as data within the protocol slows
down the system considerably. In order to improve performance it is proposed
to extend the ThumbnailData element such that the thumbnails themselves can
also be passed as a URL and retrieved by the client directly (i.e. outside of
the CIP). A possible way to achieve this is to redefine ThumbnailData as:

ThumbnailData =
[ ItemData |
URLPointer ]

which is similar to the definition of BrowseData.

Telecon 13/07/2005
------------------
Ananth asks if the ThumbnailData element should be repeatable. Jolyon says
that ESA in some cases has >1 thumbnail for a product, but that automatically
the best thumbnail is returned to the client. Allowing more thumbnails to be
returned might necessitate additional metadata elements to be returned such
that a client can select which thumbnail is most appropriate for display.
It was decided that agencies report at the next teleconference if they require
the ThumbnailData element to be repeatable.

DLR (like ESA) is one of the few agencies that already uses the ThumbnailData
element. Bernhard will ask his contractor to see how complicated it is to
modify the software for the new ThumbnailData definition.

There was some uncertainty about the elementset that the ThumbnailData element
is part of. A quick check of Archie and Bernhard confirmed that it is part of
Summary (and Full and CIP Full) but not of Brief.

Telecon 24/08/2005
------------------
Bernhard suggests that ThumbnailData and ThumbnailURL are kept as
different elements (not a compound element) which would be more backward
compatible. Archie also considers that this is a good solution.

Telecon 06/10/2005
------------------
Maurice reports that ESA has implemented DLR's proposal using a local element.
Significant performance improvement was achieved, and although esthetically less
beautiful than the original proposal DLR's proposal is effective and has the
advantage of being backward compatible. ESA therefore supports DLR's proposal.
No other agencies had further comments.

Telecon 17/11/2005
------------------
No further comments were made.

STATUS: closed.