Ira,
There are are a few places where "Unknown" was purposely set to either all uppercase or lowercase. It was so the values matched the associated external definitions (i.e., charset, MIME type, OS name). Here are the affected WKVs:
lowercase: CharsetWKV(unknown-8bit), DocumentFormatWKV
Uppercase: OperatingSystemNameWKV
Fixed to titlecase: ConnectionFailReasonWKV, PowerRequestStatusWKV
I have no issue with the way the SM handles SystemGeoLocation. An empty SystemGeoLocation maps to no-value. I agree that every printer has geographic location. I do not agree it has a GeoLocation until a geolocation component has instrumented the data or it has been administratively set. (probably set with data from a geolocation component) If the printer has a geolocation component and was unable to triangulate its position, i'd say the SystemGeoLocation was unknown.
I would prefer to interpret an empty SystemGeoLocation as no-value. I would prefer to use the IPP 'no-value' tag with printer-geo-location regardless of the reason. I could live with using the IPP 'unknown' tag for instrumentation failure.
Pete
-----Original Message-----
From: ipp-bounces at pwg.org on behalf of Ira McDonald
Sent: Thu 9/15/2011 3:44 PM
To: Michael Sweet; Ira McDonald
Cc: ipp at pwg.org
Subject: Re: [IPP] Use of unknown and no-value attribute value tags
Hi Mike,
"unknown" is used 39 places in PwgWellKnownValues.xsd
in three spellings - unknown, Unknown, and UNKNOWN
- oof! - needs work here...
In PWG SM, SystemGeoLocation is of datatype "xs:anyURI"
with a reference to RFC 5870 ('geo' URI Scheme). "unknown"
is an obviously illegal value, while the empty string can be and
is construed as "unknown" in MFD Model [PWG5108.01].
Cheers,
- Ira
Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Co-Chair - IEEE-ISTO PWG IPP WG
Chair - TCG Embedded Systems Hardcopy SWG
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
Christmas through April:
579 Park Place Saline, MI 48176
734-944-0094
May to Christmas:
PO Box 221 Grand Marais, MI 49839
906-494-2434
On Thu, Sep 15, 2011 at 6:16 PM, Michael Sweet <msweet at apple.com> wrote:
> Ira,
>> Semantically-speaking "unknown" and "no-value" do mean different things:
>> unknown: There is a value but we don't know what it is.
> no-value: We know there is no value.
>> Clearly every printer has a geographic location (and thus a value exists),
> however the value of that location may not be known because nobody has
> entered one and/or the printer has no way to get its location automatically.
> While we certainly could use "no-value" for printer-geo-location and treat
> it as "no value set", I like using a more specific tag if one exists.
>> That said, I wonder - how does the Semantic Model map "unknown" to the XML
> schema?
> (or does it?) If there isn't a mapping of unknown then I would suggest we
> formally deprecate the "unknown" value tag and use "no-value" for
> printer-geo-location as you suggest - it hasn't been used widely (or at all
> as far as I can see) and I don't want to depend on something that can't be
> mapped to another protocol binding.
>>> On Sep 15, 2011, at 3:05 PM, Ira McDonald wrote:
>> Hi Mike,
>> I like all of it, except that in printer-geo-location we should
> get rid of that MIB-centric "unknown" and instead use the
> semantically equivalent "no-value".
>> Cheers,
> - Ira
>> Ira McDonald (Musician / Software Architect)
> Chair - Linux Foundation Open Printing WG
> Co-Chair - IEEE-ISTO PWG IPP WG
> Chair - TCG Embedded Systems Hardcopy SWG
> 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> Christmas through April:
> 579 Park Place Saline, MI 48176
> 734-944-0094
> May to Christmas:
> PO Box 221 Grand Marais, MI 49839
> 906-494-2434
>>>> On Thu, Sep 15, 2011 at 5:56 PM, Michael Sweet <msweet at apple.com> wrote:
>>> All,
>>>> I've received a few queries about how the "unknown" and "no-value"
>> attribute value tags are used in IPP recently. What I've been telling
>> people is basically the following, but I'd like to document this somewhere,
>> perhaps as an errata for one of the IPP RFCs (probably RFC 2911 and 3380)
>> along with some updates to the IPP registry for the affected attributes.
>>>> Comments?
>>>>>> The "no-value" Attribute Value Tag
>>>> This value may be set or returned for any settable Job, Subscription, or
>> Printer attribute. The typical usage is to specify an xxx-default Job
>> Template attribute that has no default value, such as
>> "orientation-requested-default" - in that case the Printer may apply a
>> default based on the document such as automatically applying
>> "orientation-requested" with a value of 4 (landscape) for a landscape
>> document.
>>>> The "no-value" value may also be returned for read-only description
>> attributes that are a mandatory part of an object. For example, the Job
>> object's "time-at-completion" attribute can be returned as "no-value" when
>> the Job has not yet entered a terminating state.
>>>>>> The "unknown" Attribute Value Tag
>>>> This value may only be set or returned for specific Printer attributes.
>> Currently only the proposed "printer-geo-location" attribute has been
>> defined to potentially have an "unknown" value.
>>>>>> __________________________________________________
>> 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.
>>>> _______________________________________________
>> ipp mailing list
>>ipp at pwg.org>>https://www.pwg.org/mailman/listinfo/ipp>>>>>> __________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
>>
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.