UPD Mail Archive: UPD> UPDF architecture

UPD> UPDF architecture

From: Norbert Schade (norbertschade@oaktech.com)
Date: Wed Oct 04 2000 - 17:47:45 EDT

  • Next message: Norbert Schade: "UPD> constraints update"

    We have started a session in Chicago to specify more details for the final
    file architecture.
    We have to consider two areas:
        DTD files
        XML files based on those DTD files

    Concerning DTD files I fought a long time with myself. After having got some
    expertise in XML and when looking at the whole picture, I am convinced that
    forcing ourselves to one DTD file has too many disadvantages.
    I'd like to make two proposals:

    1. Locales
    We will base locales on a separate DTD.
    Find the DTD, which is a very simple one, plus the specification
    documentation and two samples. You may look at the sample constraints files
    (especially constraints2.xml), which will make it more realistic.
    The documentation tells about the advantages such a solution has, expecially
    when we think about translating that stuff.
    There is one decision to make. Do we want the master XML file to know which
    locales are available? Shall it be possible to add another locale even after
    the driver is installed on a platform? If yes, the master XML file must be
    edited when a new locale is added to the system. If no, we need to specify a
    mechanism to detect locale XML files for a certain master XML file like
    adding some identification keys.

    2. Installable options
    We have to face a similar question when it comes to installable options. We
    have dodged the issue long enough.
    I think that each physical unit (the master unit = the model, optional input
    units, optional output units, etc) should be represented by a separate XML
    file.
    As a unit may include very different features (input trays, duplex unit,
    RAM - who knows about the future).
    When trying to base the installable option XML files on the same DTD as the
    master, we have to make most if not all features optional.
    Do we want that?

    3. Include files
    While we will have either one logical DTD file or (depending how we answer
    item 2) one master and one for installable options, we may want to work with
    different physical files including them to the master.
    I noticed that this method can save tons of time during development. It is
    quite simple to isolate an included DTD section and test it with a special
    XML file only based on that section without having to write or even to look
    at a complete XML file based on the whole picture.
    Sample: I sent the new version of the constraints section out today as a
    separate DTD. It can continue being a separate file when included by the
    master. Same with fonts, etc.

    Generally we have to develop a file naming system.

    I want to prepare this whole issue as much as possible before the Boston
    conference to just concentrate finding out the final weaknesses and then be
    able to make some decisions there.
    This proved to be a very good method the last conferences.

    We can make it an open discussion on the Internet or you can contact me
    directly.

    Regards
    Norbert Schade

    Oak Technology, Inc.
    Imaging Group
    10 Presidential Way
    Woburn, MA 01801-1041
    USA
    phone: 1-781-638-7614
    fax: 1-781-638-7555
    email: norbertschade@oaktech.com




    locale.gif


    This archive was generated by hypermail 2b29 : Wed Oct 04 2000 - 18:41:46 EDT