Namespaces and DTDs

[Didier PH Martin]

HI Paul,

<YourComment>
I let this claim pass a couple of times because I didn't consider it
important but now I feel the need to scratch that itch. DSSSL does not
actually use parentheses as tags. If you use nsgmls to look at the SGML
structure of a DSSSL document you will find that all of DSSSL's structure
is actually in omitted tags.
</YourComment>

<Reply>
Exactly, the tag that contains all dsssl style module constructs is the
"STYLE-SPECIFICATION-BODY" element (therefore dsssl is content). Sorry I
made the wrong analogy. I should have said simply that a lisp structure
could be easily transformed into a SGML/XML compliant format. However we
would end up with a resultant document having mostly elements and properties
and nearly no element's content. But, in a certain way this is what XSL is
trying to do.

The question of mapping is very important for XSL vs DSSSL. The mapping
seems actually to be done by transforming a DSSSL property element into a
XML element. For instance, to express a DSSSL paragraph fo into a XSL block
(the block seems equivalent to the paragraph), we move from a construct
like:

(make paragraph font-size: 10pt)

to
  <fo:block font-size="10pt">

So the structural similarities are quite strong except that the former
construct begin with a verb and the latter with a noun. The former
expression has some procedural meaning and the latter is strictly
declarative. In this case, its the verb that make the whole difference and
prevent a straightforward replacement of "(" by "<" if we got instead:
(paragraph font-size: 10 pt), this can be easily mapped to <paragraph
font-size: 10pt> which is a valid SGML/XML construct. The other mapping
problem is with containment because, for instance, DSSSL expression like:

(make display-group
	(make paragraph.....)
	(make rule.....)
)
So to transform this into SGML/XML we need to change the containment syntax
rule to:
<display-group>
	<paragraph>
	</paragraph>
	<rule>
	</rule>
</display-group>

a) elmininating the procedural element "make" and then mapping containment
relationship to XML containment syntax.

So, it seems that the two blocking factors for an obvious mapping is the
procedural reference "make" and the containment syntax rule. A
transformation tool would have to consider these two factors and simply
replacing the delimiters is insufficient.

Off course if we take the expression part of dsssl we face with more
difficulties because now we have a full language. However, if we only
consider the formatting object part that XSL replicate, we see that the main
difference is not so much the "(" and ">" than the presence of procedural
elements like "make" and differences in containement syntax rules, otherwise
we would have very similar construct where the main difference would be "("
instead of ">" and a SGML/XML parser would be easily able to parse a dsssl
style simply that defining "(" as delimiters. So if DSSSL object would have
been expressed as strict property sets, the mapping would have been obvious.
The mapping is made less obvious by the procedural nature of DSSSL FOs (i.e.
the "make" verb). However, the verb add meaning to what the style language
"do". XSL construct simply say what the FO "is". Two way to express things
with their own merit and advantages. But it seems that XSL will have its own
"wall" when procedural construct will be needed. I hope simply that both
languages will find their place in the XML world each one for their own
advantages.

Sorry for not having be enough clear about what I meant. And thank you for
reminding me to be more precise :-)
</Reply>

Regards
Didier PH Martin
mailto:martind at netfolder.com
http://www.netfolder.com



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)