corey at corey at
Mon Jun 25 06:03:34 PDT 2001

And upon Monday of June 25, the illustrious emage at spake thusly...
> On Mon, Jun 25, 2001 at 04:03:02PM +0800, corey at wrote:
> <snip>
> > <command id='1' name='mv' src='/bin'>
> >   <opt id='1' name='-f' value=''>
> >   <opt id='2' name='' value='/foo'>
> >   <opt id='3' name='' value='/bar'>
> > </command
> <snip>
> I have to ask, how is that five-line example clean?  It looks like you're
> adding a TON of unnecessary structure here.
> I agree with Corey that we should have defined constructs for most common
> tasks, like making directories, moving and installing files, etc.  That
> way, if the implementation gets changed significantly, the XML code will
> not.  

  I bring up this topic in my other latest post ( the 'long' one ).

  Could be I'm out voted!  (c8=

> Second, it seems like a tremendous waste of
> space compared to something like:
> <move src='/foo' dest='/bar' options='-f'/>

  You forgot what Jason had defined as 'dest' - where the command
  is called ( what I call 'src' in the 'command' attribute ), so 
  change your above example to:

<move dir='/bin' src='/foo' dest='/bar' options='-f'/>

> Now, I understand if you want to make some subtags for, say, all the options,
> because there could be a bunch, so like this would do:
> <move src='/foo' dest='/bar'>
>   <param>-f</param>
> </move>

  What about options that require args?  Would you put this directly
  in param? i.e., <param>-X foobar</param>

  My desire to decouple the parameters and their argument values
  certainly is debatable - another matter of design/implementation

  Was my example's "TON of unnecessary structure" due to the usage
  of the id atts and tokenizing of the option's key/value pairs?


<move dir='/bin' src='/foo' dest='/bar'>


<command  name='mv' src='/bin'>
  <opt name='-f' val=''>
  <opt name='' val='/foo'>
  <opt name='' val='/bar'>

  ( I took out the 'id' attr for now )

  The difference is, I'm wrapping my data into elements that clearly
  define exactly what it is I'm representing - and doing so in a manner
  which allows the backend code logic to perform *exactly* the same
  in all instances, while *also* avoiding the necessary definitions of 
  each and every required command in the DTD. In this way, all commands
  act the same - as they should, as far as the XML is concerned, a
  command is a command: how do you break a "command" into it's various
  tokens? I personally think the methodology in the example I provide
  is more accurate and flexible, albiet more verbose.

  Anyhow, that's my take - after this I'll let it drop and go with the
  flow, unless anyone is still interested in further discussion.

  Further, if "portability", as Corey says, is somehow an issue that 
  I'm just not seeing - there's no reason why the 'name' attr in the 
  'command' element can't simply contain an entity ref, for instance 
  in the above example change 'mv' to '%move;' .

> Here is the way I look at
> things, a far as the attribute/subtag dispute:
> 1. If there is some information that will always be a simple string/number and
>   must always be provided, it should be an attribute.
> 2. If something needs parsing, it should be a subtag, so that the XML parser
>   will parse it for us.
> 3. If there are to be a variable number of things of the same type, like
>   params above.
> 4. If there is indecision, use attributes, because they are more compact and
>   easier to parse in code, since there's no nesting to worry about.

  The above all sounds very reasonable to me, I for one am certainly
  in agreement there.



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