Hi Paul,
In many cases inter-attribute constraints are implementation-defined rather
than being
statically spec-defined.
IPP Everywhere has a standard mechanism for discovering inter-attribute
constraints
(supported in the PWG SM XML Schema).
This information does not belong in a PWG SM 2.0 architecture spec IMHO.
Cheers,
- Ira
Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - TCG Embedded Systems Hardcopy SG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music/High North Inc
http://sites.google.com/site/blueroofmusichttp://sites.google.com/site/highnorthinc
mailto:blueroofmusic at gmail.com
Winter 579 Park Place Saline, MI 48176 734-944-0094
Summer PO Box 221 Grand Marais, MI 49839 906-494-2434
On Sat, Jul 6, 2013 at 9:15 PM, Paul Tykodi <ptykodi at tykodi.com> wrote:
> Hi,****
>> ** **
>> I might not have expressed the concept that Pete described to me
> correctly. With PPD files, there is frequently a large section describing
> UI Constraints. These are lists of items that customers cannot use
> together. If they try to select a set of options not supported by the
> target device, some type of visual error icon is displayed to show them
> what options cannot be used together.****
>> ** **
>> The constraints that Pete mentioned, which could not be represented in the
> XML, were the PWG elements that couldn’t be used together. He was not
> referring to constraints regarding how information is formatted for a
> particular element.****
>> ** **
>> He told me that the constraints describing PWG elements that cannot be
> used together have previously been documented in the tables.****
>> ** **
>> I was speaking about these particular constraints when I put forward the
> question as to whether we might want to consider listing them together in
> their own section.****
>> ** **
>> Best Regards,****
>> ** **
>> /Paul****
>> --****
>> Paul Tykodi
> Principal Consultant
> TCS - Tykodi Consulting Services LLC
>> Tel/Fax: 603-343-1820
> Mobile: 603-866-0712
> E-mail: ptykodi at tykodi.com> WWW: http://www.tykodi.com****>> *From:* Ira McDonald [mailto:blueroofmusic at gmail.com]
> *Sent:* Saturday, July 06, 2013 2:17 PM
> *To:* William A Wagner; Ira McDonald
> *Cc:* Paul Tykodi; Michael Sweet; mfd at pwg.org>> *Subject:* Re: [MFD] Schema Element Table format for Imaging System Model
> Spec****
>> ** **
>> Hi Bill,****
>> I agree that listing constraints is busywork and error-prone - leave the
> constraints****
>> for the underlying IPP or MIB objects - they're reflected in the SM XML
> schema.****
>> Cheers,****
>> - Ira****
>>> ****
>> Ira McDonald (Musician / Software Architect)
> Chair - Linux Foundation Open Printing WG
> Secretary - IEEE-ISTO Printer Working Group
> Co-Chair - IEEE-ISTO PWG IPP WG
> Co-Chair - TCG Trusted Mobility Solutions WG
> Chair - TCG Embedded Systems Hardcopy SG
> IETF Designated Expert - IPP & Printer MIB
> Blue Roof Music/High North Inc
>http://sites.google.com/site/blueroofmusic>http://sites.google.com/site/highnorthinc> mailto:blueroofmusic at gmail.com> Winter 579 Park Place Saline, MI 48176 734-944-0094
> Summer PO Box 221 Grand Marais, MI 49839 906-494-2434****
>> ** **
>> On Sat, Jul 6, 2013 at 1:49 PM, William A Wagner <wamwagner at comcast.net>
> wrote:****
>> Paul and WG,****
>> From PWG 5105.1-2004 PWG Semantic Model (the initial print service
> model), constraints appear to be range or maxlength for integers, and Type
> X Keyword for strings. There are a few other sting constraints including
> DateTime, and Uri (?), Repertoire,, etc.****
>> ****
>> I suggest that to list all of the elements in a separate section with
> their ‘constraints’ would be cumbersome. Keyword values are already
> listed and we could add type ID to that listing. Numeric integer
> constraints (0:MAX, 1:MAX, MIN:MAX, Maxlength=1023, Maxlength=127,
> Maxlength=63, Maxlength=255, Maxlength=40) seem to be of a limited number
> of values, and could be addressed in the element tables with notes. Other
> strings could be identified in the description. ****
>> ****
>> Note however that, with few a exceptions, this document does not define
> the non-complex elements; it provides a reference to their definition. So
> constraints for such elements may be helpful, but would not appear to be
> critical. These were not included in the MFD Model specification.****
>> ****
>> I solicit comments from the rest of the SM Working Group.****
>> Thanks.****
>> Bill Wagner****
>> ****
>> ****
>> ****
>> ****
>> ****
>> *From:* Paul Tykodi [mailto:ptykodi at tykodi.com]
> *Sent:* Wednesday, July 03, 2013 5:36 PM
> *To:* 'Michael Sweet'; 'William A Wagner'
> *Cc:* mfd at pwg.org> *Subject:* RE: [MFD] Schema Element Table format for Imaging System Model
> Spec****
>> ****
>> Hi Bill,****
>> ****
>> I prefer the last format as well.****
>> ****
>> One of the things I just learned from Pete, when he was briefing me on
> what I need to know for validating the Schema diagrams in section 5 (System
> Configuration) of the draft SM 2.0 document, was that Inter-elemental
> Constraints cannot be shown in the XML and the text representation in the
> tables is used to describe the constraints.****
>> ****
>> I don’t know whether we might want to consider creating a specific section
> in the SM 2.0 document for describing the constraints or not.****
>> ****
>> Best Regards,****
>> ****
>> /Paul****
>> --****
>> Paul Tykodi
> Principal Consultant
> TCS - Tykodi Consulting Services LLC
>> Tel/Fax: 603-343-1820
> Mobile: 603-866-0712
> E-mail: ptykodi at tykodi.com> WWW: http://www.tykodi.com****>> *From:* mfd-bounces at pwg.org [mailto:mfd-bounces at pwg.org<mfd-bounces at pwg.org>]
> *On Behalf Of *Michael Sweet
> *Sent:* Wednesday, July 03, 2013 4:43 PM
> *To:* William A Wagner
> *Cc:* mfd at pwg.org> *Subject:* Re: [MFD] Schema Element Table format for Imaging System Model
> Spec****
>> ****
>> I prefer the last format (what was used in the MFD Common Semantics and
> Model)...****
>> ****
>> On 2013-07-03, at 4:12 PM, William A Wagner <wamwagner at comcast.net> wrote:
> ****
>> ****
>> The Imaging System Semantics and Model V2 will include and update
> information from MFD Common Semantics and Model and the previous Service
> specifications. Much of the contents of these documents consists of showing
> hierarchical Schema graphics followed by detailed descriptions of the
> elements in the diagram. The earlier documents used three different
> approaches for these descriptions, as indicated in the discussion document
> posted at****
>>ftp://ftp.pwg.org/pub/pwg/mfd/white/table_format_examples.pdf****>> Each approach had its proponents and detractors. The most common format
> was the single row per entry table used in the MFD Common Semantics and
> model.****
>> ****
>> The Imaging System document should use a consistent approach for this
> explanation of schema elements. Although difficulty in implementing the
> format should be considered, it is also important that the approach be
> useful and effective in describing the schema. The three formats are
> described to allow a working group consideration and decision, hopefully by
> the next Semantic Model WG conference call.****
>> Thanks,****
>> Bill Wagne****
>> ****
>>> --
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean. _______________________________________________
> mfd mailing list
>mfd at pwg.org>https://www.pwg.org/mailman/listinfo/mfd****>> ****
>> _________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair****
>> ****
>>> --
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean. ****
>>> --
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean. ****
>>> _______________________________________________
> mfd mailing list
>mfd at pwg.org>https://www.pwg.org/mailman/listinfo/mfd****>> ** **
>
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/mfd/attachments/20130708/9139eedf/attachment-0002.html>