That does explain the structure, Wil. But do we need parsing relationships
in the specification of the language itself? It seems a bit like mixing the
schema and data for an xml document. (This *is* a genuine question, not a
criticism: I am far from being knowledgeable about language design.)
May be worth looking at the definition of XQueryX (http://www.w3.org/TR/xqueryx/). There does seem to be a lot of parsing info in the actual language spec: an expression (<xqx:expr xsi:type="xqx:flwrExpr">) contains a forClause, whereClause and returnClause. But it doesn't go down to the level of specifying that the Expr contains a ExprSingle which then contains a FLWORExpr (at http://www.w3.org/TR/xquery/#nt-bnf see definitions [40], [41], [42]). So maybe there is a case for pruning the parsing constructs a little.
Cheers,
Tony.
> -----Original Message-----
> From: owner-voql-at-eso.org [mailto:owner-voql-at-eso.org] On
> Behalf Of Wil O'Mullane
> Sent: 16 January 2004 18:32
> To: Martin Hill
> Cc: voql-at-ivoa.net
> Subject: Re: ADQL simplified
>
>
> My understanding of what was wanted from ADQL was a Parse
> tree for computers to work with. Not something human
> readable. We took a BNF for SQL changed it a little and fed
> it through Visual Parse to generate a Parser for the
> language. The then took classes from the parser and generated
> XSD for those. SO it is a completely automatic process which
> leaves in some redundancy but does make for much consistency..
>
> Now that is assuming we wanted a parse tree..
>
> wil
>
> On Fri, Jan 16, 2004 at 05:23:22PM +0000, Martin Hill wrote:
> > I'm working on a simpler ADQL that is less verbose and so
> easier for
> > humans and
> > tools to process. However I wanted to check first, is
> there a particular reason
> > why values are so fully (and somewhat redundantly) specified? eg
> > <Value><NumberLiteral><IntNum><Value>3</Value...etc? Was
> it just to specify the
> > values fully?
> >
> > As far as I can tell, specifying type (ie integer, string or real)
> > offers no
> > extra checking in practice, as we can't tell what types the
> columns are that are
> > being compared with (and it would be hard to validate
> anyway). Also, it doesn't
> > match the way that numbers are used in the Region schema.
> And we lose this
> > information when we convert backwards and forwards to the
> SQL-like string format
> > - or is this no longer considered important?
> >
> > Similarly with the functions - we have eg
> > <Function><AggregateFunction><SUM>
> > rather than just <Function><SUM> (or indeed <SUM>)
> >
> > Would anyone have any objections to removing these redundant nested
> > tags? Or
> > point out which wrong end of the stick I'm holding?
> >
> > Cheers,
> >
> > Martin
> >
> >
> >
> > --
> > Software Engineer
> > AstroGrid @ ROE
> > Tel: +44 7901 55 24 66
> > www.astrogrid.org
> >
>
Received on 2004-01-19Z10:06:04