Re: About XML to multiple language/multiple outputs

[Brandon Ibach <bibach@xxxxxxxxxxxxxx>]

Quoting Frank A. Christoph <christo@xxxxxxxxxxxxxxxxxx>:
> [...]
> 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.
> 
   I believe you and I think alike when it comes to teaching computer
languages and concepts, Frank. :)  I've long felt that the best way
for someone to learn something is to take a little bit of time to
learn what's really going on.  Some simple abstractions of the
concept, along with some good analogies, can make even the conceptual
model of DSSSL clear enough.
   I also like languages that are ultimately built on a small number
of powerful constructs that can be used to build higher level ones.
Fortunately, this is also the philosophy behind Scheme.  Sadly, this
concept seems to either be missing from DSSSL, or at least left in
the shadows, and never explicitly mentioned in the spec.
   Certainly, though, implementations could be based on a model of
all style rules being broken down to (query) rules internally, with
appropriate priority handling.  From what I've seen of the macro
features of various Scheme implementations, they'd be more than
adequate to tackle something like this, as they essentially have you
create a procedure that "rewrites" the code into simpler constructs.
It's actually quite elegant, allowing you to effectively create
"templates" using quasi-quotation (an intimidating concept at first
look, but fairly intuitive after some examination and good examples).
   For that matter, I have long felt that, with such a macro facility,
the style language could actually be built upon the transformation
language, with an appropriate property set for an "FOT result grove".
   I mentioned this a while back, and someone mentioned that this
wouldn't work out too well, as the FOT is supposed to be opaque,
allowing for certain optimizations.  Upon further thought, however,
it occurs to me that once a rule has actually returned a SOSOFO to
the engine, it can't be accessed again, as there are no mechanisms for
querying the result FOT.  And, given that SOSOFOs are *not* actually
FOs, but just a specification thereof, then as long as SOSOFOs are
opaque objects (which they are, given that there are no functions
available to examine or manipulate them), then all would be well.
   Okay... sorry about that little stream of consciousness diatribe,
folks.  I just love getting into the theory of things.  This will all
be very interesting stuff to play with as we look at implementing the
transformation language in OpenJade.

-Brandon :)


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