Comments on FilterQuery for V2.0 specs

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

The intent of this message is provide one comprehensive set of comments
and feedback on *ALL* of the FilterQuery proposal including text that is
unchanged from V1.0 and updated/new text in version 2.0 proposal. This
has been made quite hard given that there is not one single document to
review and no DTD/schema exists. I have placed a priority with P1 being
highest and P3 being lowest.

Global Issues

Describe Pattern of FilterQuery (P2)

In section 8.2 we need to describe the pattern or template for all filter
queries and their responses. This will help understandability.AdhocQueryRequest

<AdhocQueryRequest>
    <FilterQuery>
        <xxQuery>
            <xxFilter>
                .........Attribute filters using CompoundClause and SimpleClause.......
            </xxFilter>

            <methodBranch>
                .........Follow an relationship branch from xx class to another RIM class using a relationship method defined in class xxx....
            </methodBranch>

        </xxQuery>
    </FilterQuery>
</AdhocQueryRequest>

Each xxQuery has a response which looks like ....

<AdhocQueryResponse>
    <FilterQueryResult>
        <xxQueryResult>
        </xxQueryResult>
    </FilterQueryResult>
</AdhocQueryResponse>

Remove attributes/elements that are not traceable to RIM (P1)

• objectURN
• orgURN

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.

Query schema should be using RIM names (P2)

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

Editorial (P3)

• Fix cross-references so they are not hard-wired (P1). Search for "section " in section 8.2. Note this may be a global problem as well.
• Pictures need figure title for consistency and so they can be referred to easier.

Move Schema to Appendix (P3)

• understandability is improved with schema being in the appendix and simple examples being in the main part
• More importantly, it becomes a maintainence headache to have scheme in two places

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.

Need GetRegisteredObjectsRequest/Response (P1)

Need one query that uses authentication credentials (digital certificate)
provided by the requestor to return RegistryObjects that are owned by the
User associated with the specified credentials. Note that this is not a
traditional FilterQuery as the only filter is the authentication credentials.
This is a common use case "Give me all *MY* RegistryObjects". UDDI has
a similar call called get_registeredInfo in its publisher API.

Need UserQuery (P1)

We need to be able to find User objects in the registry. Currently that
is not possible. Need to consider security implications on this query.

When to Use xxFilter Vs. xxBranch (P2)

It is not clear what is the rule for using xxBranch Vs. xxFilter when defining
an xxQuery sub-elements. Why is the following query for example using ExternalLinkFilter
instead of ExternalLinkBranch?

<!ELEMENT RegistryEntryQuery ( RegistryEntryFilter?, SourceAssociationBranch*, TargetAssociationBranch*, HasClassificationBranch*, SubmittingOrganizationBranch?, ResponsibleOrganizationBranch?, ExternalIdentifierBranch*, ExternalLinkFilter*, HasSlotBranch*, HasAuditableEventBranch* )>
 

Semantic Rules Too Difficult To Comprehend (P1)

See for example 1d in RegistryEntryQuery in updated version. Doies any
of us besides teh author understand it. If not how do we expect our target
audience to understand it. Lets figure out a way to make this more understandable
and more compact. Also when using a symbolic name like CN in a semantic
rule for teh first time give a human friendly name along with it to help
with remembering it for example CN (ClassificationNode).

RegistryEntryQuery

RegistryEntryQueries Examples and HasPathBranch Vs. HasPathFilter (P1)

The second example uses HasPathFilter while third uses HasPathBranch. What
is the distinction

What Is LocalNodeBranch In RegistryEntryQuery (P1)

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

Why Do xxBranch often have xxFilter and xxQuery (P2)

See for example SourceAssociationBranch, SubmittingOrganizationBranch,

ClassificationNodeQuery

Remove PermitsClassificationBranch (P1)

I am not sure why we need this and what relationship this has to RIM.

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.

Do We Need HasParentBranch and HasSubNodeBranch (P2)

It seems to me that with basic XPATh support we do not need to include
these branches.

• To do equivaluent of HasParentBranch use a path like //parent/*
• To do the equivalent of HasSubNodeBranch one can look up teh parent attribute of a ClassificationNode

OrganizationQuery

• Rename InvokesEventBranch to getUserBranch (P2)
• Remove ContactFilter.  It has no basis in RIM. (P1)
• Remove SubmitsRegistryEntry.  It has no basis in RIM. (P1)

ReturnRegistryEntry

Note that what is unique about this request is that it returns a complete
tree for a RegistryObject (was RegistryEntry). Can we find a name that
reflects that a Tree is returned?

• Rename to GetRegistryObjectTree (P2)
• Rename ReturnRegistryEntryResult to GetRegistryObjectTreeResult (P2)
• Examples need to include example of a response document (P2)
• RegistryEntryMetadata has no basis in RIM (P2)
• RegistryEntryMetadata does not include all dynamic metdata associated with RegistryObject. For example ExternalIdentifiers are missing. Also it seems that AuditableEvent are not needed most of the time and therefor should not be returned unless specifically requests via an AuditableEventQuery. (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.

• Rename to GetRepositoryItem (P2)
• Remove RecursiveAssociationOption. It has no basis in RIM (P1)
• 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)
• Remove RepositoryItem. It has no basis in RIM. Repository items are returned as Mime attachments and not as XML fragements in the response. (P1)
• Remove WithdrawnObject. It has no basis in RIM (P1)

RegistryFilters

Make semantic rules more compact by defining them once using a pattern (P3)

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.
 

Remove IntrinsicObjectFilter (P1)

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

Need to clarify that inherited attributes are legal in filters (P2)

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

Reduce the number of error to a few generic (reusanle ones) (P1)

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

XML Clause Constraint Representation

Add Pattern Matching Support in String Clauses (P1)

Add a 'Matches' as a choice to stringPredicate. It should accepta String
pattern based on the definition of namePattern in RS 1.0 section 8.1.1
GetRootClassificationNodesRequest (based on SQL-92 LIKE patterns).

Rename connectivePredicate to logicalOperator (P3)

I believe the more accurate term is logicalOperator. "AND" is not a predicate.
It is a logical operator that logically combines two separate predicates.

Allow CompoundClase to have any number of predicates (Clause) separated by logical operators (P3 defer for V3)

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.

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