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

The convention used to explain this was included and diagrams updated to be more clear with respect to cardinality and associations.

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.

Additional text is added to better define what components of CTS2 are required.

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.

The ELS is an optional component of the Federation and has its own profile, outside of the ServD Federation

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?

The EA model file has the profile binding diagram added into it.
Also the Federation and Coverage areas diagram was not in the EA model file, now it is.

.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".

Update the diagrams to be consistent with the use of instance classifiers

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?

Revise the text to more clearly describe the ELS functionality

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?

The text was extended to better describe the context.

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.

Reword the text to more clearly articulate the scope of the directory standard

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)

The addition of a PageSize property on the PagesSearchResult object resovles this issue.

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.

In order to satisfy this requirement the generic RecordResult object that is the base class for both the Update and Delete result is extended to include the URL.
Brian: I believe this is on the correct object as the delete may require moderation and thus the object will still exist, and hence the retrieve details URL is valid.

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)

The RecordRequiringApproval Data structure is to be extended to include 2 new properties, one for the RetrieveDetailsURL, and another for the Parent Records index.
To make this change more apparent the diagram in section 8.2.6 on page 29 on the Reject Change Workflow is modified to separate the MaintainableServD Core into the 2 interfaces to show which interface is required to be called

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

Remove the CurrentLocalSystemTime property from the Availability object as specified in Section 8.8.3 on Page 79. All the date-time properties must have the timezone specified and handled accordingly. The Directory must process all date-times in UTC, converting where required.
The description for the AvailableAt property in this object is also unclear, need to reword it.

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

In order to be able to specify a search for an item exactly as requested the ProviderSearchParameter and ServiceSiteSearchParameter objects have add the appropriate Ids added to them, and the parameters diagram updated.

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

The namespaces in question were from Microsoft and introduced as a result of the way in which the Visual Studio toolset creates the wsdl files for the following datatypes:
string[]
(an array of strings) This is output as an ArrayOfString type in the Microsoft namespace.
This was changed to be a local datatype and not one from the Microsoft namespace (although it is exactly the same definition)
enum where the numeric values assigned to the values were not sequential from 0 some Microsoft WSDL extensions were included to capture these values in the WSDL.
All enumerated types were modified to remove the specific numeric values and therefore no longer have the Microsoft extensions required.

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.

Add the OrganizationId property to the Site record, add the SiteId property to the ServiceSite record.
The ServiceSiteId field on the ServiceSiteProvider record will no longer be marked as mandatory to be consistent with the others.

As a result of this change, the Id for the context of the Add is no redundant in the AddSite and AddServiceSite Maintenance Operations.

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

A new parameter is added to the GetReferenceListDetails operation to permit the caller to indicate what type of interface is desired, and some supportive text in the Locator Profile Binding (section 8.4.1) to describe how this is to used.

It was decided to use a string instead of the enumeration from CTS2 as it will be more flexible to support other types of reference list implementations other than those provided by the current version of CTS2.

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.

Add the new parameter to the RegisterSearchEndpointForCoverageArea operation as described. This then provides the caller of the operation a way to indicate what behavior the Locator should have.

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)

Make the function name and return parameter changes as recommended.

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 RecordRequiringApproval entity was extended to have the Record Status Property

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

Include a new property “CoverageAreaCode” of type string on the SearchInputParameters as described.

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.

Include the RetreiveServiceSiteProvider Operation