[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Macro Format
From: |
Guido Draheim |
Subject: |
Re: Macro Format |
Date: |
Sat, 15 Jan 2005 20:04:43 +0100 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040906 |
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 '<' instead of '<' and '&' 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-
- Re: bnv_have_qt: QT_CXXFLAGS should contain -DQT_THREAD_SUPPORT if needed, Peter Simons, 2005/01/14
- Re: bnv_have_qt: QT_CXXFLAGS should contain -DQT_THREAD_SUPPORT if needed, Bastiaan Veelo, 2005/01/14
- Message not available
- Re: bnv_have_qt: QT_CXXFLAGS should contain -DQT_THREAD_SUPPORT if needed, Peter Simons, 2005/01/15
- Re: bnv_have_qt: QT_CXXFLAGS should contain -DQT_THREAD_SUPPORT if needed, Guido Draheim, 2005/01/15
- Macro Format (was: bnv_have_qt: QT_CXXFLAGS ...), Peter Simons, 2005/01/15
- Re: Macro Format,
Guido Draheim <=
- Re: Macro Format, Peter Simons, 2005/01/17
- Re: Macro Format, Guido Draheim, 2005/01/17
- Re: Macro Format, Peter Simons, 2005/01/17
- Re: Macro Format, Guido Draheim, 2005/01/17
- Re: Macro Format, Braden McDaniel, 2005/01/15
- Re: Macro Format, Alexandre Duret-Lutz, 2005/01/15
- Re: Macro Format, Peter Simons, 2005/01/16