> <xml-stream>
snip.
Yes. I see merit in this. I would actually suggest to always use textual
stuff for things like orientation (orientation 0x01 isn't very
enlightening), and always use units as appropriate (i.e.
<tr><x>1120mm</x>... and similar), but I think xml could well be used
for more complex transmissions.
> Sure, the formatting and parsing remain problems,
Yes and no :
1. In 99% of the cases, you don't want to make sense of the data right
inside the frontend. You store the stuff away and let a specialized app deal
with it. That keeps parsing out of the frontend.
2. For those cases wher you do want, you are making use of special features
of a scanner anyway. Adding the proper parsing for the (hopefully few)
features of that scanner shouldn't be so hard.
> but at least we don't have to get those details into the SANE standard.
Exactly what I am after. And your proposal in deed goes very well together
with mine. It builds three layers of parsing complexity, that can be
implemented optionally on top of each other:
1. Only RAW data allowed. No parsing, no problem. We have to blind-save or
discard unknown data.
2. RAW + mime-typed data allowed. We have to parse a string to see if it is
something we (or an external helper) understands. If we can't find a match,
we again have to blind-save or discard, or we can let the user choose
what to do, given the type.
3. RAW + mime-typed data + internal data parsing. We have to parse the
mime string, and if we see that it is a format we can handle, we can parse
it further to gather more metadata as required. Fall back to 2., if
we fail to parse.
90% of apps will be happy with 1.
9 more percent will probably want 2. And those will probably only care for a
few types, or only with those that metamail handles as exernal helper.
And the rest will have to bite the bullet and do 3, which isn't terribly
hard either.
> I would think that other backends written for scanners with similar
> support could follow practice and use the xml encoding approach.
Yes. It is good to set such de-facto standards (if they are flexible enough).
CU, Andy
-- = Andreas Beck | Email : <andreas.beck@ggi-project.org> =
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com