Re: Macro Format

[Guido Draheim]

Peter Simons wrote:
> Guido Draheim writes:
>
>  >> (a) Abandon XML altogether and go back to the @keyword
>  >> style of adding meta information. The HTML page
>  >> generated for your macro wouldn't look as good anymore
>  >> as it does now, but that's not exactly a major concern.
>
>  > That's a matter of parsing the content, the @description
>  > block is currently not expected to contain direct html
>  > text but one can easily enable that.
>
> Right. Technically that's no problem at all, the software
> would just "stop" quoting HTML specials, and then you could
> embed HTML into the description. The downside is that you'd
> have to write '&lt;' instead of '<' and '&amp;' instead of
> '&'.

Those escaped entities would be the case for the xml source
format as well - it would just be copied over. Anyway, I was
more thinking about adding a "limited set" of html markups
as formatting options for the @description text, just as it is
done in some online forms (i.e only <p><tt></tt> etc will work).
It would not be real xmlbased but just spiced up with more
markup options to preserve the intended presentation of the
original ac macro writer.

>
> And, of course, you'd have to deal with bogus HTML. ;-) The
> HTML pages we generate right now are _all_ perfectly valid.
> I'm not sure how much that's worth, though.

*giggle* yeah, perfect html is not too much, there are even a
bunch of htmltidy programs out there to help correcting the
usual omissions - using instead an xml output presentation
format along with a css stylesheet and a markup description
(i.e. semantic web), that'd be damn cool - and push the
world a bit ahead in time. Most browsers today can render
a good deal of a xml/css combination. I just don't know
much about gnu org guidelines however, may be it's forbidden
anyway *sigh*

>
>
>  > I won't like to see xml being abandoned altogether - it's
>  > a very good intermediate format that can combine many
>  > sources much more easily than trying to do it with a
>  > bunch of scripts.
>
> I agree. Also, XML allows us more sophisticated
> meta-information. One thing that has been missing ever since
> is the notion of "packages". XML also comes with all kinds
> of mechanisms to express cross-references and dependencies.

Well, I was extending the orginal submission format a bit to
allow more meta-information to be added - they all just take
the @format. Furthermore, I came to combine the information
in the macro with some info bits outside of the submission
to allow for things like "depracated" to be added or a
secondary category which one can not add right into the macro
text to maintain compatibility with the gnu ac archive. So,
well, most meta-information can also be added into a non-xml
based source format, it just requiries some extra parsing
routine which is the only downside of it.

>
> In case any cares, the DTD is here:
>
>   http://www.gnu.org/software/ac-archive/dtd/acmacro1-xml.dtd
>
>
>  >> (b) Commit a pseudo-macro in the legacy tree that tells the
>  >> user to go to www.gnu.org/.../bnv_have_qt.html for the
>  >> real thing.
>
>  > Only if the text is being auto-generated from the xml
>  > source, ... as things would get out of sync sooner than
>  > later.
>
> No problem, I could mirror all XML macros into the legacy
> tree automatically. The only question is whether we'd want
> auto-generated files to be committed into the CVS tree,
> especially if they don't do anything. I wouldn't mind overly
> much, but it raises the question of how far we'd like to go
> to keep sf.net "in sync" with gnu.org. I'd much rather like
> to integrate sf.net's added features (like RPMs, etc.) into
> gnu.org, so that we don't need two archives any longer.

That is kind of a problem as noted below with the haskell
dependency. When speaking about packaging we should think
it to be more in terms of "third-party" developers like
distro makers that tend to download a source tarball, add
some configure hints and patches as needed for their distro,
and go to install/pack them. - Here we speak about compiling
the xml format into a derived format (a product of a build
process!) just to zip it up and call it the source tarball
which it is not for real. Ouch.

And, well, requiring haskell as a build tool will make it so
that virtually no distro maker will accept such a packaging
system. The other thing is: I am not only installing for
rpms but also on platforms like solaris, hpux, darwin, etc
and note that I came across quite some bsd-based platforms
that do not have gnu make preinstalled. I chose autoconf/
automake to get away with it.

>
>
>  > Yeah, it's a long story. Btw, where do you have the
>  > sources to the formatting engine of yours?
>
> I never released the engine because it's (a) written in
> Haskell and not many people could run that to begin with and
> (b) because of that long story we won't retell. ;-)
>
> If there is an interest, I could make the sources available.
> It's just a fairly complex installation, because you need a
> Haskell compiler, an SGML (or XML) parser, and lot's of
> secondary tools. So it may turn out to be quite an effort to
> set it up. I'd help where I can, naturally. It would be
> pretty cool to find someone who can regenerate and maintain
> the archive too, I have too little time to respond quickly
> more often than not. I'd be all for it. :-)

Well, atleast we would need to have a few non-haskell scripts
that allow to compile the xml-macro format into aclocal/m4
text. If we do have it then one can go ahead with packaging
anyhow - whatever sophisticated there may be else in your
complete presentation engine, we can make a cvs tarball snapshot,
and compile it up into an installable format without that
dependencies.

>
>
>  > As claimed earlier I am pretty unambitious about web
>  > presentation things with my focus being more on packaging
>  > and maintaining an `acinclude` tool.
>
> What changes would need to be made to the gnu.org archive to
> make your packaging tools work? I'd really like to provide
> better releases and a way to "install" the macros.
>

autoconf atleast (we can skip automake - the rules are not
all too complex). Some non-haskell generators to do xml-acmacro
to aclocal/m4 macro. Some build rules and doc texts, and I'd
throw in my `acinclude`. That's basically it. Perhaps some
discussion how to express obsoletion and such (which has stopped
in some intermediate stage a while back).

cheers,
-- guido                       http://google.de/search?q=guidod
GCS/E/S/P C++/++++$ ULHS L++w- N++@ s+:a d(+-) r+@>+++ y++ 5++X-