[
Lists Home |
Date Index |
Thread Index
]
Paul T wrote:
> Can you 'configure' SGML to use *both* { and <%
> 'mixed' in a same file?
Not using a single SGML declaration, but...
> Can you 'configure' SGML
> for some other tricks with 'separators' ?
Easy. You might have:
<foo>
{foo}
!
+
all starting a foo element. This might be very inconvenient, since ! and + can
appear everywhere, so you might restrict the behaviour to only occur in a bar
element. The big caveat is that this uses short references, and no SGML editor
(AFAIK) supported them, so you did your editing with a non-SGML test editor.
Also, this behaviour is written into the DTD, though you could manage it with
entities.
> If yes, then, perhaps, it may be not a crazy idea
> to try re-factoring SGML into XML++ or XML--.
> ;-)
Or just use a combination of tools - it's so much easier to mark up something
as:
The world of dogs
Dogs come in many colours, including:
- black,
- white,
- red.
My favourite coloured dog is yellow.
and feed that into a processor validates it against a DTD and normalises it
into:
<dogument>
<title>The world of dogs</title>
<para>Dogs come in many colours, including
<list>
<item>black,</item>
<item>white,</item>
<item>red</item>
</list>
</para>
<para>My favourite coloured dog is yellow.</para>
</dogument>
This is a little bit contrived, but totally feasible. I've seen a lot denser
markup come from data that remained largely readable. When Exoterica (OmniMark)
did Cinemania for Microsoft in the early '90s, the ratio of markup to data
characters was <1 character per element. By any means but clever markup, this
would have been a disaster to try to create and maintain. There is a lot to be
said for separating markup from syntax - if nothing else, it is almost always a
waste of time to enter an end tag.
> Maybe, SGML already has all the answers, it
> is just hard to understand what was better to throw
> out of it and it is the macroprocessing part of
> SGML that should not be thrown out ;-)
Just because it didn't make it into XML, doesn't mean that it's not still
available. I think that what was thrown out was pretty reasonable - XML still
more or less hits the sweet spot for me.
> PS. I'd greatly appreciate a URL to something like
> "SGML Cookbook". Google is good, but some advice
> from human being is always better.
Like... the 'XML and SGML Cookbook' by Rick Jelliffe? Or perhaps 'Practical
SGML' by Eric van Herwijnen? (I really didn't ever expect to recommend that book
again...)
--
Regards,
Marcus Carr email: mrc@allette.com.au
___________________________________________________________________
Allette Systems (Australia) www: http://www.allette.com.au
___________________________________________________________________
"Everything should be made as simple as possible, but not simpler."
- Einstein
|
