UPD Mail Archive: UPD> item 15

UPD Mail Archive: UPD> item 15

UPD> item 15

From: Norbert Schade (norbertschade@oaktech.com)
Date: Fri Sep 14 2001 - 13:14:29 EDT

  • Next message: Norbert Schade: "UPD> item 11"

    A controversary one.
    I have my own opinion here, so please see me as one input only, not as the chair.
    In a theoretic world there are two opposite scenarios.
    1. All information about printing devices is stored in one large database. it could be managed in a few files only, but rather likely it's split into hundreds if not thousands of small modules. this complete database will be installed with every driver plus the executables using it.
    Advantage may be not to save redundant information multiple times, as many devices are similar or identical in some feature areas.
    One disadvantage may be to maintain the database - first at the original location, which should be easier, but then on everybody's desktop. It's an update question. Rather huge portions of data would be copied around.
    1.1. A derivation of that could be that only those parts of the database would be installed, which are acknoledged to be necessary for the current devices.
    2. The opposite position would be to have a separate device description independent from any other for each and every device.
    Advantage may be a rather small set of files with rather small data will be moved around.
    Disadvantage may be that people have to test the same data all over the place again and again, although it's identical, but just nobody knows.

    The question is can we establish something in the wide range between these two opposite positions, which avoids redundant information as much as possible, but does not require the installation of some or even many other device descriptions to just complete one of them.
    Another problem to be solved is that XML - to my knowledge - is not able to define modules to a unit. This is possible with schemas (or dtd), but not with the actual xml files. So there would have to be something like a reference file for the modules.
    Every in this market section knows that the testing and QA effort is an immense problem as well.
    So if you have an idea how to serve both masters, let us know!

    Mark Hamzy, it would be nice, if you explain your position in some words, too.

    Norbert Schade
    Principal Software Engineer
    Advanced Development / Connectivity
    Oak Technology, Inc.
    10 Presidential Way
    Woburn, MA 01801
    Phone: 1-781-638-7614
    Fax: 1-781-638-7555
    email: norbertschade@oaktech.com

    This archive was generated by hypermail 2b29 : Fri Sep 14 2001 - 13:14:34 EDT