[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
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]