RE: RIMv2.6 Review, Sections 1-5

[<PMACIAS@lmi.org>]

Sorry, just realized my third comment was an ironically confusing.  Here's how it should have read:

"[Line 364] - Also, to clarify for future readers, it might be good to reference which version of the UML methodology is being applied.  UML may not change drastically from version to version, but for a document that may be referenced by future generations of registry developers such information may be useful. ;-)"

> -----Original Message-----
> From: MACIAS, Paul 
> Sent: Friday, August 20, 2004 10:22 AM
> To: ebXML Regrep (ebXML Regrep)
> Subject: RIMv2.6 Review, Sections 1-5
> 
> 
> OK. My head is starting to hurt, so while I take a break I'll 
> forward on the comments I have so far on the RIM.  Here's 
> what I've got up through Section 5.
> 
> Paul
> 
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 
> >>OASIS/ebXML Registry Information Model v2.6<<
> 
> [General Comment] - I'd like to suggest a reorganization of 
> Section 4's sub-sections.  Perhaps alphabetic, or maybe some 
> relation to how the items are discussed in detail later.  
> Right now the sub-sections seem to jump around.  For 
> instance, group sections that are later detailed in Section 5 
> (i.e. 4.3, 4.13, and 4.14) together and ahead of items 
> detailed in Section 7 (i.e. 4.8 and 4.9).  This may be more 
> work than it's worth depending on any references that point 
> to these sub-sections, but reordering the sections based on 
> one of the above schemes seems more logical to me.
> 
> [General Comment] - Is our convention to spell out acronyms 
> at their first use?  See line 364 "UML", 367 "DTD".  I 
> understand that not having a grasp of these concepts makes 
> understanding the spec difficult, but just a matter of convention.
> 
> [Line 364] - Also, for clarity in for future readers, it 
> might be good to reference which version of the UML 
> methodology is being applied.  UML may not change drastically 
> from version to version, but for a document that may be 
> referenced for generations such information may be useful. ;-)
> 
> [412] - Header number appears italicized.
> 
> [461] - Figure 1 needs some touchups. Some of the labels are 
> hard to read given where they are positioned.  Most notably, 
> the text for the relationships right above the "RegistryObject" class.
> 
> [583] - "Person" class needs to be added to Figure 2 as a 
> subclass of "RegistryObject" and super class of "User".
> 
> [583 & 669] - Figure 2 shows "Service" as a direct subclass 
> of "RegistryEntry", while line 669 indicates "Service" as a 
> direct known subclass to "RegistryObject".
> 
> [628 & 710] - Identifies a default value for the "home" 
> attribute that is not represented in the attribute summaries 
> at lines 615 & 679 respectively.
> 
> [655] - The heading for the attribute summary appears wrong.  
> Should be "5.6.1".  Remove the last ".1".
> 
> [655] - Attribute "lang" has the data type "language".  Yet I 
> didn't see an explicit instruction that those data types not 
> defined in the chart at line 602 are the built-in W3C Schema 
> data types.  Developers would hopefully figure that out, but 
> I wanted to bring the point up in case we want to spell it out.
> 
> [669] - List of known subclasses runs together "Service, 
> ServiceBinding, SpecificationLink" via the shared underline.
> 
> [669] - "RegistryObject" does not list "Subscription" as a 
> direct known subclass.
> 
> [679] - Very minor, but the "International-String" data type 
> is bugging me.  I understand that the point is to make clear 
> that there isn't white space between the "International" and 
> "String".  But there isn't a hyphen either.  Can the hyphen 
> go?  It would make me feel better. :-)
> 
> [769] - The header number "5.8" appears diminutive compared 
> to similar headers of this level.
> 
> [789] - List of known subclasses runs together 
> "RegistryPackage, Service" via the shared underline.
> 
> [789] - "RegistryEntry" does not list "Federation" or 
> "Registry" as direct known subclasses.
> 
> [933] - The "Person" class should identify "User" as a known subclass.
> 
> [936, 940, and 949] - Attribute summary at line 936 lists 
> "address" and telephoneNumbers as not required.  Yet the 
> descriptions for each indicates that these attributes are a "MUST".
> 
> [936] - "Person" has "url" attribute. Can't this be handle as 
> an association to "ExternalLink"?  If not, do we need to add 
> "url" as an attribute to "Organization"?
> 
> [956] - Shouldn't "RegistryObject" be listed as a super class 
> for "User"?
> 
> [980 & 997] - Does the "MUST" requirement for 
> "telephoneNumbers" at line 997, mean that the attribute 
> requirement in the summary table of line 980 should be "Yes"?
> 
> [936] - "TelephoneNumber" has "url" attribute. Can't this be 
> handle as an association to "ExternalLink"?
>