1. we had a mistake in the AdditionalDriverComponent.
it was of type xsd:string, although we had the right type updf:AdditionalDriverComponent available. we just didn't refer to it.
2. info about UPDF drivers.
the proposal is to replace the element AdditionalDriverComponent with a more complex element Driver.
2.1. it would have an optional (but recommended) attribute ID.
this would work as an identifier of the driver. an installer could check, if the corresponding driver is already installed.
it is questionable, whether the UnitName attribute in the master UPDF schema serves that purpose already.
my understanding is 'no', as a company may develop a corporate UPDF driver or one may want to refer to a specific driver independent from the device description info.
2.2. it would have an optional (but recommended) attribute Reference.
this is a string attribute holding a URL or a simple file name.
if it is a file name, it is supposed to live in the same directory as the device configuration. if the device configuration came from the device as the only file and the attribute is still just a file name, the installer may ask for a path more or less expecting a CD drive.
2.3. it would have optional, multiple elements OperatingSystem.
if no operating system is listed, the installer is supposed to know where to find a proper default UPDF driver.
2.4. it would have optional, multiple elements Component.
This is the previous AdditionalDriverComponent.
it the driver is a MS Windows driver with an inf included and the UPDF device description as the data format, this is likely redundant.
however if the device configuration is the only file living in the device and the driver can be any generic UPDF, this is the chance to add a library or something else to that generic driver.
Comments???
Regards
Norbert Schade
Norbert Schade
69 Prescott Drive
North Chelmsford
MA 01863
phone: 1-978-251-1017
email: norbertschade@comcast.net
This archive was generated by hypermail 2b29 : Mon Mar 22 2004 - 18:26:18 EST