Re: New ebRS Section 8.2.9, Registry Filters

[Len Gallagher <LGallagher@nist.gov>]

Farrukh,

Thanks for your suggestions. I agree with some of them. In particular, I 
was so intent on adding what I needed to Section 8.2.9 in order to support 
proposals for RegistryEntryQuery and ClassificationNodeQuery that I forgot 
to propose deleting other outdated items.

Comments in-line below.

-- Len


At 12:26 PM 9/20/01, Farrukh Najmi wrote:

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



I'm happy to do this in the future if the team thinks it worthwhile.



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


This is an issue that we debated in the past. At the time, the group 
decided it was more helpful to keep the XML definitions along with the 
Semantic Rules that reference them. I defined things using DTD's, because I 
don't yet completely understand XML Schema, but have no objection to 
replacing the definitions by XML Schema if others feel that is better.



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


I have no objection to using the phrasing you propose, except I think 
there's value in letting people know which filter caused an "invalid 
attribute exception". The spelling of the error and the use or not of 
spaces versus UpperCamelNotation can be an Editor's decision.


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


My problem with specifying the use of XPATH is that XPATH assumes a 
Document Object Model definition of what is being queried. But nowhere in 
RIM do we yet define what that DOM is with respect to a node's hierarchical 
"path" being queried. I'd like to retain the definitions proposed, which 
depend only on very simple methods anticipated in RIM, until we all feel 
comfortable with whatever subset of XPATH we decide to use.

I might point out that ebRIM has a getPath() method defined for the 
ClassificationNode class, but the method is nowhere defined. It simply 
returns a String data type. I don't know how to use XPATH to query a String 
data type! That's why Filter Query defines a dynamic, non-persisent class 
called Path, having attributes "path" (a string) and "pathDepth" (an 
integer) that are derivable from ClassificationNode instances. The derived 
attributes of Path can then be queried with the Clause syntax we already 
have defined.




>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


This is an old issue. In Vancouver we agreed to replace "Package" with 
"RegistryPackage" so I believe it is RIM that should change. We agreed to 
this at some previous teleconference. However, this is NOT a big issue with 
me.  I agree that both RIM and RS should use the same term.



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


I agree -- however, at present none of the Filter Query syntax uses a 
RegistryObjectFilter, so we could delete this filter definition 
entirely.  It's unfortunate that RIM makes no distiction between what I'll 
call "abstract" class definitions versus "concrete" class definitions. An 
"abstract" class has no persistent instances; instead, it is just used to 
collect together common attributes that are inherited by "concrete" subclasses.

In my mind RegistryObject is an "abstract" class in RIM and would never 
need to be referenced in a Filter Query.  Filter Query assumes that 
RegistryEntry is a "concrete" class that holds all persistent instances of 
ClassificationScheme, RegistryPackage, and ExtrinsicObject.




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


I agree -- this filter definition should be deleted.



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


I agree -- the text you propose above to add this sentence to the 
description of each filter is OK with me.




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


I'm OK with doing this if the team agrees it is a better way to communicate 
exceptions back to the user. But I see real value in giving the user as 
much information as possible, and naming the filter that produced the 
InvalidAttributeError seems pretty valuable to me!


NOTE:  All of the following comments from Farrukh deal with ebRS Section 
8.2.10, XML Clause Constraint Representation, which was not the subject of 
any of the Filter Query proposals.  I agree with Farrukh that the Clause 
syntax is a bit clumsy and may benefit from some revision.  However, 
revision must be done very carefully as predicate syntax is very dependent 
upon precedence rules and other implicit assumptions. I'm confident that 
what we have now will work and I'd like to feel the same about any 
revisions before agreeing to them.



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

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