Issues for Mailing list of the Services Directory 1.0 (ServD) Finalization Task Force

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 18654: Unable to identify location of RetrieveDetailsURL for pending changes
Issue 18662: Unable to identify location of RetrieveDetailsURL for newly added records
Issue 18663: Search Parameter objects for Provider and ServiceSite missing ID fields
Issue 18664: Availability objects CurrentLocalSystemTime is meaningless
Issue 18665: The PagesSearchResult is missing PageSize
Issue 18666: LastModificationDate on the SearchItem and Search Params
Issue 18667: Scope of ServD not clearly defined
Issue 18668: Component Capability Discovery. It is unclear why this sub-clause is present
Issue 18669: The context of the ELS in the Terms and Definitions is unclear
Issue 18670: Interaction Diagrams missing instance indicator ":"
Issue 18671: Profile Binding Diagram not in Model (EA file)
Issue 18672: Profile Binding ELS Note context unclear
Issue 18673: Scope of CTS2 implementation required
Issue 18674: Notation for String (collection) should be explained
Issue 18694: RecordRequiringApproval does not have RecordStatus
Issue 18700: ServiceSiteProvider Inconsistent Operation Naming/incorrect return parameters
Issue 18710: There is no RetrieveServiceSiteProvider operation
Issue 18711: The SearchInputParameters object does not have a CoverageArea property
Issue 18712: RegisterSearchEndpointForCoverageArea operation does not indicate if a reset is required
Issue 18713: GetReferenceListDetails cannot define which type of interface
Issue 18720: Site, ServiceSite, ServiceSiteProvider Parent Ids missing/not mandatory
Issue 18780: Vendor names in wsdls need to be removed

Issue 18654: Unable to identify location of RetrieveDetailsURL for pending changes (servd-ftf)

When retrieving the list of changes that are available the results do not indicate the location of a retrieve details service that can provide the complete object, and also missing is the "parent" object which can be used to locate the entity pending the change (specifically where there is no Retrieve method for the entity, such as an address or contact point, as they are in the context of a provider, or organization)

When you add a new organisation (or other record) the return object does not contain the location of a retrieve details service that can provide the complete object as added.

The Search Parameter Object ProviderSearchParameter is missing the Provider ID field to permit the direct locating of a specific record.
Also missing is the ServiceSiteID on the ServiceSiteSearchParameter object.
These fields are required to permit the location of a specific record to then be able to locate the appropriate RetrieveDetails URL to get the complete picture.
Issue is observed in the overview diagram on page 78 and also the object definitions on pages 83 and 87

The Availability Object has a CurrentLocalSystemTime property which is not usefull for handling timezones.
The specification need to ensure that timezone information is correctly handled on the AvailableAt property. 

This could be handled by ensuring that all callers only interact with the ServD system using UTC, and all dates in the system are assumed to be UTC (or converted to UTC) for processing/storage/return values

If the Service decides that the requested page-size was not acceptable and uses a different page size to the one requested (I.e. the caller put in millions to try and "dump" the database, and service decides that it wants to only accept 100 as highest number) then the caller has no idea what the actual page size used was.
(Except maybe to see that there are more pages of data, and that the number of items is different to what was expected)

This would be very useful to be able to see if changes have been made and keep local address books up to date.
And then easy to see if changes need to be loaded further by calling the retrieve details which is a "heavier" call to the service for a more complete level of detailed information.

1. Scope - first sentence implies that ServD only supports location information. What about service characteristics?


Doesn't ServD support all information about the providers, organizations, sites and their services and relevant characteristics. Both for consumption by both People and computers.
Need to reword to be clearer.

ELS does not seem to be included in any of the specified components. Why is this text not just included in Annex A? 
Also, i.e. ELS related to other web services and Open distributed processing interface directory functions, such as ODP/CORBA Trader and UDDI?

4. Terms and Definitions. ELS is listed as a term. Is its function limited to computer interface service endpoints? 
Is ServD restricted to physical locations of services provided by people and organizations, or can ServD be used to find Endpoints for machine interfaces offering computerized services?

.2 Interaction diagrams. 
Each of these diagrams has an invoking component. It is unclear why this is not shown as a type, i.e. why is there not a ":" before the component name?
Also many of the interface lifelines do not have a ":" before the interface type in the lifeline header. 
The ":" prefix use appears to be inconsistent in its application throughout the Sequence Diagrams in 8.2.
8.2.1 Provider Search Sequence diagram. the locator lifeline should be labelled ":Locator" rather than "Locator".

8.3 Profile binding. Are the class diagrams in this subclause included in the EA file? I cannot find them. Where is the source file for these diagrams?

8.3 Profile binding. It is unclear why the note regarding ELS under the first diagram is required. ELS does not appear in the figure.

8.4.1 ServD Locator configuration. States "All of the required TCS2 reference lists must be configured. Is use of CTS2 required for conformance to this specification, and if so, How much of CTS2 is required.

8.5.2.1 Method LocateSearchEndpointsForCoverageArea. Return value specified as "String (collection)", It should be explained that this is a convention to show a Return Result which is an array.
8.5.2.2 Method GetReferenceListDetails. The signature has a return value of ReferenceListDetail (collection). Is this supposed to be multi-valued (i.e, array). This notation should be explained somewhere. It shows with a [] in the UML diagram in section 8.5.1

You cannot tell the status of a record that requires approval apart from in the description or summary fields, hence a caller is not able to elegantly present the information to a user for actioning

The ServiceSiteProvider Maintenance functions for Add and Update do not return an array of results where they should, and they the name is not in the same format as for all other operations.


Should be renamed to:
ServiceSiteProviderAdd
and
ServiceSiteProviderUpdate

(existing implementations could continue with the old name and return parameters for compatibility)

To be more consistent with the other RetrieveDetails and Maintenance interfaces there should be a routine that directly reads the ServiceSiteProvider record from its ID.
This enables callers to verify the status of a link in a more direct way.

Without the CoverageArea property being in the search parameters the federated search is not possible as shown in the diagram in section 8.2.2 Provider Search (Federated).
The implementation does not have a coverage area to interrogate the federation as to which directories to issue the search to.

As this is the primary search field it should be in the main search parameter object: SearchInputParameters

When calling the RegisterSearchEndpointForCoverageArea operation there is no definition in the specification for what the implementation should do with any coverage areas not included in the call (delete them, or leave them alone).
The return code includes a summary of items added, updated, and deleted.
So the implication is that it should delete them, but it isn't defined.

Suggest that an additional parameter be added to make that decision explicit.

When calling the GetReferenceListDetails interface, there is no way to determine if the caller wants to know about REST or WSDL style interfaces.
This needs to be passed in as a parameter to the call.

probably of type ImplementationProfile from the CTS2 CoreService

The objects Site and ServiceSite do not have their parent’s ID included in the object structure. Hence when calling retrieve details the object does not have the information as to what Id it’s parent has (unless it already knew via the search call or previous history ­ it is not explicitly included).

The ServiceSiteProvider record’s ServiceSiteId field is not marked as mandatory and the ProviderId is marked as mandatory. This is inconsistent.

Machine readable documents dtc/13-05-06 thru dtc/13-05-09, inclusive, have XML namespace definitions containing vendor names.  Please remove them.