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

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

Richard Martell wrote:

>Farrukh Najmi wrote:
>  
>
>>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.
>>    
>>
>
>
>Now I'm confused by the prospect of a missing repository item :-(
>
>Terminology aside (we don't have strong feelings about this, hence the
>"advisory" label--we tend to speak of a RepositoryItem and its
>Representation), the ExtrinsicObject.mimeType property always has a
>value ("application/octet-stream" by default) that indicates the content
>type of an associated representation. If this does not characterize an
>existing repository item, what does it mean?
>
>Your comment suggests that ExtrinsicObject.mimeType can be absent (i.e.
>_no_ default value specified in the spec and schema). If no content
>type is specified then presumably no additional information is
>available, thus yielding a poor man's metadata record rather than a
>summary of some extrinsic resource.
>  
>
I think you sum it up well. ExtrinsicObject without repository item is 
heavily used
as a "poor man's metadata record" that can be user defined. Lets us 
leave this issue
with no change.

>
>  
>
>>>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.
>>
>>    
>>
>
>
>Hmm, we didn't see ExtrinsicObject.contentVersionInfo documented
>anywhere in the draft spec or schema. Granted, a user-specified version
>number can be easily handled as a slot.
>  
>
This is another bug in version 2.6 that will be fixed in 2.7. It is 
referenced in Versioning
section in RS 2.6 though.

>
>  
>
>>>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.
>>    
>>
>
>
>Is there a default access control policy governing extramural
>associations?
>e.g., "Disallowed unless expressly permitted", or the converse
>"Allowed unless expressly prohibited"
>  
>
Yes the default access control policy at:

http://cvs.sourceforge.net/viewcvs.py/ebxmlrr/omar/misc/samples/acp/defaultACP.xml?rev=1.4&view=auto

allows any one to reference unless expressly prohibited.

BTW I neglected to update the defaultACP listing in RIM 2.6 to show this 
latest version. This is marked as another bug to be fixed in 2.7.

>How are the default ACPs published? Associated with the appropriate
>ClassificationNode in the objectType scheme?
>  
>
The defaultACP is implictly associated with all objects.
A custom ACP may be associated with an object using an Association 
between the object and the ACP
using the canonical AccessControlPolicyFor associationType. This is 
defined in the RIM chapter on Access Control.

>
>  
>
>>>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?
>>
>>    
>>
>
>
>This refers to an inconsistency in how ebRIM attributes are represented.
>Suppose we have a simple model like the following:
>
>[Alpha] -------> [Beta] 0..*
>           betas
>
>where Alpha.betas has type Set<Beta>. A "literal" XML encoding would
>look something like this:
>
><Alpha>
>  <betas>
>    <Beta></Beta>
>  </betas>
></Alpha>
>
>Whereas a slightly more compact representation prunes the "betas" node:
>
><Alpha>
>  <Beta></Beta>
></Alpha>
>
>The rim.xsd schema tends to favour the "compact" style, except for the
>case of slots where we see Slot.values expressed as Slot/ValueList.
>
>A minor issue to be sure--the least-effort solution is to do nothing ;-)
>  
>
I would favour leaving this minor inconsistency unchanged due to the 
disruption that
the change would bring.

>Just curious--under the ISO umbrella is the UML likely to become
>normative? We've found this to be the case as OGC specifications are
>"promoted" to TC 211.
>  
>
I am a big fan of UML but I am not sure what you mean by making it 
normative.
How would that impact our specs? Suggest no change here.

>
>  
>
>>>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.
>>
>>    
>>
>
>
>See above. If the compact representation is preferred, ignore this
>suggestion.
>  
>
Suggest no change here to minimize impact.

>
>  
>
>>>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?
>>
>>    
>>
>
>
>Hmm, this should probably be left intact. And it's not really misleading
>if Identifiable is understood to constitute a "brief" view of
>RegistryObject.
>  
>
Agreed. Leave this unchanged.

>
>  
>
>>>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
>>
>>    
>>
>
>
>Yes, introducing refinements as association subtypes is a reasonable
>approach (e.g., this is done in Dublin Core, where "spatial" is a
>subProperty of "coverage").
>
>hasGeometry
>  hasGeographicExtent
>  hasPosition
>  hasLocation
>
>
>  
>
>>>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.
>>
>>    
>>
>
>
>ExtrinsicObject seems to offer the best fit, since the actual
>representation of the geometry object reflects one of three content
>types:
>
>application/xml           - Geometry Markup Language (GML, ISO 19136)
>text/plain                - Well-known Text (ISO 19125-1, 6.2)
>application/octet-stream  - Well-known Binary (ISO 19125-1, 6.3)
>
>The coordinate values are conveyed by the repository item; this
>is a pretty straightforward approach we have implemented.
>
>
>  
>
>>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?
>>
>>    
>>
>
>
>These definitions come from ISO 19125-1:2003 ("Geographic information —
>Simple feature access — Part 1: Common architecture")
>
>dimension
>---------
>The inherent dimension of this geometric object, which must be less than
>or equal to the coordinate dimension. This specification is restricted
>to geometries in 2-dimensional coordinate space.
>
>e.g., dim=0 for Point or MultiPoint, dim=1 for a LineString, etc.
>
>geometryType
>------------
>The name of the instantiable subtype of Geometry of which this
>geometric object is an instance.
>
>e.g., Point, LineString, Polygon, MultiPoint, etc.
>
>srid
>----
>the Spatial Reference System ID for this geometric object.
>
>e.g. identifies the relevant coordinate reference system
>
>
>  
>
>>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?
>>
>>    
>>
>
>
>We are OGC members already engaged in developing a catalogue
>specification based on ebRIM 2.5 (but accessed using OGC catalogue
>interfaces, not ebRS). If some of our RIM extensions found their
>way into the OASIS spec, that would be cool--and our spec would become
>smaller to boot ;-)
>
>Of course, geometry objects by themselves aren't very useful without
>support for spatial queries. Adding support for this would probably
>require an extension to the ebRS filter query grammar; happily, the OGC
>has already defined an XML syntax for spatial operators that could
>probably be incorporated without too much fuss (and ISO 19125-2 defines
>an SQL syntax). Anyway, a topic for future discussion if this seems a
>reasonable course of action.
>  
>
My personal view is that the RS Filter Query is unwieldy and difficult 
to maintain
as RIM changes. I would like to hold the line on it and replace it with 
something like
XQuery in version 4. In my own apps I tend to use the optional SQL Query 
exclusively which is
much more easier to use.

If you think there is value to extending RIM for spatial queries and 
Geometry (I think so)
then would it be possible for you to provide a rim.xsd patch based on 
the version at:

http://cvs.sourceforge.net/viewcvs.py/ebxmlrr/ebxmlrr-spec/misc/3.0/schema/rim.xsd?rev=1.10&view=log

with the suggested changes and adequate comments. A universal diff 
format patch would be ideal. See:

http://ebxmlrr.sourceforge.net/3.0/PatchSubmissionGuide.html#How

on how to submit a diff -u format patch.

Also a brief writeup on what the spatial queries might look like in SQL 
format would complete
what is needed to have a good grip on what you are proposing.

The TC can then review the proposal and decide if we should include it 
in version 3. My personal feeling is
that spatial metadata / query capability would be a hugely valuable 
feature in ebXML Registry 3.0 but
need to have a solid proposal to decide on the impact it would have on 
the release.

>
>  
>
>>>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?
>>
>>    
>>
>
>Adding <Module> confers some rudimentary semantics to indicate a special
>kind of registry package that bundles specific RIM extensions (note that
>we're not proposing to introduce a new type definition).
>
>Perhaps this could be done in some other manner, for example by
>specifying a Module objectType as a kind of RegistryPackage (where
>RegistryPackage/@objectType="Module"). But this mechanism is currently
>reserved only for extrinsic objects, no?
>  
>
Yes extension of types is currently reserved for ExtrinsicObjects.

Based on my limited understanding I would suggest we defer the module idea
for a future release as it may not be as vitally important as spatial 
metadata / query.

Lets focus on the spatial metadata / query and see if we can get a solid 
proposal
with minimal impact and build consensus on adding it to version 3.

Thanks again for your valuable contributions.

-- 
Regards,
Farrukh