Bug fix for the style-sheet DTD.

Subject: Bug fix for the style-sheet DTD.
From: "Didier PH Martin" <martind@xxxxxxxxxxxxx>
Date: Fri, 6 Aug 1999 13:50:56 -0400
Hi,

I was out of the internet for couple days, the Network solutions co.
unplugged us from the DNS world. We discovered what is the impact when
network solution is doing a mistake. Now, after some phone calls, and hot
discussions, everything is back to order, my mail server and the OpenJade
home page are back.

I read the emails about the comment thread. The problem is with the modified
DTD. James modified the DTD (or somebody else) and the DTD is different from
the specs. According to the specs, a style-specification-body element should
contain anything. here is an extract from the specifications:

<!element style-specification-body - - CDATA
-- content uses notation of DSSSL style language -->
<!attlist style-specification-body
dsssl NAME style-specification-body
content ENTITY #CONREF -- Default: syntactic content --
>

As you see it is a CDATA content. Now, here is the modified Jade DTD for the
same element:

<!element style-specification-body o o (#pcdata)>
<!attlist style-specification-body
  content entity #conref
>

You can see why you can omit the style-specification-body in a DSSSL script.
This is because it is declared as a O O (omit tag - this means you are not
obliged to have a start and end tag for this element - Simply said, no needs
for tags). In the original specs, a style-specification-body element is
mandatory. In the Jade DTD it is not. Or more precisely, the start and end
tags could be omitted but not in the original specifications (even if tags
are omitted, the element is still there for the parser).

The second point is that the content has been changed from CDATA to PCDATA.
This implies that the element's content is parsed. This is why you cannot
include any comments (or nay other tags) in your DSSSL script. Normally,
this should be declared as CDATA and thus any content, including comments or
whatever the kind of tags you want to include could be included in DSSSL
constructs.

Now how to debug this?

Simple, keep the O O stuff, this is useful. You are not required to include
the style-specification-body element start and end tags in your scripts. In
the style-sheet.dtd file, change the declaration for the
style-specification-body element so that now it contains CDATA. Here is the
modified declaration that you just have to cut and paste in to DTD in order
to replace the old one generating problems.

<!element style-specification-body o o CDATA>
<!attlist style-specification-body
  content entity #conref
>

That's it, now you can include any "<>" stuff. So SGML is not so bad after
all :-).

Stay tune, I am writing a text about the DSSSL document format. A bonus, a
simple explaination about how to include self documentation within your
DSSSL scripts and second bonus, a DSSSL script to pretty print your style
sheet. The supreme bonus, the script will execute correctly. This is
something not feasible in XML. So, there is some good things with
architectures and SGML. The problem we have up to date is just a simple
explaination on how to exploit this useful feature. So the article won't bug
you with a long explaination of the architectural forms etc.. Just a simple
receipe, a proposed format to document your scripts and a script to pretty
print your scripts. Not more not less.

Hope the DTD patch will help you.

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


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


Current Thread