Re: [regrep] Groups - patch-rim-query.txt uploaded

[Richard Martell <rmartell@galdosinc.com>]

Hi,


A fine summary--I wasn't really expecting anyone to examine the diff
file too closely ;-)

A few clarifications follow.

Farrukh Najmi wrote:
> Hi Richard,
> 
> 
> Here is my attempt to summarize your changes to rim.xsd and query.xsd
> for those that are new to diff -u format:
> 
> 1. Makes AdhocQueryRequest more OO and extensible:
>    -It allows an AdhocQueryRequest to carry any sub-type of
> AdhocQueryType (before it was explicitly SQLQuery or FilterQuery
>    -Eliminates use of choice (a poor choice in XML Schema design IMO) in
> AdhocQueryRequest


This change replaces the choice group with an abstract head element,
rim:AdhocQuery to provide an extensibility point. This reduces schema
coupling in that if a module introduces another kind of ad hoc query
(e.g., XQuery, XQueryX, OCL), then a supporting change isn't required
in query.xsd.


> 
> 2. Fixes inconsistency in how BooleanClause was written.


This replaces an anonymous type definition with a named one, thus making
it available for reuse (e.g., geo:SpatialClauseType extends this).


> 3. Added Module is a sub-type of RegistryPackage with no additional
> specialization
> 
> Here are some questions and comments:
> 
> 1. Makes AdhocQueryRequest more OO and extensible:
> 
> I think the changes you propose to rim.xsd and query.xsd indeed do fix
> some systemic issues with our schema w.r.t QuerySchema and
> I am supportive of the direction of the changes. I do not know XML
> schema well enough to understand the syntax used in StoredQueryType and
> QueryExpressionType. Can you send an annotated version of just those
> two  types? That would be a big help.
> 

These schema components allow for the use of generic stored queries
that are not tied to a specific query language.
<http://www.oasis-open.org/apps/org/workgroup/regrep/download.php/9183/regrep-storedquery.pdf>

StoredQueryType extends AdhocQueryType to include any query expression
(presumably one the target registry understands) as part of its
definition; trying to publish a query expressed in an unsupported
language will generate a fault message. A StoredQuery instance can
then appear wherever an AdhocQuery is allowed (e.g., within an
<AdhocQueryRequest>, or a <SubmitObjectsRequest>).

<complexType name="StoredQueryType" id="StoredQueryType">
    <complexContent>
      <extension base="tns:AdhocQueryType">
        <sequence>
          <!-- required for definition, but not invocation -->
          <element name="queryExpression"  minOccurs="0"
                   type="tns:QueryExpressionType" />
        </sequence>
      </extension>
    </complexContent>
  </complexType>
<element name="StoredQuery" type="tns:StoredQueryType"
         substitutionGroup="tns:AdhocQuery"/>


The query expression is only included when submitting the query for
publication; it's ignored for invocation (in this case StoredQuery/@id
identifies which query to execute). The attributes specify the query
language and version. The expression itself may include any kind of
content.

<complexType name="QueryExpressionType" id="QueryExpressionType"
  mixed="true">
  <sequence>
    <any namespace="##other" processContents="lax" minOccurs="0" />
  </sequence>
  <attribute name="queryLang" type="anyURI" use="required"/>
  <attribute name="version" type="string" use="required" />
</complexType>


e.g.
<StoredQuery id="some-uri">
  <Name>
    <LocalizedString value="getSomething">
  </Name>
  <Description>
    <LocalizedString
      value="Retrieve something of interest." />
  </Description>
  <!-- parameter-1 is a URI value. It would be nice to indicate
   whether or not it's required, e.g. @required={true|false} -->
  <Slot
    name="parameter-1"
    slotType="http://www.w3.org/TR/xmlschema-2/#anyURI";>
    <ValueList />
  </Slot>
  <queryExpression
    queryLang="http://www.w3.org/TR/xquery";
    version="1.0">
    ** Some XQuery expression goes here **
  </queryExpression>
</StoredQuery>


> 2. Good idea, though I caution that there may many inconsistencies and
> other issues in query.xsd in the FilterQuery schema. My position is that
> we should not change FilterQuery schema dramatically as I feel that we
> should obsolete it someday and replace qith XQuery. Until then I would
> like to make only safe and backward compatible changes to filter query.
> I believe this one qualifies as that so I +1 it.


None of these proposed changes will break anything :-)


> 
> 3. I am still not sure about Modules and would like to hold opinions
> until I have done my homework.
> 
> Others please share you thoughts on Richard's good work here. Thanks.


Interested folk should review the latest revision here:
<http://www.oasis-open.org/apps/org/workgroup/regrep/download.php/9260/regrep-modules-03.pdf>

The first section provides a brief overview and a rationale. The basic
premise is that given ebRIM is extensible, a standard means of
packaging a cohesive set of extensions would be invaluable (in
our work on geospatial applications we have found this to be the
case, especially with respect to interoperability). Modules fall
under the rubric of application profiles (cf. ISO/TR 1000-1).


-- 
Richard Martell         Public PGP key: <http://www.galdosinc.com/pgp/>
Galdos Systems, Inc.      tel: +1 604-484-2765  |  fax: +1 604-484-2755

Opinions, conclusions, recommendations, and other information presented
in this message are not given or necessarily endorsed by my employer or
firm. If the digital signature is invalid, I did not send this message.