User Interface investigation
The UPDF group decided to investigate two current open source XML based
user interfaces languages to see if either one is a good fit for our user interface
language in UPDF. The two markup languages are XUL
and UIML. Methodology used for the investigation was to see
how the language could meet the list of requirements from the UI Requirements document.
Michael Yeung (Canon) completed the investigation in to whether UIML would be a good
fit for use as our user interface language.
The resulting document is here: DOC
format PDF format
Sandra Matts investigated whether XUL would be a good fit.
The resulting document is here: DOC
format PDF format
Conclusion:
- UIML is lacking in several categories. The biggest issue is that there appears to be no
localization model. Trying to retrofit a localization model after a language has already
been defined can be extremely difficult and kludgy.
- XUL appears to fit better but there are issues there too.
The group has to decide how we want to work with XUL. There are several levels of
involvement in working with an open source project.
- Only leverage their spec and enhance it to include printer device characteristics. Each
printer company writes their own proprietary implementation. The spec is open to the
community and a standard. CONS - no leverage of testing. Each company writes an
implementation. Redundant effort.
- Work with Netscape to have the XUL spec enhanced for printer devices. The spec is open
to the community and a standard. Each printer company writes their own proprietary
implementation. PROS: other types of devices can use the spec.
- Go for it Baby! Open source the implementation for Linux and any other operating system
that cares to use it. Possibly use XPFE code for XUL parsing.
It's not clear whether our companies will let us open source any driver code. Need to
investigate further. The Printer Working Group does not currently have a process for open
source code. No server to store code. No process to check in code. No license agreement
(look at GNU GPL.)
Further investigation needed to see if we can also use XPFE (Cross platform Front
Engine) component of Mozilla's XPToolkit.
Another XML based UI language is Glade. We should look at it.
Bruce Ide from IBM gave a short talk on a PPD to XML converter that he wrote for a
driver in Linux.
Durham meeting - We won't be able to get feedback from our companies (lawyers) on
whether each company can participate in any open source project. We can continue to
evaluate the technical merits of XUL. Try to make a decision to use XUL or not (technical
only.)
Los Angeles meeting - Have a printer XUL DTD or some DTD.
Sun presentation
| Sun gave a presentation on their Java print subsystem called
Jamocha. I will put a link to the slides here when I have them. |
|
Bi-di
Requirements - This is a list of reqs from previous meetings that will be
the start of a bi-di requirements document.
- Must be able to retrieve UPDF from: Printer, OS CD, or printer CD, web site.
- Must be able to get UPDFs for installable devices - paper handling options.
- Must be protocol independent
- Must be able to reflect current configuration of printers before or during a print job.
Or any other time after initial installation.
- At driver / printer installation - reflect current config.
- Must have mechanism for determining when the config has changed.
For bi-di protocol support the model is for a "get" or retrieval of UPDF file
from a printer. It is possible there is another channel for sending the print job with PDL
information that uses another type of protocol.
The idea of sending the whole UPDF file every time or deltas needs to be looked at
carefully.
Model document should have these models - initial get of UPDF file for every protocol
out there. Parallel, Firewire, Network atached printer. Document current (somewhat static)
case of installation today. Show new printer installation with UPDF and dynamic
configuration. Most minimum level of support is a sleek printer with the URL of where the
UPDF is kept. This has no driver CD and no UPDF in printer memory.
Need to show legacy support of printers. There are at least three
variable in the printer - UPDF installation. New /Old operating system, New / Old printer.
New / Old installable option or any legacy component. New OS and New printer should
require no user intervention to install and configure a printer.Updates to UPDFs should
have deltas. We MUST document what is minimum level of support for UPDF compliance.
Deltas mechanism must be defined. Configuration retrieval must be scalable from low-end to
high-end. Printers and Hardware. Palmtop to server. Sleek to Production printer. Do we
allow for sections of the UPDF to be downloaded? One proposal is to have a 32 bit integer
where each bit describes a section of the UPDF file. Another idea is to have two files for
one UPDF. Attributes and values of those attributes. Attributes are static. Values are
dynamic. Values could be binary. This is a big change to our current UPDF spec. |
|
XML Links
Links and info
Mailing Lists
General Discussion: upd@pwg.org
To Subscribe:
- Send mail to majordomo@pwg.org with the following
in the body of the message:
subscribe upd
Archive: ftp://ftp.pwg.org/pub/upd
|