Richard Martell wrote:
> Hi,
>
>
> I've aggregated my comments regarding the latest RIM revision. Three
> levels of severity are distinguished:
>
> MAJOR - significant impact, should be resolved
> MINOR - inconsistency that might hinder implementation or
> interoperability
> ADVISORY - an editorial tweak, correction, or clarification
>
> Again, no CRITICAL issues to report :-)
Hi Richard, Thanks very much for taking the time to provide comments in
advance and with pre-triaging done.
It is very helpful to your over-worked editor ;-)
>
>
> 1 [MAJOR] RepositoryItem and ExtrinsicObject
>
> In section 1.5, replace occurrences of RegistryObject with
> ExtrinsicObject, since this is the actual type that serves as a proxy
> for repository items that reflect some specified content (media) type.
>
> Perhaps add a few words about using ExternalLink objects to reference
> items located in external repositories maintained by a third party.
> Or is this gambit frowned upon?
The approach we have taken in both specs is to start very simple and
build up complexity incrementally. There is symmetry throughout teh
specs between the duality posed by having both a Registry and a
Repository. This is symmetrically posed throughout the spec in terms of
RegistryObjects (metadata) and RepositoryItems (content). There is no
telling whether there may be content associated with other
RegistryObject types in future.
Also if you follow the library analogy through it fits very well with
the RegistryObjects (metadata) and RepositoryItems duality.
Lastly, ExtrinsicObject is a name that throws peoples midns in a loop. I
prefer to introduce it later rather than earlier.
For these reasons, I feel fairly certain that we should make no change
for above.
>
>
> 2 [MINOR] In 2.5.6 a lid is required, but not in the schema. Modify
> rim.xsd accordingly, and update the specification text such that
> within a publication request the submitter must specify either (i)
> a temporary (dummy) value that is subsequently replaced by the
> registry, or (ii) an absolute URI assigned by some other naming
> authority.
I think you may be mistaken. It is already in rim.xsd at line 161.
Suggest no change for this reason.
>
> 3 [MAJOR] In 2.5.9 the basic lifecycle of a registry object is ambiguous
> and should be clarified with a simple state diagram (also in terms of
> the canonical events listed in 7.1.2.1).
>
> e.g.
>
> approval deprecated deleted
> Submitted -------> Approved ---------> Deprecated ------> Withdrawn
>
> What triggers a state transition? Presumably a user can explicitly
> approve, deprecate, or delete objects. In which case the registry
> must not ignore the attribute in a request (which contravenes the spec
> directives).
We used to have a state diagram but I removed it in version 3 as it
seemed that there were links from nearly every state to every other
state and it looked like one big ugly confusing mess. Plus it was a pain
for me to keep up-to-date and looking pretty. I did not find it was
helping readability and understandability that much. State transitions
are triggered by LCM protocol request such as
Submit/Approve/Deprecate/Undeprecate/RemoveObjectsReqest
Suggest no change for version 3.
> 4 [MINOR] In 2.7.1 the id and home attributes are specified for
> ObjectRef, but these are inherited from Identifiable and are therefore
> redundant here.
This point was raised and resolved (to no change) during review of draft
01. It is deliberately duplicated because it has soem special semantics
for ObjectRef such as caching a local replica of remote ObjectRef.
> 5 [ADVISORY] In 2.8.1 perhaps change values to type Set<LongName>
> instead of Bag, since duplicate values don't appear to be meaningful
> in this context.
Duplicate for values of a Slot do make sense. For example lets say the
Slot values store the Gender of each student in a class. I know it is a
dumb example but thats the best I can think of at present. Suggest no
change.
>
>
> 6 [ADVISORY] In 2.8.3 append the following sentence: "The slotType
> attribute may also be used to indicate the type or value domain for
> the slot value(s)."
+1
Thanks for catching this important use of slotType. Will add in next
version as follows:
"The slotType
attribute may also be used to indicate the data type or value domain for
the slot value(s)."
> 7 [MINOR] In 2.9.1 the default value for mimeType is
> "application/octet-stream". But what if there is no corresponding
> repository item? In this case, presumably the mimeType attribute
> is empty (i.e., there is no default value). Or would this absence be
> signalled by omitting ContentVersionInfo?
That is correct. ContentVersionInfo is the indicator of whether there is
a RepositoryItem or not.
I can see how we could also use the mimeType to do the same but prefer
no change since
change is not necessary.
> 8 [MINOR] In 2.9.4 append the following sentence: "The value
> should be a registered MIME media type."
Oops. I missed this. It was pointed out in draft 01 review. Thanks.
Fixed in draft 03.
Here is proposed slightly modified text:
" The value of this attribute SHOULD be a registered MIME media type at
http://www.iana.org/assignments/media-types ."
> 9 [MAJOR] In 3.6.1 (and elsewhere) ObjectRef is used as the type for
> many attributes. However, rim.xsd employs simple URIs (referenceURI)
> almost exclusively, rather than ObjectRefType (a complex type that
> maps to the ObjectRef class).
>
> The ObjectRef datatype in 2.2 has the same name as the RIM class. No
> packages are defined, so this is somewhat confusing. Perhaps rename
> the "ObjectRef" datatype in 2.2 so it doesn't clash with the class,
> or reuse one of the other simple URI-based types, like UUID.
I understand how what you decsribe can be confusing to the reader. Let
be give the rationale and thinking behind the way it is and see what
needs to change in the verbiage.
From a UML perspective, a reference attribute in a RegistryObject can
reference a local or remote object via an ObjectRef instance. The reason
it MUST be an ObjectRef is that that is the only way one can have a
single Domain Data Type that can handle local *AND* remote references
symmetrically.
Now when the UML Model is mapped to XML Schema a reference attribute
always maps to a referenceURI. The referenceURI value references an
ObjectRef instance within the same XML document that may be a local or
remote ObjectRef. If the ObjectRef is missing then the referenceURI is
implicitly pointing to a local ObjectRef.
When a reference attribute is mapped to SQL Schema it maps to a
VARCHAR(256), which is basically a string. The id value contained in
reference attribute columns may be a foreign key linkage into an entry
in the ObjectRef table and if none is found then similar to XML Schema
it is implictly referencing a local object.
Maybe we need to:
a) Add the XML Schema related info from above, in the LCM chapter as a
small section which is referenced in the Submit and Update protocol sections
b) Add the SQL Schema related info from above, in a section in SQL
Schema section to with
But I am not sure that any change in Data Type is warranted in RIM. Lets
discuss tomorrow.
> 10 [MINOR] In 4.2.4 the path attribute is required to be generated on
> retrieval. But according to the production rules in 4.2.5 this cannot
> be set if there is no value for the code attribute (which is
> optional). Suggest that the specification text be amended such that
> the path attribute is not required to be set, OR a looser directive
> to include the path only if codes are available.
+1. Fixed in draft 03
Replaced Old: "A registry MUST set the path attribute for a
ClassificationNode when it is retrieved from the registry."
With New: "A registry MUST set the path attribute for any
ClassificationNode that has a non-null code attribute value, when the
ClassificationNode is retrieved from the registry."
>
>
> 11 [ADVISORY] In 5, "Responsible party information" might be a more
> apt designation, since we're concerned not just with the origin
> of an item but with identifying the owner and/or responsible party
> (person and/or organization--this may differ from the creator or
> source).
>
> "This chapter describes the classes that enable the description of
> the parties responsible for creating, publishing, or maintaining a
> RegistryObject or RepositoryItem."
OK. Will use above text as is in draft 03
>
>
> 12 [ADVISORY] In 5.3.5, the primaryContact for an Organization should
> reference a Person, as the contact need not be a registered User.
+1 since a Person can also be a User. Will fix in draft 03.
>
>
>
> 13 [ADVISORY] In 5.5.6, consider replacing stateOrProvince attribute
> with the more general attribute countrySubdivision (after ISO 3166-2).
I should definitely listen to you on this since you are a GIS man ;-)
But the ripple effect is cumbersome. There are bound to be
other little name differences with various standards and it is hard to
decide
where do we draw the line. Given the minor nature and lateness of the
release
I suggest No Change here.
> 14 [MINOR] In 5.6.5, shouldn't the number attribute at least be
> required? Currently _all_ attributes of TelephoneNumber are optional.
Yes this was a change in version 3 based upon the realization that
different use cases demanded different required fields and that it was
best to leave outside the spec. A Validation Service could enforce it in
a pluggable manner. Suggest no change.
> 15 [ADVISORY] In 7.2.4, a default value for notificationInterval is
> specified but this does not appear in rim.xsd:
>
> <attribute name="notificationInterval" type="duration"
> use="optional" default="P1D" />
+1 Fixed in draft 03
>
> 16 [ADVISORY] In 7.4.1, the type of the <any> attribute of
> QueryExpression should be anyType.
+1 Fixed in draft 03
>
>
> 17 [ADVISORY] In 7.7.3, amend the last sentence as follows: "The
> registry MUST include Identifiable or RegistryObject instances as Set
> elements depending upon the notificationOption specified for the
> Subscription."
+1. Fixed in draft 03 with minor verbage change from above as follows:
"The
registry MUST include ObjectRef or RegistryObject instances as Set
elements depending upon the notificationOption specified for the
Subscription."
Since the semantics require that set element be either ObjectRef or
RegistryObject instances.
>
>
> 18 [MINOR] In 8.1, since a registry is itself a service it would be
> sensible for Registry to extend Service instead of RegistryObject.
> This would then permit bindings to be associated with affiliated
> registries. Otherwise, how are they located?
That depends on how you look at it. One can veiw the Registry as having
one or more services or one can view it as a Service. I find teh first
one more flexible since it allows a Registry to offer any number of
services. Also one goal is to make the Federation Info Model classes be
as minimal as possible. Suggest No Change here.
>
>
>
> 19 [MAJOR] Section 9 refers to XACML 1.0, but XACML 2.0 is the current
> standard. Should this section be updated accordingly?
I debated this one long and hard in my own mind. XACML 2.0 does not add
that much to XACML 1.0 functionally. There are hardly any
implementations of XACML 2.0 available (a barrier for registry
implementors). All in all it seemed that being based on a stable XACML
1.0 was better than moving to XACML 2.0 now. Suggest we defer moving to
XACML 2.0 for version 4.
> 20 [MINOR] Section 9 says much about policy _definition_ but rather
> little about policy _enforcement_. It seems to imply the existence of
> an embedded policy engine that evaluates relevant policies and renders
> appropriate access control decisions. That is, a registry is assumed
> to function as both a Policy Enforcement Point (PEP) _and_ a Policy
> Decision Point (PDP). If this is the case, it should be made explicit
> in the preamble for section 9.
But is that an implementation detail? Do we need to be explicit about it
any more than we are?
If you feel it is important please suggest the precise change.
>
> Alternatively, these functions could be distributed. For example, a
> registry could invoke a remote PDP using SAML (AuthzDecisionQuery) and
> enforce the resulting authorization decision.
Indeed. That we did not specify the reliance on SAML
(AuthzDecisionQuery) was to keep the scope of the SAML 2 feature small
(limited to SSO) and go for the 80-20 rule.
Suggest No Change on this.
Thanks again for your thoughtful comments.
PS: Look forward to a solid turnout for our TC meeting tomorrow. See
you all then.
--
Regards,
Farrukh
