[
Lists Home |
Date Index |
Thread Index
]
Scary why? Because perhaps all the information you have
been fed on a regular basis for the last few
years turns out to be partially wrong? That shouldn't
scare you. It should embarass you and make you mad.
All the answers? No, because the answer that is right
in one local space is wrong in another. SGML got a
lot of the requirements for very large and non-unique
cases of text systems right. But, that is a problem
space large enough that implementing it eliminates
everyone but programmers with several CS degrees from
major Unis. Implementing a subset of it was done
several times by people who didn't have CS degrees
to begin with. So, choose the boundary of the questions
and you get a reasonable answer for that. XML got
popular fast partly based on hype, partly based on
the then-powerful W3C imprimatur, partly due to the
rampant greed of the web community at that time,
and partly because it is a smart subset and relaxed
the requirement for processing a schema at runtime
in a separate syntax. Today almost all of those
conditions have changed. Do we still get the
same answers?
No to XML++. That screws over XML and confuses
people even more ("my precious!").
Do this the right way. Go to ISO and refactor SGML
ISO 8879 as part of the regular standard review.
For crying out loud, learn how to use the system
instead of trying to reinvent it like drywall.
Have patience and arrive at the meetings with
your homework done. It worked for the XML
WG and SIG. After several years, it should
be admitted we should have done this to begin
with instead of plotting a coup and screwing
over the system. We needed a subset of SGML
for the web; not a knife fight for control
of the future. Meatheads.
What you want for SGML, BTW, is not an SGML
cookbook. You want a copy of SP from James
Clark and a copy of the SGML Handbook from
Dr. Charles Goldfarb (Oxford Press). Neither
are easy. A complete solution never is.
len
-----Original Message-----
From: Paul T [mailto:pault12@pacbell.net]
> > OK, OK, really nice thing should allow both, because
> > some people need to edit it in a GUI HTML editor,
> > but some people are editing templates in vi / notepad
> > And I think that there is no possible markup that
> > would be good for *both* cases.
>
> You might want to have a look at SGML - you can support both syntaxes by
simply
> defining two SGML declarations. The DTD remains the same for both markup
> schemes but the instances are different. On top of that, you can assign
context
> sensitive behaviour to particular characters from within the DTD, allowing
you
> to process a csv file with a DTD.
>
> This may not be as archaic as it sounds. If you are able to separate the
data
> capture/modification/markup from the downstream usage with a normalisation
> process, then why not? We routinely still use SGML tools at the start of
XML
> projects - when the objective is simply an XML file, pragmatism beats
> standardisation every time.
Can you 'configure' SGML to use *both* { and <%
'mixed' in a same file? Can you 'configure' SGML
for some other tricks with 'separators' ?
If yes, then, perhaps, it may be not a crazy idea
to try re-factoring SGML into XML++ or XML--.
;-)
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 ;-)
Rgds.Paul.
PS. I'd greatly appreciate a URL to something like
"SGML Cookbook". Google is good, but some advice
from human being is always better.
Many thanks.
PPS. 'Worse is better' means "no namespaces, but
unique prefixes are sufficient".
So it looks like there is at least one thing that
SGML got 'right' and XML did not.
Hmm... Scary...
|
