WBMM> Re: Need quick decisions on schema changes

WBMM> Re: Need quick decisions on schema changes

McDonald, Ira imcdonald at sharplabs.com
Thu Jun 3 14:39:01 EDT 2004


Hi,
 
I'm delighted to define Resource object in WIMS spec - it's already been
defined
in IPP 4 years ago - we've reviewed my Resource schema (and requested only 
slight changes) - I can write the WIMS appendix.
 
I'm also delighted to define Subscription object in WIMS spec - PSI doesn't
need
it, but WIMS does - WIMS already has to define Alert object (see the
schema),
so this is consistent - I can write the WIMS appendices.
 
The difficulty with the Resource events (and any other non-Printer events)
is that
for some months (while it's approved and adopted and finally posted) the
Events
schema MUST remain unchanged.  A way forward is to let PSI also formalize
the Events schema (Printer-only) and publish it.  Meanwhile, continue to use
an expanded version of Events schema in WIMS directory for WIMS development.
 
I dislike removing the WIMS Management and Admin actions from either the
Schedule schema or the WIMS spec.  They're well-specified and work fine now.
 
In order to have even Counters for non-print services in an XML schema, WIMS
is going to have to define at least System object (and probably Service) and
WIMS
can't wait for some hypothetical future MFP WG to define them.
 
My two cents,
- Ira
 

Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: imcdonald at sharplabs.com 

-----Original Message-----
From: Harry Lewis [mailto:harryl at us.ibm.com]
Sent: Thursday, June 03, 2004 2:48 AM
To: Wagner,William
Cc: McDonald, Ira; Zehler, Peter; wbmm at pwg.org
Subject: RE: WBMM> Re: Need quick decisions on schema changes



I agree with Bill's points and I believe they show us a way forward. I share
Bill's concern that we need to avoid getting tangled in our own shorts (that
is the way Bill put it... isn't it ;-). I believe what still needs to be
sorted out is how much (or little) skeleton imaging system model do we need
(or can we get by with) to support the (appropriately) limited initial WIMS
scope yet not block or disrupt a future SM expansion embracing the MFP,
entirely.   
---------------------------------------------- 
Harry Lewis 
Chairman - IEEE-ISTO Printer Working Group
http://www.pwg.org
IBM Printing Systems 
http://www.ibm.com/printers
303-924-5337
---------------------------------------------- 



"Wagner,William" <WWagner at NetSilicon.com> 
Sent by: owner-wbmm at pwg.org 


06/03/2004 12:07 AM 


To
"McDonald, Ira" <imcdonald at sharplabs.com>, "Zehler, Peter"
<PZehler at crt.xerox.com> 

cc
<wbmm at pwg.org> 

Subject
RE: WBMM> Re: Need quick decisions on schema changes

	




I agree with Harry and Pete on most things, and I will admit to not
following how your argument below applies  to their objections (nor, indeed,
many of your other undoubtedly logical relationships) 
  
Although having everything follow a grand scheme is desirable, the effect
appears to introduce so much interdependency that everything requires that
everything else be done, thereby defeating the ability to complete anything.
Since PSI deals only with printers but needs alerts  done, why can it define
just printer alerts (and perhaps general alerts)? Alerts for WIMS would be
the combination of printer alerts, scanner alerts, fax alerts, resource
alerts etc, as these become defined. Dropping the register for alerts
capability because the only alerts we can currently support are printer
related seems undesirable. 
  
  
With respect to  "Does WIMS WG accept the need to model Resource?",  it is
unclear to  me what other group  would do this. Although I would not put
this on high priority, I would prefer not to loose Resource.  Again, since
we may not at this time fully understand all the aspects of Resource,  can
we not work with a skeleton model, filling it out later? 
  
I  understand the notion that the current semantic model is only for
printers, and that elements belonging to  a non-printer part of an MFP  need
to be in some other part of the semantic model. As such, forcing them into
WIMS at this time may upset the future logical model if it cannot be remove
from WIMS in favor of a reference to a more general semantic model at a
later time. 
  
Indeed, the compromise forcing these cuts was in response to the
understanding that we needed your skeleton imaging device model  filled out
before we could use it, and that it was unclear when (and if) that would be
done. But it seems that we need some interim way of handling references,
realizing that they may change in  detail and completeness. 
  
Anyway, it would seem that, insofar as the schema are informational adjuncts
to the spec, the changes you identify must also be reflected in the spec. I
would, however, like to wait until the smoke clears before making those
changes. 
  
Thanks for your continuing efforts. 
  
Bill Wagner 
  
  
  
 -----Original Message-----
From: McDonald, Ira [mailto:imcdonald at sharplabs.com]
Sent: Wednesday, June 02, 2004 4:20 PM
To: 'Zehler, Peter'; McDonald, Ira
Cc: 'wbmm at pwg.org'; Wagner,William
Subject: RE: WBMM> Re: Need quick decisions on schema changes

Hi, 
  
For PSI to advance, the Events spec (psievents10) and the Events 
schema MUST be formally approved for addition to the next version 
of the Semantic Model. 
  
Because there is no such thing as a Resource or a _Subscription_ 
defined in any standards-track IETF or PWG approved spec, 
there CANNOT be any Resource operations or events in WIMS. 
  
And more cogently, there CANNOT be any Subscription object 
defined in the Alert schema (so there is no source for the element 
bindings of most Alert types).  So RegisterForAlerts doesn't work. 
  
This just gets worse... 
---- 
  
The PWG Semantic Model element PrinterOperationsSupported 
ONLY contains the base IPP/1.1 operations.  There is no obvious 
way that it could easily be extended to cover all PSI operations, 
WIMS operations, etc. 
  
And arguably, the PWG SM/1.0 Printer object should NOT be 
the source of any WIMS connection.  The abstract System or 
Service object in front of Printer should start WIMS connections. 
  
Near-term the WIMS Agent should NOT be conflated with Printer. 
---- 
Cheers, 
- Ira 
  

Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: imcdonald at sharplabs.com 


-----Original Message-----
From: Zehler, Peter [mailto:PZehler at crt.xerox.com]
Sent: Wednesday, June 02, 2004 2:36 PM
To: McDonald, Ira
Cc: 'wbmm at pwg.org'; 'Wagner,William'
Subject: RE: WBMM> Re: Need quick decisions on schema changes

Ira, 
Harry covered my views.  My inserts are only on 7 & 8. 
  
Peter Zehler 
XEROX 
Xerox Innovation Group 
Email: PZehler at crt.xerox.com 
Voice:    (585) 265-8755 
FAX:      (585) 422-7961 
US Mail: Peter Zehler
             Xerox Corp. 
             800 Phillips Rd. 
             M/S 128-25E 
             Webster NY, 14580-9701 
  
-----Original Message-----
From: Harry Lewis [mailto:harryl at us.ibm.com] 
Sent: Wednesday, June 02, 2004 1:57 PM
To: McDonald, Ira
Cc: 'wbmm at pwg.org'; 'Wagner,William'
Subject: WBMM> Re: Need quick decisions on schema changes 
  

Inserted... 
---------------------------------------------- 
Harry Lewis 
Chairman - IEEE-ISTO Printer Working Group
http://www.pwg.org
IBM Printing Systems 
http://www.ibm.com/printers
303-924-5337
---------------------------------------------- 




"McDonald, Ira" <imcdonald at sharplabs.com> 


06/02/2004 11:47 AM 




To
"'wbmm at pwg.org'" <wbmm at pwg.org> 

cc
"'Wagner,William'" <WWagner at NetSilicon.com>, Harry Lewis/Boulder/IBM at IBMUS 

Subject
Need quick decisions on schema changes

  




  	 






Hi, 

PLEASE answer quickly with your opinions on edits below, 
so I can begin the edits needed in all of the WIMS schema 
after last week's PWG Vancouver meetings. 


Last week, we reduced the scope of the PWG Std Events spec 
and Events schema to Printer-only (Printer, Job, Document, 
and Subunit).  Fine, but... 


(1) Alerts schema - Should I delete 'AlertResource'? 


    - it depended on the now _deleted_ ResourceXxx events 
    in the Events schema and Resource object in the 
    (abandoned) Imaging System Model draft 


HL - Yes, for now... but we need to put these back in later 


(2) Alerts schema - Should I change 'NotifySourceState' 
  to delete 'Testing' and 'Down' from 'hrDeviceStatus' 
  in Host Resources MIB (RFC 2790)? 


    - this change will make support of coherent Printer 
    state harder to harmonize with HR MIB 
  - I think that it's a bug that Printer state in IPP/1.1 
    requires state reasons to report Down or Testing 


HL - No 


(3) Alerts schema - Should I rename 'NotifySourceState' 
  to 'NotifyPrinterState' and 'NotifySourceURI' to 
  'NotifyPrinterURI'? 


    - doing so effectively closes the future possibility 
    of multifunction alert support in WIMS 


HL - No! 


(4) Resource schema - Should we abandon this schema? 


    - last week's meeting seemed against adding any 
    new objects except in some future PWG MFP Model 
  - abandoning Resources seems foolish to me 


 HL -   Seems foolish to me too. Don't like the word abandon. Prefer
"staging" 



(5) Schedule schema - Should I reorganize it into 
  the three Monitoring, Management, and Admin groups 
  of Actions? 


    - this seems worthwhile, as it describes WIMS levels 
    better 


HL - Yes 


(6) Schedule schema - Should I delete Resource actions? 


    - Does WIMS WG accept the need to model Resource? 


HL - No (Yes... but possibly at a later "stage") 


(7) Schedule schema - Should I import 'NotifyEvents' from 
  the Events schema? 
  
  - this looks better, but again loses Resources 


HL - Not sure... why does this loose Resources... because event schema
requirments are being driven by PSI? Seems incorrect. 


            <PZ>I don't understand this one either</PZ> 


(8) Schedule schema - Should I add the elements for 
  Supported[Operations|Actions|Objects] here, so 
  that RegisterForManagement operation works? 


    - the WIMS operations won't appear in any generic 
    PWG Semantic Model element in the forseeable future 


HL - why do you say the WIMS ops won't appear in SM? Do you mean just the
admin related Ops? 


            <PZ>This would seem to be a straight forward extension and could
be added to the Schema easily, captured as a Semantic Model extension and
picked up in the next version of the PWG Semantic Model spec</PZ> 



Cheers, 
- Ira 


Ira McDonald (Musician / Software Architect) 
Blue Roof Music / High North Inc 
PO Box 221  Grand Marais, MI  49839 
phone: +1-906-494-2434 
email: imcdonald at sharplabs.com 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.pwg.org/archives/wims/attachments/20040603/103789ca/attachment-0001.html


More information about the Wims mailing list