Syntax, shall we?

Neven Has 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
this way.

> 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
and put 'unsubscribe alfs-discuss' in the subject header of the message

More information about the alfs-discuss mailing list