[RFC] SRS Section 3

Matthew Burgess matthew at linuxfromscratch.org
Fri Feb 4 10:23:16 PST 2005

Jeremy Huntwork wrote:

> 3.1.1 Profile Validation & Parsing

s/Parsing/Processing/ - to me, validation involves parsing the profile 
anyway.  However, 'processing' means translating a parsed profile into 
something useful, i.e. translating the XML into commands, etc.

> Validation is the 
> process with which an XML document (in our case a profile) conforms to 
> the DTD properly and is fully valid XML. Parsing is the process with 
> which a system takes a valid XML document and rips it apart into useful 
s/rips it apart/separates it/
> pieces. alfs needs both fully valid XML profiles and excelleent parsing 

> One of the major problems with the current nALFS is that there is no way 
> to handle conditional execution (if, then, else).

Is this sentence required?  Why worry about what an old tool couldn't 
do?  The rest of 3.1.2 reads just fine without it there IMHO.

> The new ALFS DTD v3.2 that will be used for alfs will contain the

  > 3.1.4 Logging DTD
> As mentioned above, alfs will support a new logging DTD. The logging 

s/alfs will support a new logging DTD/the new alfs schema will support 

> facility is geared towards the package manager type functions, but also 
> is an excellent way to gather details on SBU data, iterative comparison 
> of builds and other such things that LFSers are interested in. The idea 
> of the logging DTD is to provide a single source of log type data from 
> an entire build process. The log files will support apending data to the 

> 3.1.5 Split of Front End and Back End
> alfs will support a seperation of front and back end to complete a 
> client/server architecture.

Can we stick with "front end" (ui) and "back end" (daemon) for the 
terminology throughout this section please, we all know how much 
confusion has been caused by referring to things as clients and servers :)

> 3.2.1 Internationalization
> The LFS community is made up of many people from many nationalalities 
> and native languages. nALFS should support a facility of i18n plugins.

plugins?  What needs plugging in?  And certainly not to nALFS - we're 
working on alfs remember :)  Maybe you just meant "alfs should allow for 
all ui elements and messages to be translated easily".

<snipped>sections 3.3 - 3.6 appear to have been ripped out of someone's 
textbook or employer's development guidelines :)</snipped>

> 3.7 On-line User Documentation and Help System Requirements
> As with any good application, documentation and help facilities will 
> exist for alfs. Current documents are the ALFS DTD Syntax Document, 
> nALFS Users Guide and nALFS Hackers Guide.

Again, I don't think we need mention what documentation exists for the 
old tool or the fact we'll use them as a basis for the alfs' 
documentation - that's an implementation detail.  We merely need to list 
what documentation we _will_ provide, i.e.

alfs schema guide
alfs-ui user guide
alfsd user guide
alfs developers' guide.

> 3.10 Licensing Requirements
> nALFS will be licensed under the GPL.


> 3.11 Legal, Copyright and Other Notices
> Since alfs will be licensed under the GPL, there are no notices. All are 
> handled by the GPL.

Erm, what about copyright assignment?  This is of particular importance 
if the alfs community want to change the license in the future (with the 
GPL Version 3 being worked on, this may just happen!).  It's a legal can 
of worms, but might be worth at least looking into.

Good stuff so far.


More information about the alfs-discuss mailing list