Many thanks Kelli, for the Webex and for the management model requirements update. I have (or shortly will) add this to the FTP site in PDF format.
With respect to your questions:
1. I think that we may be a little out of sync on the distinction between devices and services. I am curious about the reaction to my sketch that Harry included in last week's minutes. I rather expected some objections. But as I see it, the device model evolves largely out of the MIB. The service model (for printing at least) evolves largely out of the PWG Semantics. A device (if it is much use) will be performing some services. So the management model of a physical printer will include both device and service aspects.
I do not see these as different models in terms of structure, but rather different parts of a unified model, realizing that in a particular instance only some portions of the model may be applicable.
Indeed, I would prefer that this list of model requirements not be limited to device model, with a separate list for service model requirements, although some requirements may be more applicable to one than to the other.
However, I agree that a consideration of what might be considered PSI requirements would be both helpful and instructive.
2. I also am getting a little foggy about how WDSL defining the protocol fits into the management model, although the idea of a grand model that encompasses everything may sound appealing. But it seems a bit incestuous for the model to describe both the object (what is being managed and the subject (what is managing, or at least communicating the management information).
3. Again, I may be out of sync here, but I think that there is no one single way in which management information is being consumed. The idea I thought was evolving was that WBMM would define a type of structure, and provide a library of elements to populate that structure. It might even define a minimal populated model. But different classes of application would populate this structure with specific schema. Perhaps, we would be designing a model of a model and some typical application models.
This is an important point, since in conceptualizing WBMM operations full flexibility would require configuration options that allow a management interface (device or service) to identify the elements that it supports, and the manager to define how these elements are to be structured. This would be fairly complicated. It could be simplified by having predefined structures, and a simple management interface would just respond with the structures that it supports.
I think we have some material for discussion here. I will also send out some other ideas relative to defining the protocol at a conceptual level, and the updated charter draft.
Hope to have substantial participation since the objective right now is to complete and distribute WBMM phase 1 documents for PWG consideration at the June meeting.
From: KENNEDY,KELLI (HP-Boise,ex1) [mailto:kelli.kennedy at hp.com]
Sent: Tuesday, May 27, 2003 10:56 AM
To: 'wbmm at pwg.org'
Subject: WBMM> requirements for the device model
I just posted an updated list of the requirements for the *device model*
with changes from our last meeting. It is called Brainstorm5-21_v2.doc.
(Sorry that it is only in Word, but I don't yet have Acrobat).
There are still several issues:
1) Does the group agree that WBMM needs to manage software services distinct
from devices? Could someone provide me with an example of what might need
to be managed for a PSI service?
2) I don't think that the requirements for the *device model* should contain
anything about WSDL. This seems to fit better into the requirements for the
*protocol* because when you define how to interact with a web service, you
are essentially defining a protocol.
3) There was not agreement that the model should be structured around how
the information is consumed, rather than the physical structure of the
device. We need more discussion around this.
If anyone has any other requirements for the device model they would like me
to add to the list, feel free to send them to me.