Re: Example for RS Section 8.2.9 (Registry Filters)

[Philip Goatly <philip.goatly@bolero.net>]

Hello Folks,

          Maybe this is a silly question - but inventing a filter 'language'
has anyone produced a formal grammar ?

          Having been involved with code generators/compilers etc for a
number of years in my career I would suggest this is essential. You have no
idea what problems can occur if you don't - such as producing a language
which can produce ambiguous staements.

          Your example with EQ in it looks suspiciously like Fortan to me
;-}


Cheers, Phil
----- Original Message -----
From: "Len Gallagher" <LGallagher@nist.gov>
To: <ebxml-regrep@lists.ebxml.org>
Sent: Thursday, April 05, 2001 4:13 PM
Subject: Example for RS Section 8.2.9 (Registry Filters)


>
> ebXML regrep,
>
> Special note to Scott Hinkelman -- please advise the group on the two
> problems below!
>
> Several readers of the Registry Services version 0.88 document have
> commented that the document does not have complete examples showing the
> integration of FilterQuery with the Clause syntax for constraints defined
> in Section 8.2.10.
>
> Such integration is not always desirable, since its size and complexity
> might detract from the main purpose of the examples, but I agree that at
> least one integrated example is desirable.
>
> The following example is taken from Section 8.2.2 (RegistryEntryQuery).
>
>   <RegistryEntryQuery>
>      <RegistryEntryFilter>
>         objectType EQ "CPP" AND  -- code by Clause, Section 8.2.10
>         status EQ "Approved"
>      </RegistryEntryFilter>
>   </RegistryEntryQuery>
>
> The intent of the "-- code by Clause" comment above is to indicate that
the
> example is NOT complete and that the AND expression should be encoded in
> the XML Clause syntax specified in Section 8.2.10.
>
> Section 8.2.9 (Registry Filters) is the section that integrates the
> FilterQuery approach with the Clause syntax. Right now that Section has no
> examples.
>
> I propose that we add one example to that section, to expand the above
> example, thereby showing its integration with Clause syntax.
>
> PROPOSAL
>
> Add the following as an example in Section 8.2.9
>
>   <RegistryEntryQuery>
>      <RegistryEntryFilter>
>          <Clause>
>             <CompoundClause   connectivePredicate="And" >
>                <Clause>
>                   <SimpleClause  leftArgument="objectType" >
>                      <StringClause   stringPredicate="???" >
>                          CPP
>                      </StringClause>
>                   </SimpleClause>
>                </Clause>
>                <Clause>
>                   <SimpleClause  leftArgument="status" >
>                      <StringClause   stringPredicate="???" >
>                          Approved
>                      </StringClause>
>                   </SimpleClause>
>                </Clause>
>             </CompoundClause>
>          </Clause>
>      </RegistryEntryFilter>
>   </RegistryEntryQuery>
>
> Unfortunately, I just noticed two problems while attempting to do this
example!
>
> PROBLEM #1
>
> Note that there is no "stringPredicate" defined for string equality!! Is
> this a simple omission or is it an explicit decision?
>
> Should we add "equals" or "EQ" as another alternative to the attribute
list
> for StringClause? I prefer "EQ" and "NE" to be consistent with the
> operators for numbers. If so, the new definition for StringClause would be
>
>  <!ELEMENT StringClause ( #PCDATA )>
>  <!ATTLIST StringClause
>      stringPredicate (contains   | -contains   |
>                       startswith | -startswith |
>                       endswith   | -endswith   |
>                       EQ         | NE           ) #REQUIRED >
>
>
> PROMLEM #2
>
> In the above example it's not clear if the carriage returns and blank
> spaces before and after the #PCDATA for "CPP" and "Approved" should be
> stripped off before testing for equality (or contains if equality is not
> supported!). We need to decide this, or modify the XML to make these terms
> attributes, before publication.
>
> Removing these carriage returns and blank spaces makes the example more
> difficult to read by a human.
>
> Note that many of the examples in Section 8.2.10 raise this same question.
>
> Regards,
> 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
> **************************************************************
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-regrep-request@lists.ebxml.org
>