[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: Review of latest ebRIM schema (v2.5)
Richard Martell wrote: >Greetings, > > >We've been using the ebRIM schema for more than a year now within the >OpenGIS consortium <http://www.opengis.org> to implement catalogue >services for the geospatial domain (but we extend the model and employ >different interfaces). Farrukh Najmi attended one of our TC meetings >earlier in the year where he became acquainted with some of our >registry-related activities. > >I recently reviewed the latest ebRIM v2.5 spec and schema available >from the ebxmlrr CVS repository (dated 2003/06/04). My comments are >included below for your consideration. > > >1 RegistryObject.id is required (ebRIM.doc, 7.5.2), but optional > in the schema. > > <attribute name="id" type="anyURI" use="required"/> > > NOTE: the default value of the use attribute is "optional". > > This (and several others) below are a very good catches. Disposition: Acknowledged as bug. Will be fixed in the next version of spec distribution (version 2.6). > >2 RegistryObject.objectType is required (ebRIM.doc 7.5.2), but > optional in the scheam. > > <attribute name="objectType" type="anyURI" use="required"/> > This is intentional because it is required on READ and ignored on WRITE. Disposition: We will clarify in next version of ebRIM. > >3 RegistryObject.status is also required (ebRIM.doc, 7.5.2) > > <attribute name="status" use="required"> > <!-- anonymous simpleType definition --> > </attribute> > This is intentional because it is required on READ and ignored on WRITE. Disposition: We will clarify in next version of ebRIM. > >4 RegistryEntry.stability is an extensible ClassificationScheme > (ebRIM.doc, 7.6.5.1); this implies it should be handled in the > same manner as RegistryObject.objectType, Association.associationType, > etc. (i.e., as a URI reference to a ClassificationNode). However, the > definition of an anonymous enumerated type for the stability attribute > in not consistent with such usage. > We debated this one. The argument for two different ways was to use ClassificationScheme if extensibility was required by end-user and to use spec defined constant strings if user extensibility was not needed. Do you think consistency in either case is important? Let us know how you feel on this issue given our rationale. Choices are: a) Use spec defined constants and fix ebRIM to not say it is defined as an extensible ClassificationScheme b) Define as an extensible canonical ClassificationScheme Disposition: Acknowledge as Bug. Open Issue on how best to resolve. > >5 ExternalIdentifier.registryObject is required (ebRIM.doc, 7.10.1) > > <attribute name="registryObject" use="required" type="anyURI"/> > The rationale is that if an ExternalIdentifier is composed within a RegistryObject then the registryObject attribute has an implied value and is therefor optional. Given this rationale how do reviewers think we should resolve this issue? Choices are: a) Leave as is b) Make registryObject attribute required in XML Schema Disposition: open issue > >6 Service.serviceBindings is mandatory in section 10.1.1, but optional > in the schema. > > There is a distinction between null value for a collection attribute and a non-null but empty collection. A Service should be allowed to have 0 bindings. ebRIM will be fixed to say that Collection attribute serviceBindings is required but may be empty. Let us know if this response is not satisfactory. Disposition: open issue > >7 ServiceBindings.specificationLinks is mandatory in section 10.2.1, > but optional in the schema. > Same as 6. > >8 AuditableEvent.eventType is of type LongName. A comment in the schema > suggests this is an extensible list, so it should probably be handled > as a URI reference to a term in some taxonomy. > Similar issue and response as (4). > >9 Subscription employs an anonymous type definition, but it appears > exceptional in this respect; perhaps it should be promoted to a > global type definition. > Disposition: Request For Enhancement. We agree to the value of consistency and will fix this in the next version. > >10 TelephoneNumber.url is not documented in ebRIM.doc, 7.15. > We find it documented in table 7.15.1 but missing a detailed description. Disposition: Acknowledged as bug. Will fix in next version. > >11 Association.isConfirmedBy[Source|Target]Owner properties do not > have the default values indicated in 8.9.1: > > <attribute name="isConfirmedBySourceOwner" default="false" > type="boolean"/> > <attribute name="isConfirmedByTargetOwner" default="false" > type="boolean"/> > Disposition: Acknowledged as bug. Will fix in next version. > >12 Perhaps Registry might extend Service rather than RegistryEntry, > as specified in 12.1.1. The Registry type definition includes service > capabilities that supplement the service bindings. > Interesting idea. This one requires some thought. Which is better modeling? a) Registry IS A Service b) Registry HAS A Service We would like to hear thoughts of other reviewers on this. Disposition: open issue > >13 RegistryObject and RegistryEntry are abstract base classes in the > RIM. You might consider reflecting this in the schema and using > substitution groups to force substitution where appropriate (e.g. as > children of RegistryObjectList) > > <element name="RegistryObject" type="tns:RegistryObjectType" > abstract="true"/> > <element name="RegistryEntry" type="tns:RegistryEntryType" > abstract="true" substitutionGroup="tns:RegistryObject"/> > We will look into this suggestion. Disposition: Open issue > >14 Consider adding substitution group assignments to reflect the > inheritance hierarchy. Doing this offers an alternative to using > the xsi:type construction in instance documents. > e.g. > > <rim:RegistryObjectList> > <rim:ClassificationScheme > id="urn:uuid:6902675f-2f18-44b8-888b-c91db8b96b4d" > isInternal="true" nodeType="UniqueCode" > objectType="urn:uuid:c8b3dd77-9290-4fa3-a01a-94514d8f89ee" > status="Submitted"> > <-- other properties and component nodes here --> > </rim:ClassificationScheme> > </rim:RegistryObjectList> > We will look into this suggestion. Disposition: Open issue > >15 As an alternative mechanism for context-sensitive classification, > consider attaching a Slot to a Classification instance to provide a > role name (i.e. context) for the classification; this seems a bit > more straightforward than employing a meta-classification. For > example, the ACME-->Japan classification might be qualified with a > Slot as follows (using XLink semantics): > >Slot.name=xlink:role >Slot.values=http://schemas.opengis.net/gml/3.0.0/base/feature.xsd#location > We feel it is more extensible to use Classification rather than Slots for giving context to Classifications. Note that this section is non-normative and there is nothing preventing someone from using Slot as you suggested. Disposition: Not an issue -- Farrukh
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]