[RFC] profile editing within nALFS: how much do you really want it?
zhouhui at wam.umd.edu
Mon Mar 15 10:30:31 PST 2004
On Mon, Mar 15, 2004 at 10:24:12AM -0700, Kevin P. Fleming wrote:
> >I always have doubt in XML. If you don't mind, could you list the
> >reasons (sort my priority) that the profile has to be in XML, in short?
> >Appreciate it.
> Well, I wasn't around when the original decision was made to use XML for
> ALFS profiles, but I can certainly see the advantages. Some of them are:
> - pure text format (no binary storage)
I am currently working on OGDL, developed Rolf Veen,
(http://ogdl.sourceforge.net). I feel ogdl is more text format than
xml if you know what I mean.
But if that's the No. 1 reason, almost all profile ideas exist so far
are in text format.
> - the format can be described (DTD) and validated by existing tools
This is only available with XML.
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
> - there are existing document editors that can be used to create
> profiles and ensure that they are valid
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
I am a quite a vim fan, so I hate to abandon it on a text file.
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.
> - profiles are relatively easy for users to understand and aren't
> closely tied to any one particular tool or method of execution (unlike
> systems that just produce shell scripts from their "profiles")
All text file can be editted with vim.
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.
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?
More information about the alfs-discuss