RE: About XML to multiple language/multiple outputs

["Frank A. Christoph" <christo@xxxxxxxxxxxxxxxxxx>]

I wrote:
> > > Frank said:
> > > ------------------------------------------------------
> > > If the query-rule construct can be simplified so as to make it
> > universal,
> > > i.e., so that all the other rules can be expressed in terms of
> > it, then I'm
> > > all in favor of it.
> > >
> > > Didier answer:
> > > ------------------------------------------------------
> > > Good.
> > >
> >
> > No need to do anything here, query is already universal.
>
> Maybe semantically, but not in practice. I meant something along
> the lines of how natural numbers can be encoded as
> lambda-functions (Church numerals), or derived expressions in
> Scheme can be defined by macro definitions. In other words, the
> equivalence should expressible in the language itself.

In retrospect, maybe I didn't mean this. (I don't remember, really---I just
got back from vacation and it's been a while since I wrote the above.)

If the other construction rules can be expressed via query, then the
standard should prefer to give their definitions in terms of a
source-to-source translation to a core language. This is a common technique
for reducing the complexity of a (declarative) language. (DSSSL also uses
it, for example, when it defines the semantics of for-each and so on.)

As a rough example, we might define the semantics of simple element rules by
the translation:

  (element <gi> <construct-expression>) =>
  (query (node-list-filter (lambda (nl) (string=? <gi> (gi nl)))
(all-elements)) <construct-expression>)

But one problem with this is that it doesn't respect the order of
specificity given in the standard: element rules are less specific than
query rules. You could express this by adding the priority part of the query
rule and putting some extra restrictions on the priority, but that tends to
work against the clarity gained by expressing things as translations.
(Another problem with this translation is that <gi> need not be a string,
and the case for a <qualified-gi> must be expressed differently.)

It's these kinds of subtle infelicities that make DSSSL hard to learn,
understand and use. If all or most of the unusual features of DSSSL (like
units, construction rules and modes) were expressed as translations to a
small and straightforward core language, it would be more IMO more easily
comprehensible.

--FC


 DSSSList info and archive:  http://www.mulberrytech.com/dsssl/dssslist