[regrep-query] Re: Call for Vote

[Matthew MacKenzie <matt@xmlglobal.com>]

Team,
I would like to rescind my vote on item 1, and recast the vote as NO.

I did not spend enough time reading the interaction when I cast my vote
initially, which was irresponsible on my part.

The reason I am voting "NO" is because I do not agree with Len's statement
which is included at the bottom of the message.  In my mind, it seems as
though some query functionality is being dropped, and will need to "prove
its worth" before any of it is allowed back in.  My feeling is that it is
not our job to be deciding what kinds of queries need to be made against a
reg/rep.  If we continue down this road, we should just define an inquiry
and retrieval API like UDDI has done, instead of having a complex query
solution (Filter Query) which only handles a carefully crafted set of query
types.  Basically, if it can be represented in the RIM, I should be able to
query on it and its relationships.  If things that are accesable make no
sense, fix the RIM, not the query stuff.

At the same time, I have no remedy to suggest beyond leaving browse and
drill down in place until this is fixed.  I lack the depth of understanding
in Filter Query to offer any other suggestions.

Regards,

Matt

<excerpt
        author="len"

location="http://lists.oasis-open.org/archives/regrep-query/200110/msg00014.
html">
I don't think FilterQuery has to support Association instances between
every type of class in RIM. For example, what would be the purpose of
Association instances between AuditableEvent and ExternalIdentifier, even
though technically they are representable in ebRIM?  If some important
associations do exist, then lets label them and make them part of the
ebRIM  specification. NOTE: FilterQuery does treat the important
association from Classification to Organization (i.e.
SubmittingOrganization) as an important association; each
HasClassificationBranch has a SubmittingOrganizationBranch as a
sub-element. This recognizes that Classification of a RegistryEntry can be
done by someone other than the SubmittingOrganization that owns that
RegistryEntry. E.g. the UserCarDealers association may classify electronic
parts in a completely different way than does the IEEE. Also note that the
two AssociationBranch elements do NOT have a SubmittingOrganizationBranch
as a sub-element; this is because at one point in the past I thought we all
agreed that all Association instances would be owned by the
SubmittingOrganization of the sourceObject (but this assumed rule is not
yet part of ebRIM).
</excerpt>