W3C home > Mailing lists > Public > public-xml-processing-model-comments@w3.org > April 2007

Re: Possibly OT component request.

From: Vasil Rangelov <boen.robot@gmail.com>
Date: Sat, 28 Apr 2007 00:50:01 +0300
To: <public-xml-processing-model-comments@w3.org>
Message-ID: <4632700c.4ffea0a6.48f5.ffff9730@mx.google.com>


>> 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?
>
>Which sounds like a lot of overloading?
>If the pipe deals in XML files, who about keeping it simple,
>if the application that is taking the file can't deal with it, it's a
>user error?
>
>That reduces implementation complexity and parameter complexity?
>
>regards

Overloading? You mean in performance sense? How come? Various other XML
based and non-XML based languages ((X)HTML to name one) already refer to
other sources and specify their MIME type in the process. That hasn't made
those languages' parsers slow. At least, not notably in my point of view.

Or do you mean in author's point of view? Well... it doesn't seem too
complex to me. And if the type option is optional (in which case the
implementation should attempt to guess the MIME type based on extension or
whatever), this would make it even easier for an author to use the step, as
they don't have to bother changing the name of the parameter when they
decide to use another file type, served from the same URL.

In implementer's sense, this would make the job easier, as if the type is
not supported, the step would just fail*. Implementation won't have to
guess... at least in its presence. In its absence, things will be slower,
but more portable. It'll be up to the author to decide which one is more
important to them (at which point speed would prevail, unless the author is
still learning).

Anyhow, if the above method of using the option name as a pointer to the
archive type is to remain (for ease of implementation's sake I guess), then
XProc needs to define a model where the presence/absence of an option would
require the absence/presence of another option. That's because if an
implementation supports say both "zip" and "rar", there's currently no way
to define that only one of those options must be used. Such mechanism would
still make XProc a bit more complex. Maybe a little too "schema"-tish.

And the first variant of file supply and no type indicator is obviously not
a good choice, as some archive files can be read in more then one MIME type,
self extracting archives (EXE files which can be read by any archiver that
supports the format the file was originally compressed with) being a typical
example.

*XProc needs some fallback mechanisms. If a step fails, there should be the
possibility of another step taking its place and the whole pipeline should
not fail unless there are no more alternatives.
Received on Friday, 27 April 2007 21:50:15 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:21:42 GMT