Re: New ebRS Section 8.2.9, Registry Filters

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

Len,

Thanks for putting together proposal for updating Filter query section.
I think that the document so far is very easy to understand.

Note that I am replying to the sub-team and not teh TC list where yoru
original message was posted.

I assume this is just proposed replacement for  Section 8.2.9 of RS 1.0
What happens to xxxBranch, withXXX etc?

Here are some comment in advance of tomorrows meeting.

Some high level feedback follows:

1. Please include line numbers with your documents so we can refer to them.

2. Move Schema to Appendix
-------------------------------
I feel that understandability is improved with schema being in the appendix
and simple examples being in the
main part. Consider moving the schema to appendix.

3. Consider further simplification of semantic rules
--------------------------------------------------
I observe pleasantly that there is a consistent patter to the semantic rules
which can be used
to compress the semantic rule description without any loss of clarity.

Here is a suggested text:

"For every xxxFilter XML element (e.g. OrganizationFilter), the leftArgument
attribute of any containing
SimpleClause shall identify a public attribute of the corresponding UML class
(e.g. Organization)
defined in [ebRIM]. The public attribute may be either direct or inherited
from a base class.
If not, raise exception: InavlidAttributeException. The xxxFilter (e.g.
OrganizationFilter)
returns a set of identifiers for instances of the corresponding class (e.g.
Organization) whose attribute values
evaluate to True for the Clause predicate.

For example, for every OrganizationFilter XML element, the leftArgument
attribute of any containing
SimpleClause shall identify a public attribute of the Organization class
defined in [ebRIM]. The public attribute may be either direct or inherited
from a base class.
If not, raise exception: InavlidAttributeException. The OrganizationFilter
returns a set of identifiers for instances of the Organization class whose
attribute values
evaluate to True for the Clause predicate.
"

4. Remove artifacts that are not defined by RIM
------------------------------------------------
There are a few places where there are artifacts that have no basis in RIM
1.1.
RIM should drive FilterQuery design (not the other way around).

The proposal assumes that RIM needs to define Path, PathElement, and
SlotElement.
I believe that Path and PathElement should not be in the RIM because RIM
should
model the things that are in the registry not things that are attributes of
things that are in the registry

We should remove ContactFilter, SlotElementFilter, PathFilter and
PathElementFilter. We should support path (as XPATH) specification in
the ClassificationNodeFilter. We should also remove references to a Contact
class for same reason.

5. Query schema should be using RIM names
----------------------------------------------
A few places have some inconsistencies in use of names with RIM. For example:

The proposal uses  RegistryPackage when RIM uses Package. This should be
renamed to Package
The proposal uses ObjectFilter when RIM uses RegistryObject. This should be
renamed to RegistryObjectFilter

We should use the RIM names.

6. We do not need IntrinsicObjectFilter
----------------------------------------
"For every IntrinsicObjectFilter ..."
We no longer have IntrinsicObject as a class in RIM 1.1.
I feel that there are no use cases that I can see for supporting
IntrinsicObjectFilter.

7. Need to clarify that inherited attributes are legal in filters
-----------------------------------------------------------
"For every RegistryEntryFilter XML element, the leftArgument attribute of any
containing SimpleClause shall identify a public attribute of the RegistryEntry
UML
class defined in [ebRIM]."

It should be made clear at least once that inherited attributes may also be
used.
For exaple it should be legal to use "name" attribute in a
RegistryEntryFilter.

8. Reduce the number of error to a few generic (reusanle ones)
---------------------------------------------------------------
"If not, raise exception: object attribute error."
"If not, raise exception: registry entry attribute error."
....

The above should all be the same error:

Suggest replacing all such cases with:

"If not, raise exception: InvalidAttributeError."

9. Rename connectivePredicate in CompundClause
----------------------------------------------------
I believe the more accurate term is logicalOperator. "AND" is not a predicate.
It is a logical operator that
logically combines two separate predicates.

10. Allow CompoundClase to have any number of predicates (Clause) separated by
logical operators
-----------------------------------------------------------------------------------------------------

This is a significant usability improvement based on my experience with filter
queries in 1.0.
It would also require defining default precedence rules as well as Parenthesis
or Group element
to override default predence rules.

I will provide an example later today of what I am thinking of.

See additional comments inline

Len Gallagher wrote:

> Regrep,
>
> Earlier today I distributed proposals for revisions and enhancements to
> RegistryEntryQuery and ClassificationNodeQuery.  Both of those proposals
> assumed the existence of new methods in ebRIM and assumed the existence of
> dynamic, non-persistent classes based on those methods, i.e. Path,
> PathElement, and SlotElement.

I feel strongly that the query work will be iterative and will have to change
as RIM changes based on
new features for 2.0. We should not  make thoise changes in Query yet.

>

>
>
> I see no reason why ebRS cannot assume the existence of those classes,
> provided that their derivation from methods in ebRIM is specified in ebRS.

We need to describe how methods map to filter queries in detail. This is not
yet specified based
on what I see.

>
>
> Attached is a proposed extension of ebRS Section 8.2.9, Registry Filters,
> that defines PathFilter, PathElementFilter, and SlotElementFilter based on
> dynamic, non-persistent classes derived from getPath(), getPathDepth(),
> getPathElements(), and getSlotValues() methods that may be included in
> ebRIM. If those new methods are not approved for RIM, then the
> corresponding query elements can be deleted from the query proposals I
> distributed this morning.
>
> -- 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_RegistryFilters.pdf
>    RS_RegistryFilters.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