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