From: Abdallah Qaisi [SMTP:email@example.com]
Sent: Friday, August 13, 1999 5:37 PM
To: BEN_BREZINSKI@HP-Vancouver-om1.om.hp.com; firstname.lastname@example.org
Subject: Re: UPD> re-scope of UPDF
Ben, Sandra, see my comments below.
>Item Subject: UPD> re-scope of UPDF
> I don't see any much overlap between IPP and UPDF. UPDF is the
> description of the printer, and is (should be?) transport independent.
> As far as I know, we haven't made IPP a required component of UPDF.
It's true we haven't made IPP a requirement - UPDF is supposed to be protocol
independent. However, that means we will have to create the xml that
can be used with any network protocol and then provide the mapping
from UPDF to the different protocols. This will be a large job and will
require more time to do. We would have to schedule work time
between meetings to get this done. In the interest of making UPDF useful
to the largest number of printers - I believe this is the right thing to do.
However, it would be helpful if I felt people would contribute input when
we do the bi-di work.
> I agree that we need to re-clarify. IPP is capable of retreiving
> facts about the printer, but UPDF expresses not only the facts, but
> how they relate to one another.
> If we steer toward Linux and Unix, then we need to drop the "U" from
> the comittee name,
"U" can stand for Unix too;) Dropping it causes a clash with Adobe PDF.
> as it will no longer be universal, and will be of a
> much more limited interest to me.
> Ben B
> There also has been some thought about steering UPDF towards
>a Linux (and other Unix flavors) printing solution and not really a
>solution. What do
>people think about that?
If UPDF is limited to Unix, how is it better than today's solution - PPD?
I understand that one of the goals for UPDF is to support both
Postscript and non-Postscript printers. But while PPD handles PS only,
it does it nicely on all platforms not just Unix.
[Sandra Matts] Good point. If we start scoping down the project
in order to get it done, we have to make sure we don't eliminate
the features that make it better and that solve the original problem.
My other thought: Is non-Postscript printing on Unix the biggest problem
that UPDF is aiming to solve or the easiest problem to solve? If it's
the biggest problem, then you may be heading in the right direction as
long as you promise adding more platforms later. If on the other hand,
you are doing it just for the sake of scoping down the project then I
disagree with the direction.
Finally, as you know, Apple's Mac OS X at the low level is Unix based so
there may be ways we can support your new direction but I cannot say for
sure until I see a better definition of the new UPDF proposal. At
minimum, the XML portion of a UPDF file could easily be handled on OS X
since the new OS already handles XML parsing at the system level. I'm
not sure about the optional code modules (the UI and rendering plugins) -
whether these binaries will be compatible or not.
[Sandra Matts] In order to keep it useful for the largest number of OSs - we should
do as much specification in XML and only resort to binaries when absolutely needed.
These are my thoughts at this time. Sorry for not being able to
contribute much to this project. But I'm still watching and tracking it
> Chuck sent out the DTD vs Schema link. This is something to look
>please check out the UIML and XUL documents for User Interface
>(208) 396-4755 phone
>(208) 396-5161 fax