Re: Possibly OT component request.

First stop, hello. This is my first post into this mailing list. This WG
seems to be doing a great job :)

I've read the discussion about the optional archiving step component, and I
have one suggestion for it. Instead of:
  <p:unzip>
    <p:option name="zip" value="/path/to/file.zip"/>
    <p:option name="name" value="/internal/name/with/paths"/>
  </p:unzip>
Where the name of the parameter seems to show the type of the file, I
suggest moving the type of the archive into a new parameter and call the
current parameter something more generic... like "archive". The value of the
type parameter should be (I believe) a MIME type, as that's the idea behind
MIME types, right? Showing the type of a file. More generic values (zip,
rar, etc.) would be nice too, but it just seems kind'a wrong.

One reason for this change is that instead of requesting standardization
of/creating additional parameters for each new archive, implementers can
just add types, ignore the type parameter if they don't recognize it and/or
try to guess the type themselves.

A minor change, that could as well remain as is. I think the name "file"
suits the file location better then "name", as "name" seems too... common.

Also, I'm not sure of the name "unzip". It's the "zip" that bothers me. RAR
calls it "unrar" instead, or in other words - every format vendor calls it
"un*format*". How about something more generic? "extract" maybe?
This makes the above example more like:
  <p:extract>
    <p:option name="archive" value="/path/to/file.zip"/>
    <p:option name="type" value="application/zip"/>
    <p:option name="file" value="/internal/name/with/paths"/>
  </p:extract>

Thanks for reading.

Received on Thursday, 26 April 2007 21:36:54 UTC