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