RE: About XML to multiple language/multiple outputs

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

> > > >
> > > One can, perhaps, define both query and element rules on terms of an
> > > abstract query rule, not present in the language specification.
> > >
> >    Actually, I believe (without having worked out all the details, of
> > course), that the existing query rule would be sufficient for this.
> > We know, for sure, that any other type of rule can be rewritten as a
> > query rule because the query rule allows node selection via an
> > arbitrary SDQL expression.  The only potential problem is enforcing
> > the specificity rules that DSSSL requires.
> >    I believe this can be done with the priority expression part of the
> > query rule by calculating a priority for each rule (thus, the basic
> > query rule itself would be translated into our "baseline" query rule,
> > so that we can alter the priority expression result).  For instance,
> > we would automatically just add a large constant on to the result of a
> > query rule's priority expression, and we would calculate the priority
> > of an element rule based on the specificity of its gi or qualified-gi
> > argument.
...
>
> I think a proper way to transform all rules into query rules
> without risking overflows would need a slight extension of
> the priority expression: Allow it to be a pair (or even list)
> of numbers, sort them lexicographically. Maybe that
> is the `abstract query rule' Avi was thinking of.

This looks way too specific. It will end up making the language more
esoteric, not less. Who would ever have a practical use for it?

Here is a different idea. It has to do with what I consider another
deficiency in the standard.  Suppose that nl is an element node with GI B
and we evaluate the fragment

  (with-mode X (with-mode Y (process-node-list nl))

in the scope of the following declarations:

  (element B (literal "initial"))
  (mode X (element B (literal "X")))
  (mode Y (element C (literal "Y")))

You might expect it to be formatted as "X", but the result will be
"initial", because modes don't nest: if there is no match in the current
mode, the engine falls back to the initial mode, instead of the dynamic
parent. I find this pretty odd behavior, and it makes me want to avoid
modes, period.

So suppose instead that we stipulate that modes nest dynamically. Then we
define a primitive mode for each kind of construction rule, and rewrite a
rule so it belongs to that mode.

For example:

  (element s body) ==>
  (mode %element
    (query (node-list-filter (lambda (nl) (string=? (gi nl) s)
(all-elements)) body))))

  (query e body) ==> (mode %query (query e body))

  (root body) ==>
  (query (document-root)
    (with-mode %default (with-mode %element (with-mode %id (with-mode %query
body))))

However, this requires that mode declarations can also be nested
syntactically. If the user writes:

  (mode X (element s body))

the translation is

  (mode X (mode %element (query ... body)))

What this should mean is that the rule only matches when the current mode is
X, and one of X's ancestor modes is %element (which is always true).

In general, any definitions inside the ellipsis in

  (mode A (mode B ...))

would match only if both modes are active, and B is an ancestor of A. There
is obviously a similarity to qualified GIs in an element rule, but it
doesn't make sense for my translation to insist that B be a parent mode of A
here. (Maybe someone sees how to fix that?)

--FC


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