OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

regrep message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [regrep] [spec comments] Richard Martell on version 2.6 specs

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

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: 
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.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)

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">
<element ref="tns:Value" minOccurs="0" maxOccurs="unbounded" />
<attribute name="name" type="tns:LongName" use="required"/>
<attribute name="slotType" type="tns:LongName" use="optional"/>

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"

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 (
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, 
add a new extrinsic object type for geometry objects. Geometry extends 
ExtrinsicObject to add the dimension, geometryType, and srid attributes.

<complexType name="GeometryType">
<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"/>
<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:

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).

northlimit=49.8951; eastlimit=-122.2606; southlimit=48.7801; 

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

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>


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]