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
simply.
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.
Regards
Norbert Schade
This archive was generated by hypermail 2b29 : Wed Nov 08 2000 - 13:52:45 EST