OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

regrep-query message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: Revision of FilterQuery proposal


Len,

Thanks for the update and for addressing several issues identified previously by team.

Below are the list of remaining issues that I feel are *MUST FIX*. Note that this is a much pruned down sub-set of my previous issues list.

We can test whether they are or not in the meeting:
 

Need Pattern for Mapping RIM Methods (P1)

The branch elements in queries are a mapping of RIM relationship methods. However, they are named in an adhoc way rather than based on the RIM method name using a fixed pattern. This should be fixed for coinsistency and ease of understanding.

For example the getClassifications method in RegistryObjectClass in RIM should map to a getClassificationBranch (notice mapping to method name with plural suffix removed) instead of HasClassificationBranch.

Avoid Mapping RIM Relationship methods Bi-Directionally When Method is only in one Class (P1)

This is a recurring issue. For example according to RIM an AuditableEvent has a User and a User does not have an AuditableEvent. AuditableEventQuery correctly has a InvokedByBranch (should be named getUserBranch). However, the InvokesEventBranch (should be getUsersBranch) in OrganizationQuery also has a AuditableEventFilter. This is unnecessary and adds significant complexity.

Need to Compensate for RIM 1.1 Moving Classes From registryEntry To RegistryObject (P1)

There are many places in filter query where this change in RIM 1.1 has implication. One exaple is that we need to replace ReturnRegistryEntry with ReturnRegistryObject.
 

Remove xxViews (P1)

We should not have the xxView elements (e.g. RegistryEntryView) as defined in section RS 1.0 section 8.2.1. They are defined in an ad hoc manner instead of a mapping from RIM. xxViews are used in xxResult (response to the query e.g. RegistryEntryQueryResult). Instead xxResult should return a RegistryObject.

Need RegistryObjectQuery (P1)

We need to be able to query on RegistryObjects in abstracts as we have moved most classes in RIM 1.1 to be sub-classes of RegistryObject when they used to be RegistryEntry sub-classes in RIM 1.0.
 

What Is LocalNodeBranch In RegistryEntryQuery (P1)

This is nowhere to be found in RIM. Where did it come from and what does it mean?
 

Remove Path, PathElement, pathDepth in HasPathBranch, Use XPATH based PATH exclusively (P1)

See http://lists.oasis-open.org/archives/regrep-query/200109/msg00047.html for details.
 

OrganizationQuery

Remove SubmitsRegistryEntry.  It has no basis in RIM. (P1)

ReturnReopositoryItem

I have serious concerns about this query. It seems to be the most farthest removed from RIM and RS and is very ad hoc in its description.

Len Gallagher wrote:

Query team,

At last Friday's Query teleconference, I agreed to update the FilterQuery
proposal to incorporate decisions made during that meeting, to modify all
subsections of ebRS Section 8.2 to bring them into line with the revised
ebRIM, and to publish the whole proposal as a single revision of that
section of the spec.

The complete section 8.2 is attached as a line-numbered PDF document (31
pages).

Here's an overview:

8.2 -- FilterQuerySupport
Very minor edits to introduction.

8.2.1 -- FilterQuery
Minimal changes to bring attribute names into alignment with ebRIM.

8.2.2 -- RegistryEntryQuery
Created a new ExternalLinkBranch element as agreed by the team.
Marked the 3 alternative subelements of HasPathBranch as incomplete and
subject to enhancement or deletion.
Modified one of the examples to show XPATH syntax.

8.2.3 -- AuditableEventQuery
No changes. This section is subject to modification as the
AuditableEventClass in ebRIM evolves.

8.2.4 -- ClassificationNodeQuery
Deletion of the PermitsClassificationBranch as agreed by the team.

8.2.5 -- RegistryPackageQuery
No changes.
NOTE: The functionality of RegistryPackageQuery is all attainable via a
slightly longer REgistryEntryQuery. Maybe the whole section is a candidate
for deletion.

8.2.6 -- OrganizationQuery
Deletion of ContactFilter as agreed by the team. This section could be
further enhanced to support dynamic classification of organizations. That
enhancement would be straight-forward once decisions on
HasClassificationBranch are agreed.

8.2.7 -- ReturnRegistryEntry
Minor wording changes for clarity.

8.2.8 -- ReturnRepositoryItem
Significant modifications to capture ebRIM changes to now treat
ClassificationScheme and Package as metadata.
Created new element for ClassificationSchemeRepresentation.
Created new element for RegistryPackageElements.
Re-named ExtrinsicObject to ExtrinsicObjectFile to avoid conflict with
metadata.
Re-named ExternalLink to ExternalRegistryItem to avoid conflict with metadata.

8.2.9 -- RegistryFilters
Minor wording changes in Semantic Rules 15, 16, 17.

8.2.10 -- XML Clause Constraint
No changes.

-- Len

**************************************************************
Len Gallagher                             LGallagher@nist.gov
NIST                                      Work: 301-975-3251
Bldg 820  Room 562                        Home: 301-424-1928
Gaithersburg, MD 20899-8970 USA           Fax: 301-948-6213
**************************************************************

  ------------------------------------------------------------------------
                                  Name: RS_FilterQuery_20010927.pdf
   RS_FilterQuery_20010927.pdf    Type: Acrobat (application/pdf)
                              Encoding: BASE64

--
Regards,
Farrukh
 
begin:vcard 
n:Najmi;Farrukh
tel;work:781-442-0703
x-mozilla-html:FALSE
url:www.sun.com
org:Sun Microsystems;Java Software
adr:;;1 Network Dr. MS BUR02-302;Burlington;MA;01803-0902;USA
version:2.1
email;internet:najmi@east.sun.com
fn:Farrukh Najmi
end:vcard


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC