[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Are we losing out because of grammars?

  • From: Rick Jelliffe <ricko@a...>
  • To: xml-dev@l...
  • Date: Fri, 02 Feb 2001 01:44:00 +0800

head grammars
From: Bullard, Claude L (Len) <clbullar@i...>

>Ummm... so far it looks like they have about
>the same expressive power.  Can you show
>examples where they don't?  Appreciated...

Off the top of my head,  grammars like
   ( a, (a |b)*, c, (a, b)+, b )+
are pretty hard.  One can easily infer the rules

  - there can only be a, b, c
        test="count(*) = count(a)+count(b)+count(c)"
  - there must be at least 1 a, at least 2 b, and at least 2 c
       test="a"  test="count(b) > 1" test="count(c) >1"
  - it must start with a and end with 2b
       test="*[1][self::a]"   ???
  - a must follow c
       test="count(a[next-sibling::c]) = count(a)"

but the other information in there gets cumbersome to model with paths.
I think the reason is because there must be some anchor point (element name,
position or count) to hang Xpaths from, which is not what is available with
these
groups.

(Actually, it should be possible to mechanically generate much more complex
XPaths
to model much more.  But the chances of such complicated model corresponding
well to any cliche in an inferencing engines' database would be slight. So
we could get Xpaths, but we couldn't generate nice natural-language
explainations for them, which is the name of my game, given that notionally
in schematron the natural language assertions come first and the tests are
just there to try to model the statement as best we can.)

But my point has been to look hard at what we are missing out on expressing:
a detail that should have no part in fine schema design. Which is why I say
"who cares" about grammars (in particular, grammars once they lose the
virtue of terseness.)

Cheers
Rick Jelliffe

P.S. The kind of horrible rule to avoid would be

test="a[previous-sibling::c][next-sibling::*[1][self::b][next-sibling::*[1][
self::b
        or ( self::a[next-sibling::*[1][self::b][next-sibling::*[1][self::b
        or  ...
             ]])]]]"
but this would capture the content model for small models. The unbounded
repition
cannot be captured with this, though, it has to stop somewhere, but
simulation is possible
and can be mechanically derived from a grammar.


PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.