Syntax, shall we?
haski at sezampro.yu
Thu Jan 24 10:15:24 PST 2002
On Thu, Jan 24, 2002 at 03:59:54AM -0800, Jesse Tie-Ten-Quee wrote:
> Allright, let's get this big ball of wax started.
> First, I want to express that all suggestions are welcome and will be
> considered and discussed, at least as much as we can.
> I was going to start off by posting a few new ideas i had with the
> syntax, but i want to hear from a few people first that have mentioned
> they have a few ace's up there sleeves. (*waves at Neven*)
*waves back* :)
I was waiting for your ideas, since these below are more or less old
and already discussed. But still, a new point of view is also desperately
needed for these - there might be a lot of flows in there.
First, these are all "relative" to the syntax used by both Perl ALFS
and nALFS, which is a small (at least it was at the beginning) modification
of the one from ADG.
Unfortunately there isn't a document describing this current syntax, so
the best thing one can do is check out the profiles written using it.
Which raises the question - what should we use to refer to current syntax
we are now working on?
ADG-like document is great when syntax is complete, for the profile
writer (or developer) to start writing profiles (or implementations) but,
IMHO, it's not that practical for discussing and improving the syntax
at this stage.
I think DTD could serve us well for this, it's not that hard to understand,
even for someone who doesn't know it that well (like me for example :).
Mark has one at:
Not everything is represented with it (for example the values of <options>
for different elements), but we could add some comments to it and make
it really useful for this.
I could send it here (or better first to Mark, to correct my mistakes :),
modified like that, to show what I mean.
Second, not all of the below are mine ideas. Some are from my various
TODO and TODISCUSS :) lists, and with some of them I might not even agree
They are just thrown here, in no particular order:
o The question Mark raised is whether we should force the order for
certain elements or not. For example, in:
does <base> _have_ to go first, before <param> or not.
If we start using DTD for validating profiles, it seems (I'm not
the expert) that some ordering will have to be forced?
Personally I'm not for that kind of forcing. We could just add a note
(to the official syntax document in the future) that if you want to
validate your profiles with DTD you'll have to be careful with the
order of elements. Or something like that.
o Should we have that <include> in the syntax? This element seemed like
a great thing at first, but now I'm not that sure.
As someone already mentioned, it could cause some problems in the
future, if we start using some third party XML software. For example,
XML editor won't include another profile when it encounters <include>,
it will just leave it be. It could be said that this element "breaks
the XML" in a way. (Don't take this literally. :)
For what it's used now, something like XInclude can easily replace it.
But, on the other hand, we won't be able to expend it to suit our
needs if we start using XInclude instead. There is so much stuff that
could be added to our own <include> that would allow implementations to
do a lot of nice things. For example, by specifying remote url like:
implementation could either launch some program to grab that profile,
checking if it's successfully transferred, and acting accordingly. Or,
have it's own code for grabbing the profile with some nice status
reporting or other similar perversions.
o What I think is a very good idea is something like:
<package_info> <!-- name is just an example -->
<package_building_instructions> <!-- name is just an example -->
As I said on this list, it always bothered me a bit that info like name
and version of the package are on the same level as prebuild, build
and postbuild information. All together inside <package>.
I think profile would be much more readable if we split that
Then, latter, we could also add things like <location>, <homepage>,
<description>, <author> - all in <package_info> - without "polluting"
the <package> itself.
Note that this change would break the profiles (at least with current
implementations), but I think it's worth it.
o New element - <group>, or similar - was suggested here. Inside it, all
the regular elements are to be found. For example it could look like:
<description>Creating directories in /usr</description>
Personally, I don't thing this is necessary. I do agree that it might
improve the look of the profiles and make them more readable perhaps,
but if people decide that something like this should be included in
the syntax, I don't thing it should become mandatory (all elements in
some <group> or <package>).
o Thanks to Fabien Steinmetz, there is:
<value>:/static/bin</value> <!-- Sounds familiar? ;) -->
now, implemented in nALFS.
I think this can be very useful (think about PATH above) and perhaps
added to the syntax?
o One general thing - where ever possible, I think we should allow
multiple content in elements, separated with whitespace. For example:
o Should we rename <base>? I never liked that name much, but I still
didn't want to use <dir> - this is the working directory for the most
elements and I think it should be as descriptive name as possible.
But as someone said, we kind of got used to it. :)
I might add a few more ideas latter, when I remember them. :)
All in all, I think that the current syntax is pretty close to something
we could all agree to use.
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe alfs-discuss' in the subject header of the message
More information about the alfs-discuss