Syntax, shall we?
mark.uzumati at virgin.net
Fri Jan 25 02:09:15 PST 2002
On 2002.01.24 18:15 Neven Has wrote:
> 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
> > 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
> > 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
> 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)
> of the one from ADG.
> Unfortunately there isn't a document describing this current syntax,
> 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
> 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)
> 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
> 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
> 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
> that much.
> 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
> (to the official syntax document in the future) that if you want
> validate your profiles with DTD you'll have to be careful with the
> order of elements. Or something like that.
Been looking more at XML Schema recently, and we definitely wont have
this problem using it. Downsides are it is a pig to read, it doesn't
seem that widely used yet, and i haven't had time to fully explore it
> o Should we have that <include> in the syntax? This element seemed
> 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
> XML editor won't include another profile when it encounters
> it will just leave it be. It could be said that this element
> the XML" in a way. (Don't take this literally. :)
> For what it's used now, something like XInclude can easily replace
> 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
> could be added to our own <include> that would allow
> implementations to
> do a lot of nice things. For example, by specifying remote url
> <location type="remote">
> implementation could either launch some program to grab that
> checking if it's successfully transferred, and acting accordingly.
> have it's own code for grabbing the profile with some nice status
> reporting or other similar perversions.
I think the only thing we might gain from our own include is somethng
like status reporting, XInclude will support remote fetching etc. At
the moment i could take it or leave it.
> 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
> and version of the package are on the same level as prebuild,
> 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>,
> <description>, <author> - all in <package_info> - without
> the <package> itself.
> Note that this change would break the profiles (at least with
> implementations), but I think it's worth it.
I like this, it would also allow a section that is maybe more flexible
in implementation, with more "optional" syntax features maybe put in
package info, while the build section is quite strict.
> o New element - <group>, or similar - was suggested here. Inside it,
> the regular elements are to be found. For example it could look
> <description>Creating directories in /usr</description>
> Personally, I don't thing this is necessary. I do agree that it
> improve the look of the profiles and make them more readable
> but if people decide that something like this should be included
> the syntax, I don't thing it should become mandatory (all elements
> some <group> or <package>).
> o Thanks to Fabien Steinmetz, there is:
> <setenv mode="append">
> <value>:/static/bin</value> <!-- Sounds familiar? ;) -->
> now, implemented in nALFS.
> I think this can be very useful (think about PATH above) and
> added to the syntax?
Ooh, I like this !
> o One general thing - where ever possible, I think we should allow
> multiple content in elements, separated with whitespace. For
Again, agree completely.
> 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
> elements and I think it should be as descriptive name as possible.
> But as someone said, we kind of got used to it. :)
I'd forgotten that thread completely :) About the only thing i can come
up with now that might be an improvement is <base_dir>
> 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
> we could all agree to use.
Agreed, some things would be nice to add but as a base i think it's
Off on holiday now, have fun, please don't generate _too_ much for me
to read when i get back :)
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