Re: Revision of FilterQuery proposal

[Len Gallagher <LGallagher@nist.gov>]

Farrukh,

You seem to be misunderstanding my proposal. I was "revising" the 
FilterQuery sections to accommodate recent revisions to RIM. Many of your 
comments below address features in FilterQuery that I'm not proposing any 
changes to -- they stay in the document whether my proposed revisions pass 
or fail. I thought I was being responsive to your previous request to 
include all of the subsections, even those I'm not proposing changes to.

But I'll address all comments as best I can. See in-line below.

-- Len



At 10:21 AM 9/28/01, Farrukh Najmi wrote:
>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.


I don't have any inherent objection to letting method names from RIM 
influence branch names in FilterQuery, but it doesn't always make sense to 
do that.  For example, every RegistryEntry instance is required to have a 
unique submitting organization, but there is no explicit 
getSubmittingOrganization() method on RegistryObject or on RegistryEntry. 
Instead, the submitting organization is buried in the getOrganizations() 
method on RegistryObject. This is the type of thing I was referring to in 
my previous email message saying that sometimes the RIM model is too 
general and doesn't sufficiently call out very important concepts. 
FilterQuery chooses to make that very important concept, i.e. who submits 
stuff, more visible with an explicit SubmittingOrganizationBranch on 
important classes where the submitting organization is not easily derivable 
from some closely associated instance.

As a second example of where it doesn't make sense to use method names for 
XML branch names in FilterQuery, consider the methods that return 
collections, e,g, getClassifications(). The FilterQuery approach considers 
each of those classifications one at a time, so using the plural of the 
name would be inappropriate. Once the meaning is different, I submit that 
it is best to avoid too much similarity in the name.

I submit that there is no requirement that "Branch" elements in FilterQuery 
be in any sort of one-to-one correspondence with method names in RIM. The 
method names are at a different level of granularity.  Of course, any 
justification of a FilterQuery element should be able to show which methods 
are used to implement it. That's the intent of the Semantic Rules. It 
should be quite clear from the rules which methods would have to be invoked 
to evaluate the query and construct the query response.



>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.


Right -- this is the second example above. Since one is able to test 
classifications one at a time to see if the HasClassificationBranch is 
satisfied for one, two, or more classifications, it is better to do more 
than just drop the "s" on the name.



>
>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.


Many of us agree that the AuditableEvent class in RIM is weakly specified 
and will likely change in the near term. In anticipation of those 
modifications, the "revision" proposal didn't spend much time thinking 
about the AuditableEventQuery. Instead, I just made sure that there weren't 
any contradictions with the existing RIM.

Note that the Organization class doesn't have any getRegistryObjects() or 
getRegistryEntries() methods, even though it is a very important use case 
that one be able to "find all organizations that submitted new CPP's in the 
past 30 days". The existing OrganizationQuery assumes that it is possible 
to do these things even though there is no explicit method to do it.  The 
implicit method is to go through the Association instances that link an 
Organization to a RegistryObject (or in this use case a RegistryEntry). The 
Semantic Rules for OrganizationQuery make clear which associations need to 
be invoked!



>
>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.


I've pointed out previously that RIM makes no attempt to distinguish 
"abstract" classes from "concrete" classes. An abstract class has no 
persistent instances in the Registry, while a concrete class does. 
FilterQuery treats RegistryObject as an abstract class -- it's persistent 
instances can be viewed as the Union of all of the instances of concrete 
subclasses of it.

We could define a RegistryObjectQuery, but it would just be the combination 
of RegistryEntryQuery, OrganizationQuery, ClassificationNodeQuery, etc.

I do agree that it might be good to formalize the notion of being able to 
get back an arbitrary RegistryObject if you know it's "id" attribute. The 
existing FilterQuery cannot do that! See below for further discussion of 
this issue.


>
>
>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.

I'm proposing only very minimal changes to those "View" definitions to make 
sure the attribute names match up with new attribute names in RIM. As 
before, a ClassificationNodeQuery is required to return the node's "code" 
attribute (whoops -- should also add "parent"), which is NOT an attribute 
of RegistryObject, and an AuditableEventQuery is required to return the 
"timestamp" attribute of an auditable event, also NOT an attribute of 
RegistryObject, etc.

It would not make sense to just return "id", "name", and "objectType" for 
those types of query. Then we'd have to make a return trip to the Registry 
to get the information we really want.



>
>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.


I wouldn't oppose adding a new RegistryObjectQuery defined as follows:

  <!ELEMENT RegistryObjectQuery
     (   RegistryObjectFilter
       | RegistryEntryQuery
       | OrganizationQuery
       | ClassificationNodeQuery
       | AuditableEventQuery )>

It would return RegistryObject instances, possibly including the id, name, 
and objectType attributes. But right now such is NOT included in the 
"revision" proposal I submitted.

NOTE: FilterQuery does not support AssociationQuery or ClassificationQuery 
because Association instances and Classification instances are just links 
between other classes. We've agreed that they don't necessarily have 128 
bit UUID's. Instead, they are uniquely determined by an explicit subset of 
their attributes. This is why the new ebRIM defines compound id's for these 
classes, cf ebRIM v1.1 Sections 6.8.4, 9.1.5, and 10.3.4. It is NOT 
NECESSARY to query classifications and associations directly because one 
can always get the desired information in other ways. Those link classes 
are supported by other query capabilities.


>
>
>What Is LocalNodeBranch In RegistryEntryQuery (P1)
>
>
>
>This is nowhere to be found in RIM. Where did it come from and what does 
>it mean?


The Sematic Rules of each relevant FilterQuery define the local node to be 
the ClassificationNode instance identified by the classificationNode 
attribute of the Classification class (cf ebRIM Section 10.3.1).

That branch definition is assuming a revision to Classification being 
worked on by the External Scheme sub-team that would treat internal and 
external classifications in an analogous manner. For external 
classifications the "classificationNode" attribute would NOT be required. 
The "LocalNodeBranch" would be followed only when this attribute is 
present, thereby indicating an internal classification and the required 
existence of a ClassificationNode instance.

I wouldn't oppose a change in the wording of that Branch element to 
"InternalNodeBranch".



>
>
>Remove Path, PathElement, pathDepth in HasPathBranch, Use XPATH based PATH 
>exclusively (P1)
>
>
>
>See 
><http://lists.oasis-open.org/archives/regrep-query/200109/msg00047.html>http://lists.oasis-open.org/archives/regrep-query/200109/msg00047.html 
>for details.



This is an open issue clearly recognized by my proposal. There has been no 
agreement to my knowledge that our team has already recommended the use of 
XPATH exclusively.


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


This is a carry-over from the existing specification. I didn't propose any 
significant changes to this Section other than to delete a couple of items 
we discussed at the last Query sub-team teleconference.

But -- "submitting organization" does have a basis in ebRIM, it's just 
buried deeply under the Association link between RegistryObject and 
Organization.  The set of RegistryEntry instances submitted by a given 
submitting organization is the set of RegistryObject instances linked to 
that Organization whose objectType="RegistryEntry" and whose 
associationType="SubmittingOrganization". We could even say that other 
Association attributes are targetRole="SubmittingOrganization" and 
sourceRole="SubmitsRegistryEntry", then the Branch name would have a direct 
link to RIM. Caution: I just noticed that "sourceRole" and "targetRole" are 
no longer attributes of the Association class! That's OK with me as I don't 
think they ever get used in a definitive manner, but others may disagree.

NOTE: Recall that we did approve at the ebXML Vancouver meeting last 
February, that every RegistryEntry instance shall have a unique 
SubmittingOrganization and an optional ResponsibleOrganization. These 
requirements are no longer very visible in ebRIM -- but they are implicit 
in the Association link from RegistryObject to Organization.



>
>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.


My proposal makes only minor changes to this section to accommodate the 
fact that ClassificationScheme and Package are now purely metadata. No 
significant structural modifications were made. The points made by Farrukh 
below are not addressed by this revision proposal. They have been in the 
specification since early Spring 2001 and remain in the document whether my 
proposal passes or fails.

But I'll respond below anyway since I do think the ReturnRepositoryItem 
query is a very valuable feature of FilterQuery.

>    * Remove RecursiveAssociationOption. It has no basis in RIM (P1)
This feature depends on the Association instances in ebRIM. It allows a 
client to specifiy that it wants a specific repository item returned, along 
with all repository items that are "associated" with that item by virtue of 
an Association instance that links together their RegistryEntry instances.

For example, return a given "core component" along with all other "core 
components" that are used in its definition. The query assumes the 
existence of a "UsedBy" associationType (cf ebRIM Section 9.1.2) and allows 
the client to specify that it wants that link followed a specified number 
of times, or recursively, for an arbitrary number of times.

>    * Remove WithDescription. It is not needed as the common use case is 
> that the user already has a RegistryObject (with decsription) before they 
> use (P1)
I agree that this is a rather clunky feature that could be removed! I'll 
even volunteer to make sure it does not appear in what gets sent to the 
Editor. But I'd like explicit agreement on that from the team before I do it.

This feature to optionally not include the description was added way back 
in Oasis Registry/Repository history when descriptions could be several 
thousand characters. Now that they can only be a maximum of 256 characters 
it's a much less useful feature to be able to suppress the description.

>    * Remove RepositoryItem. It has no basis in RIM. Repository items are 
> returned as Mime attachments and not as XML fragements in the response. (P1)


I agree that repository items described by ExtrinsicObject metadata 
instances are returned as Mime attachments and that the "contentURI" 
attribute is used as a way to distinguish among multiple attachments. But 
ClassificationScheme and Package do NOT have a "contentURI" attribute so 
they cannot be referenced in that way. It's not a problem here because they 
can be returned using the XML already specified as part of the 
SubmitObjectsRequest. That's exactly what ReturnRepositoryItem does!

>    * Remove WithdrawnObject. It has no basis in RIM (P1)


But it does have a basis in RIM. At the Vancouver meeting in February we 
approved an option on the RemoveObjectsRequest to remove either: a registry 
entry and its associated repository item, or just the repository item 
associated with that registry entry. These options are identified by the 
"deleteScope" attribute on RemoveObjectsRequest. If the repository item is 
removed, but the registry entry remains, then that situation is brought to 
the client's attention with the "WithdrawnObject" element as part of a 
ReturnRepositoryItemResult.

-- 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
**************************************************************