Re: About XML to multiple language/multiple outputs

Subject: Re: About XML to multiple language/multiple outputs
From: Brandon Ibach <bibach@xxxxxxxxxxxxxx>
Date: Thu, 26 Aug 1999 13:11:48 -0500
Quoting Avi Kivity <Avi@xxxxxxxxxxxxx>:
> > > This would be possible with the R5RS macro system, or am I overlooking
> > > something ? Maybe getting the priorities right would be a little tricky.
> > 
> > My point is really whether or not there exists a sound translation at all,
> > not how its implemented. One sticking point here is the specificity. For
> > example, a query rule is always more specific than an element rule. In
> > particular, a query rule with priority 0 is more specific than any element
> > rule. So what priority do you assign to the translation of an element rule?
> > 
> 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.
   The problem would, of course, come into play in that the user can
have their priority expression generate an arbitrarily large value, so
we could run into a problem where their value is so large that adding
anything on to it would cause an overflow.  Of course, if they're
generating values that large, they're risking overflow, anyway, so
maybe it isn't as much of a concern.  But, then, on the same note,
could we really decide what the constant would be that we would add to
query rule priorities, given that it has to insure that even a query
rule with a priority of 0 would outweigh any other rule?  Picking an
arbitrary value for this would, essentially, put a cap on how specific
a qualified-gi in an element rule could be.  However, such a
qualified-gi as might overflow such a limit is probably not a
practical reality, so, again, I wouldn't worry too much about it.
   So, does anyone else think we need to move this discussion to a new
list: dsssl-guts? :)

-Brandon :)


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


Current Thread