Syntax (was syntax.txt)

corey at corey at
Mon Jun 25 00:55:04 PDT 2001

And upon Monday of June 25, the illustrious Jason Gurtz spake thusly...
> > I don't think that the config, build and install tags should be
> > manditory.
> 	Here is my proposal for a template profile:
> <package>
> 	<name />
> 	<version />
> 	<pre>
> 	</pre>
> 	<build>
> 	</build>
> 	<post>
> 	</post>
> </package>
> 	I submit that <pre>, <build>, and <post> are all optional by default; only
> <package>, <name>, and <version> will be mandatory to a profile.  

  I'm in total agreement with the above proposal - I like it and
  certainly can not yet see any issues with it. If I were to have
  any sort of minor suggestion, it would be to rename the pre and
  post tags to 'prebuild' and 'postbuild', as I believe XML tag names
  should be explicitly described. XML is a meta-data mark up language -
  used to *describe your data*.  This for one thing helps weed out
  possible future ambiguities.

> 	The next issue is deciding on initial tags that actually do somthing.  
> Here is my submittal of what is neccesary:

  I'm thinking of another possible approach, see below.

> <param /> if there is more than one of these, they are applied top to bottom
> in order as arguments to the 'commanding' tag.
> <dir /> the directory where the 'commanding tag' is run.
> <src /> source file/directory
> <dest /> destination file/directory

Rather than defining tags and their requirments on a per
command basis, we make a more broad and general 'command'
tag definition:

<command id='1' name='mv' src='/bin'>
  <opt id='1'>
    <value />
  <opt id='2'>
    <name />
  <opt id='3'>
    <name />

Equates to '/bin/mv -f /foo /bar'

The 'id' parameters are required: for the 'command' tag so
that the code logic knows the order in which the commands
shall be executed - and for the 'opt' tag, so that the code
logic knows the exact order in which the options should be
provided.  The 'name' and 'value' tags in the 'opt' container
element should be required, but of course are not always
necessary, so can be left blank. 

We use the parser to construct the exact form of the command,
and then simply execute it - rather than defining translation
code for each of the "allowable" commands for which we've
strictly facilitated for in the DTD. This will enable the same
exact code logic to perform the execution of *any* command,
plus allows the packagers the freedom of running arbitrary
commands that may be required for their specific package, but 
not defined for in the DTD. Thirdly, this does not require
us to make provision for every command that may ever need
to be ran in the DTD. 

The cons of this approach though is that we lose the ability to 
enforce required parameters for commands in the DTD - for instance, 
there is no longer a 'src' tag that is flagged as required in the DTD 
for the 'link' command. Thus, a packager can fail to include this in 
his template profile, and the parser won't catch it - instead this 
will create an exception in the code logic during execution. It is also 
possible the packager misspell 'ln', for example, in the command tag's 
'name' param, causing another exception at runtime - or it now becomes 
possible for packagers to include commands that are not on the target 
system's environment.  ( however, this can be solved through dependencies 
and other means, I have a few decent ideas for this possibility ).

Freedom and Flexibility, losing Control and Structure?
Or Control and Structure, losing Freedom and Flexibilty?

What do you guys think?  I tend to favor flexibility.

> I know this is a lot but how 'bout some comments  =)

  Now how was *that* for a lot?   (c8=

  Keep the ideas/suggestions and comments rollin' guys!



Unsubscribe: send email to alfs-discuss-request at
and put unsubscribe in the subject header of the message

More information about the alfs-discuss mailing list