UPD Mail Archive: UPD> file structure sample

UPD Mail Archive: UPD> file structure sample

UPD> file structure sample

From: Norbert Schade (norbertschade@oaktech.com)
Date: Wed Nov 08 2000 - 13:41:37 EST

  • Next message: Norbert Schade: "UPD> preliminary agenda for San Diego"

    Find attached a sample for the file structure we talked about before and
    during the Boston conference.
    Please take a careful look and note:
    1. The green elements are dtd files.
    "UPDF Entities" can be invoked by any other dtd as an external dtd and is
    intended to be so.
    "UPDF Locale" is a standalone dtd, separate from UPDF.dtd.
    You see that there are lines going from UPDF.dtd to the three light green
    dtd files. The lines shall indicate that the light green dtd files are
    external dtd files to the UPDF.dtd.
    In case we want to create physically separate XML files for sections like
    print media handling, I'm afraid we have to remove these lines and convert
    the light green external dtd files to standalone dtd files. Otherwise I'd
    expect problems with validation. By removing the lines we'd cut the
    connection to the master dtd.
    2. The master XML file (I chose the extension upd for all XML files in my
    sample) without any background color has tags for internal modules,
    installable options and locales. These units themselves do not have any
    reference back to the master unit.
    In this sample we are not working with a script file, but the tags holding
    the references (in this case file names). That implicitely requires that the
    master unit knows about the additional modules.
    In case a module (like an installable option or a new language) will be
    added late after shipment of the original device the master unit has to be
    edited. I want us all to be aware of that.
    3. XML files names are arbitrary in this sample, as long as they are
    referenced correctly in the master unit's tags.
    4. Basically all yellow modules can be shared between master units like "80
    PCL XL fonts.upd" is shared by Printer A and Printer B.
    A developer certainly had to draw his/her attention to the constraints to
    make sure the constraints are not model specific.
    5. Installable options can be shared between devices like "Input Unit 1.upd"
    is shared by Printer A and Printer B.
    6. Theoretically XML file for locales could be shared, too.
    In reality I think this will not happen, as something like the model name is
    always different.
    7. The installable options are completely separate modules. They can be
    added and removed quite easily as a whole unit by editing the master XML of
    the printer (or a script file, if we decide so).
    A developer can decide not to support installable options for some time to
    get his project running and that would be perfectly fine. Just the UPDF
    architecture should be open to extend it.
    Basically he could even leave out the support of locales for some time and
    just use the name id reference instead, which may not be a nice UI string,
    but it could be used as a string, and use the first element as default
    But I want us to set the directions for all those extensions, that as few
    code as possible has to be changed to extend the functionality.
    8. I was thinking about a different file extension (uld = universal
    localization & defaults) for the locale files. For now I take that back.
    9. Installable options may have different locales than the master unit.
    I recommend to make one locale mandatory (US English) and use a kind of
    fallback mechanism to select a proper substitution. The UPDF group could
    provide some fallback recommendations, if required.

    Please keep in mind: We are discussing the dtd and the XML file structure.
    That does not necessarily mean that the XML files are the files used by the
    driver. They could, but they need not. A driver (or a correspondent
    installer) could create some platform specific binary data out of it - for
    performance or other reasons. This is a separate issue and I want to leave
    that open to the driver developers. In case people request some conceptional
    ideas, the UPDF group may think about some recommendations.

    Ok, I would like us to finish this discussion in San Diego. So let us work
    it over in the upcoming weeks. Waiting for comments.

    Norbert Schade

    This archive was generated by hypermail 2b29 : Wed Nov 08 2000 - 13:52:45 EST