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