RE: About XML to multiple language/multiple outputs

["Didier PH Martin" <martind@xxxxxxxxxxxxx>]

Hi Frank,

Frank said:
----------------------------------------------------
It also lengthens the standard which, as someone has in fact recently
remarked, is already sizeable, intimidating and largely underutilized.

Didier answer:
-------------------------------------------------
Yes the spec is quite a big document. We can simplify it by chunking it into
several modules.

Frank said:
-------------------------------------------------
For example, how much of the standard do you think is presently used by even
a skilled DSSSL user? There are four major parts to the standard: the
expression language, the grove description, the transformation language and
the style language. In practice, nobody uses the transformation language.
Probably only 40-50 percent (at most) of the style language is used by even
a very advanced user, partly because much of it is unimplemented. The entire
expression language is used, but with a few mostly inessential changes
(e.g., units, languages and keywords), the standard could have just
referenced the Scheme R^XRS instead and excised that entire section. (That
would add side effects, though, which might be problematic.) Finally, hardly
anyone ever has cause or opportunity to use anything in the grove section
besides the element and attribute value classes.

Didier answer:
-------------------------------------------------
These are quite accurate observations. Add to this, that some part of the
specs are also badly used because the model is either:
a) not so clear
b) hard to express with the current language constructs

Like I said, we have to leave the existing features there for backward
compatibility but some part of the spec can be improved. The underlying
model can be improved too (especially the visual objects model). Grove
access can be simplified too. Have you take a look at XPath? they did a good
job to simplify any grove element access by a simple path so, they are using
a "string" to tell the system to reach a certain node by providing an
address instead of telling the system how to reach the system. It is like
giving your address to get to your place is a lot more economical than
giving all the instructions to get to your place. So, access to grove's node
can be greatly simplified too by an addressing mechanism.

Didier said:
-----------------------------------------------------
> Now to go back to useful things. The query construct has to be kept "as
is"
> in the next spec simply for backward compatibility. So, there is no
> intentions to remove it. However, there is also an opportunity to improve
it
> and particularly the query-expression part. There is possibilities to make
> it more simple. Ken Holman made an interesting suggestion with a
> query-expression able to reach any grove element without procedural
> construct but something more like a name space access path. This is
> something that need to be studied, commented, documented. (Note: I do not
> say here that this has to be like XPath)

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.

Didier said:
-----------------------------------------------------
> What is interesting is to
> listen to people saying that a particular concept is too hard to learn (we
> can improve it by bringing it to more simplicity). That a particular
> construct is too complex to write (we can then simplify this
> construct). As
> long as we can know what exactly is complex or is not very "usable" we can
> try at least to fix it. This is called evolution.

Frank Said:
-----------------------------------------------------
I have absolutely no complaints against simplifying the standard. Let's
simplify it.

Didier answer:
----------------------------------------------------
Good.

So, now, the first goal is to document the visual object model. We currently
support in DSSSL a flow formatting process, but the absolute page or scroll
object positioning is left out. The visual model needs to be updated first.
Then the functions used to manipulate the model will be obvious. Basically
the underlying model could be manipulated with any kind of language. Thus,
the first task is to document well the model or the kind of objects being
used. Rendition implies:
a) a visual model (Hence we have visual objects located in space)
b) an aural model (Hence we have aural objects located in time)
c) a possible tactile model (Hence we have objects located in space and
time).

So, actually, the main task to look at the underlying model, document it,
understand its shortcomings, improve it.

regards
Didier PH Martin
mailto:martind@xxxxxxxxxxxxx
http://www.netfolder.com

regards
Didier PH Martin
mailto:martind@xxxxxxxxxxxxx
http://www.netfolder.com



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