Re: [regrep] [regrep - RIM draft 02 comment] Compendium

[Farrukh Najmi <Farrukh.Najmi@Sun.COM>]

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