A related issue is how services that allow both authenticaticated and unauthenticated access communicate that fact. Conventionally (and currently for >99.9% for resources), the lack of any securityMethod declaration has indicated an open resource. In original VOResource 1.1, the intent has been to simply add an interface without any security method. With the single-interface approach now preferred, this is undesirable. Therefore, open access will, by this erratum, be indicated by a security method without a standardID.
Erratum Content
In the schema (VOResource-v1.1), the lines:
<xs:element name="securityMethod" type="vr:SecurityMethod"
minOccurs="0" maxOccurs="1">
(lines 1127f) are changed to
<xs:element name="securityMethod" type="vr:SecurityMethod"
minOccurs="0" maxOccurs="unbounded">
Also in the schema, the second documentation element of the securityMethod child of the interface type definition (starting line 1134),
<xs:documentation>
Services not requiring authentication must provide
at least one interface definition without a
securityMethod defined.
</xs:documentation>
is changed to
<xs:documentation>
A missing securityMethod child indicates an interface usable without authentication.
In the presence of at least one securityMethod element, services indicate the possiblity of
unauthenticated access using an empty securityMethod element (i.e., one without standardID).
</xs:documentation>
In the VOResource 1.1 REC document, the following changes are made:
- PDF p. 36 in "vr:Interface Type Schema Definition": replace macOccurs="1" with maxOccurs="unbounded" in the xs:element for securityMethod.
- PDF p. 37, in "Occurrence" of the "Element securityMethod": Add "multiple occurrences allowed" after "optional".
|