[RFC] profile editing within nALFS: how much do you really want it?

Kevin P. Fleming kpfleming at linuxfromscratch.org
Mon Mar 15 11:15:19 PST 2004


Hui Zhou wrote:

> But I have question on the usefulness of DTD. So far, the alfs profile
> only used by nALFS (correct me if I am wrong), so it only matters
> whether nALFS can parse it correctly or not. As long as nALFS can
> parse the profile correctly, there is no need to validating the
> profile.

I believe there are other ALFS tools out there, I have seen a number of 
them mentioned and there are links to some on the LFS website. I have 
never used any others personally though. The advantage here is that many 
(if not most) common programming languages have XML parsers available, 
so anyone wanting to create a tool to execute ALFS profiles does not 
have to build a parser for the profiles at all.

> I have looked at some but didn't find any that I like. I admit I never
> really tried one. Could you recommend one that handles the lfs profile
> with ease?

Nope, I use emacs and xmllint myself. Someday it would be nice if emacs 
could understand xmllint's error messages like it does for language 
compilers, but I don't need that enough to spend any time working on it :-)

> As for validation, I think XML added quite a few extra rules to make
> sure the format is robust. But one usually can store the same data
> with no ambiguity by breaking quite a few XML format. My point is, if
> the profile is just used by nALFS, whether it is an valid XML doesn't
> matter. To be able to parse the file and get the data is the only
> thing that matters.

The value of the DTD and validation is that it's much easier to find and 
correct syntax errors without having to actually interpret the contents 
of the profile.

> Putting the profile into XML format doesn't automatically make the
> profile sharable. Other program that want to use the profile still has
> to learn the DTD, learning a simple format is not more difficult.

Right, but they don't have to build a file parser, they get that for 
free by using readily-available XML parsers that turn the profile into a 
structured tree in memory ready to be used.

> Here is a question that I would like to hear from you:
> Now the parsing of profile is (or will be?) moved to the backend, is
> it possible to make the parsing function a module, so one can extend
> nALFS to use other profile if one really desire? As far as the actual
> running concerned, nALFS only cares the instructions, the original
> format is lost anyway, so it should be possible, isn't it? 

I won't say it's impossible, but it would not be easy. The nALFS 
handlers and the code that supports them are also built around the 
existing XML profiles. The same goes for the future "frontend", it will 
understand that the profile is a tree-structured entity and be able to 
navigate it with help from the backend, produce log files, etc. If some 
alternative profile could be represented in the same fashion then it's 
possible that the nALFS frontend could be used to talk to a different 
backend, but I don't know about splitting the backend into pieces.



More information about the alfs-discuss mailing list