(dsssl) Markup transformind. was Re: (dsssl) How to make a RTF styles-sheet with DSSSL?

[Javier Farreres de la Morena <spanish@xxxxxxxxx>]

Brandon Ibach <bibach@xxxxxxxxxxxxxx> wrote:

>   The markup means *something*.  The trick is to come up with some
>rules to determine what it means, given the rather loose markup model.

Well, I perhaps didn't explain myself quite correctly. Of course the markup
shown in the example was totally interpretable. BUT I was talking from my
impression that ALL the rest of the markup would be of the same kind: an
immense lot of para elements one after the other, each with an attribute
describing the kind of para. And I hope there are not boxes inside boxes,
or recursive nestings like this, because then it will simply be impossible
to process.

>   While the DSSSL TL is very powerful, and a sad omission from
>current implementations, Jade's SL-based transformations are quite
>capable, as well.  In fact, within the realm of SGML-to-SGML (or
>XML-to-XML, etc), there are relatively few things that the TL can do
>that can't also be done with Jade's SL and SGML backend.

Well, yes, a mistake from my part. I wasn't taking into consideration the
extensions in Jade. I tend to think only in what the standard describes.
All my comments were written having the transformation language in mind.

>   This assumes that any sequence of one or more "box" <par>s is
>preceded by by a "title" <par>.  If not, the "box" <par>s will just be
>skipped.  If this is a possible situation, the code would need to be
>modified to handle it.

You must agree with me that the limitations imposed by the markup are too
hard anyway to infere any enhanced markup or to generate a good formatting
from it through the style language.

>   No, no and yes.  No, he would not need the query feature.  In fact,
>I don't think you really understand what the query feature is.  The
>query feature allows you to specify a processing rule which matches
>nodes using an arbitrary query language expression.  The nodes are
>still processed just one at a time.  No processing rule has more than
>one "current node", ever.  Processing more than one node in a single
>invocation of a rule is done by fetching the other nodes using query
>language expressions, as demonstrated above.
>   As for node regexps, I think you attach far too much importance to
>them.  They are simply a higher-level mechanism for querying the
>grove, just as traditional text regexps are just a higher level
>mechanism for matching text patterns.
>   Any grove querying you could ever want to do can be accomplished
>with just seven procedures, all of which have been in Jade since the
>beginning: (current-node), (node-property), (node-list), (node-list=?),
>(node-list-empty?), (node-list-first) and (node-list-rest).  (It may
>be possible to argue that there should be other entries in this list,
>but this covers pretty much everything.)  With these primitives,
>anything can be done, and all other procedures can be defined in terms
>of these.
>   Jade's grove querying capabilities are not nearly as crippled as
>you seem to think they are.

Hmm, I was thinking in the transf solution (associations) rather than the
direct application of style-transf to generate boxes.

It is true that a rule only processes one node at a time, but you can catch
a lot of nodes with one query rule and then try to find out into de processing
rule what you found, node by node.  Am I wrong in this? In fact I think
I didn't explain correctly. You can describe that a rule is apt for processing
a bunch of nodes, which you describe with a query rule. When the nodes are
processed, they are taken by one or other rule, the one with most priority.
Below there is the example of what I was thinking about. Yes. I know, transf
isn't yet implemented. For this reason I think your proposal is just a bit
more helpful than mine :)

Well, I was thinking in something like this when I wrote my comments
(By the way, some expert can tell me if the association below is close to
correct?):

(=>(regexp-search-disjoint
	(q-element
		(subgrove(grove-root)) --not sure about this line
		'para
	)
	(regexp-seq
		(regexp-node
			(lambda (x)
				(string=?
					"title"
					(attribute-string x "type")
				)
			)
		)
		(regexp-plus
			(regexp-node
				(lambda (x)
					(string=?
						"box"
						(attribute-string x "type")
						)
					)
				)
			)
		)
	)
)
(if
	(string=?
		"title"
		(attribute-string (current-node) "type")
	)
	(create-sub   --this branch is the if, for titles
		(origin (current-node))
		(subgrove-spec
			class: 'element
			add: '((gi "box"))
			children: (current-node)
		)
	)
	(create-follow --this branch is the else, for para boxes
		(ipreced (current-node))
		(subgrove-spec
			node: (current-node)
		)
	)
)
)

It is true regexps are "upper level constructs" but I prefer to use them
rather than rely on the low level ones like node.list-first node-property.
We all know that these constructs are enough for everything. But it would
be said that, if you can add, you don't need to multiply, because you can
add many times. Upper level constructs are there to help us reduce the quantity
of code written, and enhance the readability of it.

And sorry if the impression was that my oppinion is that jade has a bad
query resolution. After all, almost all the query expressions are already
implemented.

>   I'm sure many of us would like to have better-designed DTDs and
>better encoded data.  We'd also like 5 minute work weeks and an end to
>world hunger. ;)  In the meantime, how about a focus on solutions to
>problems using what we have?

I know I know. But I couldn't stand saying it, sorry. Anywayn I apologized
for the "out of reason" comments in my message at the start.
But anyway, I feel inside myself that any effort in this direction will
be of great benefit for everyone who tries it. It is a hope, at least.

Javi





-------------------------------------------------------------
 ¡ Ahora GANA VIAJES
navegando GRATIS con Tiscali !
 SÓLO HASTA EL 31 DE ENERO
 http://ganaviajes.tiscali.es/?did=EMA-5300002
-------------------------------------------------------------





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