Syntax, shall we?
highos at linuxfromscratch.org
Fri Jan 25 04:22:28 PST 2002
On Thu, Jan 24, 2002 at 07:15:24PM +0100, Neven Has wrote:
> If we start using DTD for validating profiles, it seems (I'm not
> the expert) that some ordering will have to be forced?
Last time i checked, that was totally optional weither or not ordering
was unforced, allthough another look is in order it seems. Personally i
don't see any point in having an order, thou. Except maybe for the
build instruction tags. Would suck if you go run configure before the
package is unpacked ;)
> 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. :)
When i first read this was implemented in nALFS I almost screamed
out "NEVEN?!? WTF ARE YOU DOING?!?" :) I can't, in good heart, support
the idea of <include>.
> For what it's used now, something like XInclude can easily replace it.
Oh, btw, here's the URL for XML Includions if anyone wasn't sure where
to find 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:
Actually XInclude has full support for URI/downloading external files.
It also has a few nifty features that links into XPointer, where it can
only include certain parts of an XML document. So like say you had a
profile with three packages in it, zlib, openssl and opessh, but all you
needed was zlib, then you could tell it in you're href to only include the
zlib package. Not to mention the option of parser="text"/"xml" where
you can specific it as processed or not and vice-versa.
Allthough i think we should hold this off, external entities should do
for now, imho.
> 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 totally agree and was thinking along those lines. Id had annoyed me
so much that i had switched back to using the <package name="" version="">
method in testing.
> Note that this change would break the profiles (at least with current
> implementations), but I think it's worth it.
How about <meta>? I think everyone agrees this is a step in the right
direction, and it won't limit us in the future.
> 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>).
> I think this can be very useful (think about PATH above) and perhaps
> added to the syntax?
I'll have to give it some though, but it most likelly will have to be
included. (just for that reason you mentioned)
> o One general thing - where ever possible, I think we should allow
> multiple content in elements, separated with whitespace. For example:
I tend to agree, but was hoping to hold this side of the discussing off
for a while :)
> 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.
How many tags honestly *need* support for this? <link> comes to mind,
where you *have* to have this for proper usage.
Doesn't <mkdir> even have <base> and <dir> now? That seems kinda..
unconventional, apart from the fact that it is easier to have support
for multiple targets this way. Allthough i've never really liked that
idea and it reminds me of more being stuck to the shell more then we
need to. It's fairly simple to implementent the full functuality of
mkdir with system calls (using C as an example again) and having to
parse something that's allready been parser kinda rubs me the wrong way.
Thou, on the downside, it would mean writting a huge number of <mkdir>
tags in chapter 4 now ;) I'm game thou...
Jesse Tie-Ten-Quee ( highos at linuxfromscratch dot org )
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