Syntax, shall we?
haski at sezampro.yu
Sat Jan 26 04:36:55 PST 2002
On Fri, Jan 25, 2002 at 04:22:28AM -0800, Jesse Tie-Ten-Quee wrote:
> > 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>.
Heh, well... as I said, it seemed like a good idea at the beginning. :)
> > 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.
Yes, but how well is this implemented in libxml for example? I haven't
played that much with it, so I can't say how well it would handle
downloading errors or how easy would it be to write that handling around it?
> Allthough i think we should hold this off, external entities should do
> for now, imho.
> > 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 would use another, perhaps more descriptive name, but <meta>
should do the job too. :)
And element for building instructions, like <instructions>? :)
> > 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.
What about <configure> and <make>? They don't _have_ to use something like
<base> (especially <make> with its -C), but IMO, it's much much cleaner
> 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.
Yes, but as you said, without <base>-like tag we would have a ton of
<mkdir> tags. And it would look silly, since they would all have the same
"base" (heh) directory.
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