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

[Farrukh Najmi <Farrukh.Najmi@Sun.COM>]

First a very warm thank you to Richard for the rich and thorough set of 
comments he has provided on the 2.6 specs.
Most of his observations are spot on and I see us fixing them without 
any issues. Some comments require some additional
information from Richard.

What follows is my initial response to his comments. I am copying 
Richard so he can be part of the dialog. Thanks.

Farrukh Najmi wrote:

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

An ExtrinsicObject is metadata which MAY or MAY NOT have a Repository 
Item (which is content) associated with it.
Calling ExtrinsicObject RepositoryItem is confusing too distinct things. 
Suggest we make no change here.

> 2.[ADVISORY] Consider using the standard OCL collection types 
> (Sequence, Set, Bag) for operation return types e.g. getAuditTrail: 
> Sequence<AuditableEvent>

This seems like a good suggestion. I am inclined to accept it and make 
appropriate changes  in  RIM 2.7.

> 3.[MAJOR] RegistryObject.externalIdentifers [sic] should have datatype 
> Collection of ExternalIdentifier (sec. 5.7)

Typo will be fixed in RIM 2.7.

> 4.[MAJOR] RegistryObject.status should have datatype ObjectRef, since 
> it is a reference to a ClassificationNode (like objectType)

Will be fixed in RIM 2.7.

> 5.[MAJOR] RegistryEntry.stability should have datatype ObjectRef, 
> since it is a reference to a ClassificationNode (sec. 5.9)

Will be fixed in RIM 2.7.

> 6.[MAJOR] Missing description of RegistryEntry.userVersion (sec. 5.9.3?)

user/major/MinorVersion have been replaced by RegistryObject.versionInfo 
and ExtrinsicObject.contentVersionInfo.
No change.

> 7.[ADVISORY] It’s not clear why the Person class was introduced—are 
> all users necessarily persons? Cannot system entities also be 
> registered users?

Person class was introduced to support a very common need for a standard 
RIM class to represent a Person. There was no functional change to User 
class  other than factoring its attributes to new Person class.

Registered users are anticipated to be persons. However, we see the need 
for a registered Service to play same role as registered user in terms 
of making secure requests to the registry. In such cases we should use a 
Service instance that has an associated dsig. This needed to be 
clarified in the specs.

>
> 8.[MAJOR] Person.addresses are required according to 5.15.1 (1..*), 
> but not so in the attribute summary table

It should be optional.
Will fix by removing statement in 5.15.1:

"A Person MUST have at least one postal address."

>
> 9.[MINOR] Organization.address should be Organization.addresses in in 
> 5.17.1, since it is a collection type

Agreed. Will fix in 2.7

> 10.[MAJOR] Missing descriptions for 
> Association.isConfirmedBySourceOwner, 
> Association.isConfirmedByTargetOwner in sec. 6.6

These attributes have been dropped in favor of using reference access 
control policies. Will fix section 6.6.1 to remove these lingering 
attributes.

> 11.[MAJOR] ClassificationScheme.stability should have datatype 
> ObjectRef, since it is a reference to a registered ClassificationNode 
> (sec. 7.1.1)

Agreed. Will fix in 2.7.

>
> 12.[MAJOR] AuditableEvent.eventType should have datatype ObjectRef, 
> since it is a reference to a registered ClassificationNode in the 
> EventType scheme.

Agreed. Will fix in 2.7.

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

Agreed. Should be startTime and endTime. Will fix in 2.7.

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

Agreed. Will fix in 2.7.

> 15.[MAJOR] There are no subclasses of AdhocQuery defined for use as 
> selectors (i.e., value of Subscription.selector)

Fix datatype of Selector attribute to be ObjectRef.
Will fix in 2.7.

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

Need to minimize change in rim.xsd. Richard do you have a minimal 
suggestion that could address this concern?

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

Agreed. Will fix in 2.7.

> 3.[MAJOR] The ObjectRef/@createReplica attribute is not defined in ebRIM

Agreed. Will fix in 2.7.

> 4.[ADVISORY] ebRIM-XML mapping: Identifiable/Slot is missing slots 
> accessor (but see B.1 above)

Richard, can you give an example of what you think it should look like? 
I am confused.

> 5.[MAJOR] RegistryObject/@lid is not defined in ebRIM

Agreed. Will fix in 2.7.

> 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
>
Option (ii) is too disruptive and I would like to propose we eliminate 
that as an option.
Suggest replace ObjectRef datatype with referenceURI datatype in RIM 2.7

> 7.[MINOR] RegistryObjectList should be renamed as IdentifiableList, or 
> the content model should be modified to include RegistryObject 
> instances, not Identifiable instances

This was left to minimize impact to existing implementations. However, I 
see the point that this is misleading.
What do other TC members think?

> 8.[MAJOR] RegistryEntry/@userVersion is missing from type definition

This is no longer part of RIM. No change.

> 9.[MAJOR] the two Association/isConfirmedBy... attributes defined in 
> the spec are missing

This is no longer part of RIM. No change.

> 10.[MINOR] Change AuditableEvent/affectedObject to affectedObjects to 
> reflect collection semantics from ebRIM spec

Agreed. Will fix in 2.7.

> 11.[MINOR] ExternalIdentifer/@registryObject is optional, but required 
> in ebRIM spec

Agreed. Will fix in 2.7.

> 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

Agreed. Will fix in 2.7.

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

I think we should make the type attribute of EmailAddress a canonical Slot.
Agreed to mention slot usage in spec. Will fix in 2.7.

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

Suggest changing PostalAddress.state to PostalAddress.stateOrProvince to 
minimize impact to existing implementations.
Will fix in 2.7.

> 15[MINOR] VersionInfo/@versionName definition doesn't match spec (sec. 
> 5.8):
>
> <attribute name="versionName" type="tns:String8" use="optional"
> default="1.1"/>

Agreed. Will fix in 2.7.

>
> 16[MINOR] ServiceBinding/@service not defined in spec (sec. 8.2.1)

Agreed. Will fix in 2.7.

> 17[MINOR] SpecificationLink/@serviceBinding not defined in spec (sec. 
> 8.3.1)

Agreed. Will fix in 2.7.

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

Suggest we remove phoneType and replace with a canonical Slot. Suggest 
we remove FaxNumber, MobileTelephoneNumber, PagerNumber elements as they 
do conflict with phoneType and could be a can of worms.

> 19[MINOR] Federation/@replicationSyncLatency is required in the 
> schema, but not in spec (10.2.1.1)

Agreed. Will fix in 2.7.

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

Fix spec to allow ZERO actions.
Will fix in 2.7.

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

Why not have a hierarchy of associationType as follows:

AssociationTypeScheme
    hasGeometery
       hasLocation
       hasGeographicExtent

> add a new extrinsic object type for geometry objects. Geometry extends 
> ExtrinsicObject to add the dimension, geometryType, and srid attributes.

Why extend ExtrinsicObject instead of RegistryObject? Can you explain.

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

Why is a dimension an integer instead of float.
Also where are the units of the dimension.
Maybe there needs to a Measurement class with unitOfMeasure (e.g. 
Kilometer)
and value (10.5). This class could be the domain of dimension attribute?

Also what is SRID?

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

I think you present some fascinating ideas for extending RIM to provide 
generic support for GeoSpatial description.
I agree that there is a need to add such metadata support in RIM. What 
is the likelihood that you could work with
the OpenGIS community and provide us with a proposal for RIM extensions 
in this area?

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

I am not clear on why a RegistryPackage in its current form is not 
sufficient for addressing above use case. What does the Module type add 
to the picture?

>
> </Richard Martell Comments>
>
Thanks again Richard for your substantial comments. We very much wish to 
address them to your satisfaction and hope to work through these and 
other issues with you. BTW given the level of your involvement in ebXML 
Registry standard and the depth of your understanding would you consider 
actually joining the regrep TC  and working more directly with us in 
getting version 3.0 ready for submission to OASIS standardization process.

-- 
Regards,
Farrukh