RIM Issue: Is the ExternalLink Class really necessary?

[Len Gallagher <LGallagher@nist.gov>]

ebXML regrep,

Here's another issue I'd like to see added to the Regrep Issues List for
consideration in Phase 2 of the specification.

I think it is possible to delete the ExternalLink class from the RIM
specification without losing any information. Instead, there would be a
considerable increase in simplicity.

Right now, in RIM v0.60, we have:

1) ExternalLink is a subtype of IntrinsicObject, which in turn is a subtype
of RegistryEntry.  Also ExtrinsicObject in a subtype of RegistryEntry.
(cf Figure 2, RIM line 356, page 12).

2) The attributes of ExternalLink, in addition to those of RegistryEntry, are:

   - linkedObjects  (The collection of objects that use this external link)

   - externalURI    (The URI to the external content)

3) The attributes of ExtrinsicObject, in addition to those of
RegistryEntry, are:

   - contentURI  (The URI to the content catalogued by this ExtrinsicObject)

   - mimeType    (The mime type associated with the content)

   - isOpaque    (Determines whether the contentis readable by the registry)

4) Every RegistryEntry instance has an attribute as follows:

   - associatedObjects (the collection of objects associated with this object)


PROPOSAL

Why not treat every ExternalLink instance as an ExtrinsicObject instance? 

It certainly wouldn't hurt an ExternalLink to assume the two new attributes
for mimeType and isOpaque, since both of those attributes make as much
sense for objects stored outside of the registry as they do for objects
stored in the Registry.

The linkedObjects attribute for ExternalLink really adds nothing beyond the
Source and Target associations already defined for RegistryEntry instances. 

The only impediment to making this simplification, is that the RIM
specification requires the contentURI of an ExtrinsicObject to identify a
repository item in the same Registry as the ExtrinsicObject instance. If
this requirement were relaxed so that a contentURI could point ouside of
the Registry, then the contentURI attribute of ExtrinsicObject could
subsume the semantics of the externalURI attribute of ExternalLink. 

Since the contentURI is guaranteed to be resolvable by a standard browser,
there's no reason it can't point outside the Registry. For an object
outside of the Registry, the resolvable guarantee is made by the Submitting
Organization rather than by the Registration Authority.


ADVANTAGE

With the above proposal we could delete the ExternalLink class in RIM with
no loss of Registry information, thereby simplifying the model and making
it easier to comprehend. This would also simplify the Registry Services
currently defined to deal with ExternalLinks.


PERSONAL NOTE

Some of you know that I favor the existence of a class in the information
model that would play the same role as that described in RIM for
ExternalLink. But the class I envision would not be a subtype of
RegistryEntry and would not have any of the required metadata of a
RegistryEntry instance. This class would be a simple entity class that is
dependent on the RegistryEntry class, i.e. a one-to-many mapping from
RegistryEntry. Its instances would not have an independent object identity;
instead, they'd just be simple values supplied by the Submitting
Organization.  If such a class has value, we can add it later, either as a
special kind of Slot, or as a new simple entity class. For now, I favor
folding the existing ExternalLink class back into RegistryEntry, since it's
semantics are just those of a special kind of registry entry.



**************************************************************
Len Gallagher                             LGallagher@nist.gov
NIST                                      Work: 301-975-3251
Bldg 820  Room 562                        Home: 301-424-1928
Gaithersburg, MD 20899-8970 USA           Fax: 301-948-6213
**************************************************************