Spec/regrep
From Omar Wiki
Use Cases
Use cases for ebXML Registry are beind collected here.Feature Description
This section describes various features of ebXMl RegRep
- Spec/regrep/sql - Describes ebXMl RegRep SQL Schema
Request For Enhancements (RFEs) to ebXML Registry specs
Internationalized Slots
- Slot name and values should be internationalized.
Extensible Slots
- Slots should allow extensibility and substitution (See OGC pkg-basic.xsd)
Embedded Classes
- Currently embedded classes such as PostalAddress, TelephoneNumber, EmailAddress cannot have slots as they are not RegistryObjects.
It would be good to allow these to be extensible. Perhaps the esiest way to do this is to make these classes be derived from RegistryObject
- Currently only certain classes can have certain embedded classes. For example it is not possible to embed a PostalAddress inside an ExtrinsicObject.
RIM should allow any RIM class to embed any eembedded class. At the very least ExtrinsicObject should be allowed to have any embedded class.
Proposed SetStatus Protocol
- Replace Approve, Deprecate, Undeprectae etc. with a single setStatus method that can take any StatusType node reference as its value and thus allow user defined lifecycle status values.
- Have some way to specify which StatusType apply to which objectType to reduce visual clutter in GUIs. Currently if every one adds some StatusType nodes then everyone sees everyone elses StatusTypes in the UI.
AssociationType Scheme
- Add ConnectedTo
- Add Delivers
- Add Publishes
- Add Subscribes
ObjectType Scheme
- Add Schematron
- Allow new ObjectTypes to be defined any where in ObjectType hierarchy. At present there is a potential for namespace conflict with all extension being derived from ExtrinsicObject.
- Move mimeType from ExtrinsicObject to a slot on ClassificationNode in ObjectType
SubjectRoleScheme
- Remove Classification that classifies urn:freebxml:registry:predefinedusers:registryoperator
Publish
- rim.xsd say "slotType value MUST reference a ClassificationNode in the canonical DataType scheme" but spec says nothing of the sort. There is a need to be more flexible and allow slotType to reference other taxonomies as domain for values via some taxonomy specific urn. Need to make a consistent statement regarding slotType and note any expected checks server must perform under certain situations.
- Add TriggerListener protocol to allow database like triggers to invoke TriggerListener service to determine whether to commit or rollback transaction
Classification
- Consider supporting syntax to group related Classifications in a ClassificationGroup. See Marco's email on 12-09-2005 to ebxmlrr-team.
Reference Attributes
- Need to allow a reference attribute value to be able to include semantics like: "get me the latest version of this lid"
- Need to allow a reference to include a selector query to select the version of object being referenced by a lid
Associations
- Need to support bi-directional vs. uni-directional associations. Currently only uni-directions is supported which requires 2 associations when 1 would have sufficed.
Content Management Services
- Allow interceptors to be defined ona per objectType basis similar to cataloger and validator that can be configured to intercept any type of request involving objects with corresponding objectType. Example: Profiles need a way to clean up cataloged metadata when object that was cataloged is deleted.
Cataloging
- TBD
Validation
- Add Canonical XML Validation Service with Schematron as Invocation Control File
- Add Canonical RDF Validation Service with OWL as Invocation Control File
- Should allow invalid docs to be stored with status of Invalid so some workflow can occur when invalid documents are published. Or perhaps allow submission to occur withoujt validation and then provide a way to validate after submission (from UN/CEFACT Registry Profile).
Access Control
- Allow access control policies to cover multiple objects (Adnan's use case) or maybe even a RegistryRequest
- Fix slotName "ComposedPolicies" for declaring the composed Policies within a PolicySet to be a URN to avoid name conflicts.
- Fix the special case where subject-id XACML constant is used instead of normal id attribute used by regrep because it creates special cases in implementations.
Versioning
- Align with experience from subversion:
- Use integer versionname that is simply the monotonically increasing number associated with a request
- Add support for checkout
- Add support for branching and tagging
Query
- Clarify predicate pruning spec. What defines a predicate boundary. What role if any for '(' and ')'. See regrep meeting notes on 12-15-2005 by Farrukh.
- Support access control on who can invoke a stored query or an ad hoc query (Alexi Polenur).
- 6.3.1.1: specifies parameter name syntax to be overly restrictive and does not accomodate '.' character used in WSDL profile
- Current syntax:
QueryParameter := '$' <LETTER> ( <LETTER> | <DIGIT> )* - Omar currently supports:
QueryParameter := '$' <LETTER> ( '.' | '_' | <DIGIT> | <LETTER> )* - Suggested syntax #1:
QueryParameter := '$' <LETTER> ( '_' | '$' | '#' | <DIGIT> | <LETTER> )* - Note: The suggested syntax is based on SQL 92 syntax for a variable. It does not allow '.' character either so perhaps WSDL profile and others should use '_' char instead.
- Suggested syntax actually goes beyond SQL 92 in allowing the SQL comment character ('#') and a LIKE special character ('$'). Doug instead suggests...
- Suggested syntax #2:
QueryParameter := '$' <LETTER> ( '_' | <DIGIT> | <LETTER> )* - This additional suggestion matches a SQL 92 identifier with a leading (otherwise illegal) '$'. With this option, existing use of the '.' character (which prevents use of a parameter as a column name) must change to instead use '_'.
- Current syntax:
- TBD
RegistryRequest
- Provide ability to do multiple requests in same transaction. This could be done for example by sumply allowing a new SubmitRequests protocol where SubmitRequests request can include multiple primitive requests.
RemoveObjectsRequest
- Add a cascadingDelete attribute which if true signals that deleting a RegistryPackage recursively deletes its members and their members modulo access control. May apply to other types of objects as well. (Andrzej, Steve Allman).
- Add a "transaction" slot to associate RegistryObjects generated by submission of an ExtrinsicObject (via content indexing) to the submitted ExtrinsicObject. This would allow generated objects to be removed (or deprecated) automatically when the ExtrinsicObject is removed (or deprecated). This creates a shared life-cycle between master and dependent objects. This could also apply to content indexing of ExternalLinks for remote content.
- Ensure that cascading deletes are performed server-side to avoid scalability issues.
Canonical Queries
- FindUnreferencedObjects: Find by objectType all non-composed objects that have no references to them. This could be used to do garbage collection.
Event Notification
- Add ref attribute "event" to NotificationType so a Notification can be tied to the event that created it. (Doug Bunting)
- Add support for role based event notification (RBEN) so if event E happens notify roles R. (Nemanja <memar_car@yahoo.co.uk>)
Repository
- Allow XML RepositoryItems to be embedded within ExtrinsicObject
- Add size column to ExtrinsicObject to track size of repositoryitem
- Allow external repositories such as svn to be used as repository
XML Schemas
- Allow xml:base to be in any element in order to validate output produced by XMl Includes, For problem description see http://norman.walsh.name/2005/04/01/xinclude
Bugs in ebXML Registry specs
Bugs for Errata
- Many figures are missing ebRIM and ebRS
- The stored query given in "Listing 2: Example of AdhocQueryRequest to a Parameterized Ad hoc Query" should be replaced with the one in the /cvsroot/ebxmlrr/omar/misc/samples/StoredQueryInvocationExample.xml
- "A Submitter MAY optionally supply the id attribute for submitted objects" the paragraph suggests that id attribute of Identifiable is optional when it is actually not so according to rim.xsd (from Andrzej). The rim.xsd is correct and paragraph is wrong (from Farrukh).
Andrzej responds: I'm not sure you should be so quick to judge this a bug/mistake. I can see many scenarios where it would be very convenient to be able to create objects where you specify only the lid and have the registry generate the unique id (uuid). We have a number of those in the project I'm working on. I think it's a valuable feature and that the spec is correct as written. If the application doesn't care what the id is, why should we have to specify it, when the registry can easily generate a unique UUID on our behalf? This doesn't make any sense to me. From a practical users perspective I vote a strong -1 on making this a bug! And +1 one on changing the implementation to suit the spec. I think the implementation is incorrect and the spec is just fine. Andrzej's argument makes sense (Nikola), but question is what to do with the rim.xsd as "id" is required under "IdentifiableType".
- PostalAddress is missing a type attribute that allows classifying the PostalAddress. Noet that TelephoneNumber and EmailAddress are OK.
- ebXMLRegistryInterfaces.wsdl file (a possible copy/paste error). Here is the current snippet from that file:
<operation name="updateObjects"> <input message="tns:msgUpdateObjectsRequest"/> <output message="tns:msgUpdateObjectsRequest"/> </operation>
and it should look like:
<operation name="updateObjects"> <input message="tns:msgUpdateObjectsRequest"/> <output message="tns:msgRegistryResponse"/> </operation>
Other Bugs
- Need to provide a normative and consistent way to handle VARCHAR columns that exceed the specified fixed lentgth. Currently the big issue is with query column in AdhocQuery table which run into limit of 4000 characters in Oracle db. Suggest using a spillover algorithm where if string does not fit it is written to a RepositoryItem and the id of spillover RepositoryItem is written in teh field value instead.
- ObjectRef in the ebRIM spec is overloaded (in 2.2 it is a data type, in 2.7 it is a class). Also, should check in both ebRIM and ebRS all usages of the keyword "ObjectRef" and make sure that semantics is correct.
- PersonName attributes FirstName, MiddleName and LastName SHOULD be InternationalStrings. Use case: a user MAY want their PersonName.FirstName/MiddleName/LastNames to appear in two different locales. For example: a Chinese user may want his name to appear in zh for Chinese users and in en for US users.
- Notification and NotificationObject classes are transient -- never usefully persisted to the registry. They therefore should not appear in the example sql/database.sql file.
- Side note: Omar shoudn't create these tables in the database either.
- Farrukh: This is not a bug. Whether they are used or not is an impl detail. We could use persistent notification to make sure that they are reliably delivered with Once and Only Once semantics for example.
- NotificationListenerBindings.wsdl uses incorrect soapAction URN: "urn:oasis:names:tc:ebxml-regrep:wsdl:NotificationListener:bindings:3.0:NotificationListenerPortType:onObjectRefsNotification"
Request For Enhancements (RFEs) to Profile Guide
- Add suggestion that new extension nodes should be under a profile specific node to avoid name conflict.
Bugs in Profile Guide
- TBD
