Below is a copy/paste in plain text of the Galdos comments. I send it in
plain text form so we can comment on it via email on this thread. Thanks.
<Richard Martell Comments>
A Draft ebRIM 2.6 specification
<http://www.oasis-open.org/committees/download.php/8475/ebRIM-2.6.doc>
1.[ADVISORY] In the interest of conceptual clarity, consider replacing
ExtrinsicObject with RepositoryItem, which is then understood to provide
representation metadata about some resource—we’ve seen many glazed and
rolling eyeballs when discussing “extrinsic” objects ;-). A repository
item is then bound to one or more representations.
2.[ADVISORY] Consider using the standard OCL collection types (Sequence,
Set, Bag) for operation return types e.g. getAuditTrail:
Sequence<AuditableEvent>
3.[MAJOR] RegistryObject.externalIdentifers [sic] should have datatype
Collection of ExternalIdentifier (sec. 5.7)
4.[MAJOR] RegistryObject.status should have datatype ObjectRef, since it
is a reference to a ClassificationNode (like objectType)
5.[MAJOR] RegistryEntry.stability should have datatype ObjectRef, since
it is a reference to a ClassificationNode (sec. 5.9)
6.[MAJOR] Missing description of RegistryEntry.userVersion (sec. 5.9.3?)
7.[ADVISORY] It’s not clear why the Person class was introduced—are all
users necessarily persons? Cannot system entities also be registered users?
8.[MAJOR] Person.addresses are required according to 5.15.1 (1..*), but
not so in the attribute summary table
9.[MINOR] Organization.address should be Organization.addresses in in
5.17.1, since it is a collection type
10.[MAJOR] Missing descriptions for
Association.isConfirmedBySourceOwner,
Association.isConfirmedByTargetOwner in sec. 6.6
11.[MAJOR] ClassificationScheme.stability should have datatype
ObjectRef, since it is a reference to a registered ClassificationNode
(sec. 7.1.1)
12.[MAJOR] AuditableEvent.eventType should have datatype ObjectRef,
since it is a reference to a registered ClassificationNode in the
EventType scheme.
13.[MINOR] Subscription.startDate and Subscription.endDate are defined
as time-points (combined date and time), not dates. These attributes
should be renamed as startTime and endTime, or redefined as date types.
14.[MAJOR] NotifyAction.notificationOption should have datatype
ObjectRef, since it is a reference to a registered ClassificationNode in
the NotificationOptionType scheme (sec. 9.5.1)
15.[MAJOR] There are no subclasses of AdhocQuery defined for use as
selectors (i.e., value of Subscription.selector)
B Draft XML Schema (rim.xsd)
<http://cvs.sourceforge.net/viewcvs.py/*checkout*/ebxmlrr/ebxmlrr-spec/misc/3.0/schema/rim.xsd?rev=1.9>
1.[MINOR] Inconsistent ebRIM-XML mappings, e.g. i) Slot/ValueList/Value
vs. ii) InternationalString/LocalizedString, where the localizedStrings
accessor from ebRIM is dropped.
Either approach is OK, but a consistent mapping should be adopted. We
favour a “high-fidelity” mapping that includes the role names as in i)
above, but most of rim.xsd omits these. So perhaps Slot should be
redefined as follows:
<complexType name="SlotType1">
<sequence>
<element ref="tns:Value" minOccurs="0" maxOccurs="unbounded" />
</sequence>
<attribute name="name" type="tns:LongName" use="required"/>
<attribute name="slotType" type="tns:LongName" use="optional"/>
</complexType>
2.[ADVISORY] We’d like to see LongName have maxLength=256, and
FreeFormText have maxLength=1024 (or no length constraint, to
accommodate reasonably informative abstracts or summaries—1024 chars is
only about 150 words!)
3.[MAJOR] The ObjectRef/@createReplica attribute is not defined in ebRIM
4.[ADVISORY] ebRIM-XML mapping: Identifiable/Slot is missing slots
accessor (but see B.1 above)
5.[MAJOR] RegistryObject/@lid is not defined in ebRIM
6.[MAJOR] RegistryObject/@objectType has type ObjectRef in ebRIM, not
xsd:anyURI as in the schema. This inconsistency should be resolved
either by (i) amending the model to replace ObjectRef with anyURI (or
referenceURI?), or (ii) declaring objectType as an element rather than
an attribute:
<element name="objectType" type="tns:ObjectRefType" />.
NOTE: Option (ii) would appear to imply deprecation of @objectType
7.[MINOR] RegistryObjectList should be renamed as IdentifiableList, or
the content model should be modified to include RegistryObject
instances, not Identifiable instances
8.[MAJOR] RegistryEntry/@userVersion is missing from type definition
9.[MAJOR] the two Association/isConfirmedBy... attributes defined in the
spec are missing
10.[MINOR] Change AuditableEvent/affectedObject to affectedObjects to
reflect collection semantics from ebRIM spec
11.[MINOR] ExternalIdentifer/@registryObject is optional, but required
in ebRIM spec
12.[MAJOR] Organization/Address is not a collection of PostalAddress
(see ebRIM 5.17.1); this could be handled like email addresses:
<element ref="tns:Address" minOccurs="0" maxOccurs="unbounded" />
OR define Organization/addresses as a list of PostalAddress elements
13[MAJOR] EmailAddress/@type is String32 type, but ObjectRef in spec
(sec. 5.21.3). There is no mention of slot usage in the spec.
14[MINOR] PostalAddress/@stateOrProvince is PostalAddress.state in spec
(sec. 5.19.1); or perhaps call it countrySubdivision to be totally
generic (after ISO 3166-2).
15[MINOR] VersionInfo/@versionName definition doesn't match spec (sec. 5.8):
<attribute name="versionName" type="tns:String8" use="optional"
default="1.1"/>
16[MINOR] ServiceBinding/@service not defined in spec (sec. 8.2.1)
17[MINOR] SpecificationLink/@serviceBinding not defined in spec (sec. 8.3.1)
18[MAJOR] TelephoneNumber/phoneType is String32 type, but ObjectRef in
spec (sec. 5.20.1). TelephoneNumber, FaxNumber, MobileTelephoneNumber,
PagerNumber elements appear to supplant the PhoneType scheme—is this
intended? If so, they should belong to the same substitution group (with
tns:TelephoneNumber as head)
19[MINOR] Federation/@replicationSyncLatency is required in the schema,
but not in spec (10.2.1.1)
20[MINOR] at least one Subscription/Action must appear, but the
collection may be empty according to the spec (sec. 9.2.1):
<element ref="tns:Action" minOccurs="0" maxOccurs="unbounded"/>
C Proposed ebRIM enhancements
1.Spatial references using geographic coordinates
add associationType="hasGeometry" to relate a source RegistryObject to a
target Geometry object. The Association/Name element may be used to
further characterize the spatial relationship (e.g. geographicExtent,
location)
add a new extrinsic object type for geometry objects. Geometry extends
ExtrinsicObject to add the dimension, geometryType, and srid attributes.
<complexType name="GeometryType">
<complexContent>
<extension base="tns:ExtrinsicObjectType">
<attribute name="dimension" type="integer" use="optional"/>
<attribute name="geometryType" type="anyURI" use="required"/>
<attribute name="srid" type="anyURI" use="required"/>
</extension>
</complexContent>
</complexType>
<element name="Geometry" type="tns:GeometryType"
substitutionGroup="tns:Identifiable" />
Alternatively, just declare a global Geometry element like so:
<element name="Geometry" type="tns:ExtrinsicObjectType"
substitutionGroup="tns:Identifiable" />
And use the following slots on an ExtrinsicObject, where Slot/@name is:
"http://www.isotc211.org/19125-1/Geometry.Dimension"
"http://www.isotc211.org/19125-1/Geometry.GeometryType"
"http://www.isotc211.org/19125-1/Geometry.SRID"
a registry object (with or without an associated geometry) may include a
special slot to specify a simple bounding box that provides a rough
approximation of the geographic extent (this may be calculated from an
associated geometry object if one exists).
<Slot
name="http://purl.org/dc/terms/spatial"
slotType="http://purl.org/dc/terms/Box">
<Value>
northlimit=49.8951; eastlimit=-122.2606; southlimit=48.7801;
westlimit=-124.1234
</Value>
</Slot>
The bounding box is expressed using the DCSV notation of the DCMI Box
encoding scheme <http://dublincore.org/documents/dcmi-box/>.
2.Spatial references using geographic identifiers
this entails classifying a RegistryObject instance according to some
taxonomy of geographic identifiers (e.g. ISO 3166-2) or a geocoding
scheme (e.g. UN/LOCODE). Doing this doesn’t require anything beyond
registering a suitable scheme and classifying content accordingly.
the Classification/Name element may be used to qualify the semantics of
the classification (e.g. coverage, location, service area).
3.RIM modules
these are registry packages used to define a cohesive set of
application-specific extensions that can be registered and discovered
(i.e., a sort of registry expansion pack)
<element name="Module" type="tns:RegistryPackageType"
substitutionGroup="tns:Identifiable" />
a module may introduce the following kinds of extension objects
ClassificationScheme
ClassificationNode (including new objectType, associationType nodes)
AdhocQuery (convenient parameterized queries)
ExtrinsicObject (i.e., repository items such as schemas, XSLT scripts,
user documentation, etc.)
new Slots
NOTE: we have been using these to define specialized geospatial
extensions (e.g., to support geodesy, remote sensing, cadastre, and
cartography applications), but the basic concept can be widely applied.
</Richard Martell Comments>
--
Regards,
Farrukh
