corey at axcelerant.com
corey at axcelerant.com
Mon Jun 25 06:03:34 PDT 2001
And upon Monday of June 25, the illustrious emage at spamcop.net spake thusly...
> On Mon, Jun 25, 2001 at 04:03:02PM +0800, corey at axcelerant.com wrote:
> > <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
> 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
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'>
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 linuxfromscratch.org
and put unsubscribe in the subject header of the message
More information about the alfs-discuss