Apparently I did not make myself clear the last time.
Let me try again.
ScanService.xsd
All I suggested was a name change for the element ContentRegionsUnits.
Proposed change: RegionUnits
Reason: that term is used in other areas of PWG schemas. It would be more consistent.
I did not propose any type changes.
I could imagine (but did not request) to rename the type ContentRegionUnitsType (all of its appearances) to RegionUnitsType, although the type does not appear in xml instances and is therefore not as apparent. But a change may improve readability in general.
When studying various PWG schemas, the general use of terms seems to be:
- RegionUnit and similar names refer to just one list of TenThousandsOfInches, etc.
- ContentRegionUnit and similar names refer to a more complex object including width and height and others.
The other change I suggested is rather general.
Various PWG objects show an excellent type definition. InputSource and DocumentFormat in the ScanService schema are just examples.
If one has 2 objects of the same type (e.g. 2 ADF input sources with 1 device), it helps to have 2 parameters to refer to the objects:
- a classifying ID: the types InputSourceType and DocumentFormatType of AllowedValue(s) elements are perfect for that. No change requested at all.
- a unique ID: its only purpose is to be unique. There are 2 ways to prepare for that.
1. An ID could be added similar to the proposed change below. But the type of this ID should be 'xsd:ID'. A type of string or int would also work, but then it's the responsibility of the editing person to care for the uniqueness. This ID must not be of type InputSourceType nor DocumentFormatType.
2. an 'any' element could be added. So somebody like me would add such an ID element to the instance.
I am not asking for any change in the classification of objects, not for input sources, document formats nor any other object.
I hope this clears some confusion.
Norbert
-----Original Message-----
From: sm3-bounces at pwg.org [mailto:sm3-bounces at pwg.org] On Behalf Of Zehler, Peter
Sent: Wednesday, March 12, 2014 7:18 AM
To: Semantic Model 3.0 Workgroup discussion list
Subject: [SM3] Don't change DocumentFormat! (RE: SM3 Meeting Minutes - 10 Mar, 2014)
All,
I don't think you should touch "DocumentFormat" ("document-format in IPP). This is a simple MIME Type string that has been around since the beginning of IPP. Changing it will break a lot of implementations. Have you looked at "DocumentFormatDetails" ("document-format-details" in IPP) that was defined in PWG5100.5 and PWG5100.7? This gives you what you want and more.
Pete
Peter Zehler
Xerox Research Center Webster
Email: Peter.Zehler at Xerox.com
Office: +1 (585) 265-8755
Mobile: +1 (585) 329-9508
FAX: +1 (585) 265-7441
US Mail: Peter Zehler
Xerox Corp.
800 Phillips Rd.
M/S 128-25E
Webster NY, 14580-9701
-----Original Message-----
From: sm3-bounces at pwg.org [mailto:sm3-bounces at pwg.org] On Behalf Of Manchala, Daniel
Sent: Monday, March 10, 2014 5:38 PM
To: 'sm3 at pwg.org'
Subject: [SM3] SM3 Meeting Minutes - 10 Mar, 2014.
Meeting Attendees:
Rick Yardumian (Canon)
Bill Wagner (TIC)
Norbert Schade (Conexant)
Daniel Manchala (Xerox)
The Working Group discussed some inconsistencies in the SM schema pointed out by Norbert. Here are some of them that need to be corrected (or improved) - particularly the schema elements defined in the Scan Service.
ScanService.xsd has the following element definition for "ImageBox".
===============
<xs:element name="ImageBox">
<xs:complexType>
<xs:sequence>
<xs:element name="Height" type="RangeOfIntType"/>
<xs:element name="Width" type="RangeOfIntType"/>
<xs:element name="XOffset" type="RangeOfIntType" minOccurs="0"/>
<xs:element name="YOffset" type="RangeOfIntType" minOccurs="0"/>
<xs:element name="ContentRegionUnits">/* This needs to be changed to "RegionUnits" */
<xs:complexType>
<xs:sequence>
<xs:element name="AllowedValues" type="ContentRegionUnitsType" maxOccurs="unbounded"/> /* May need to be changed to "RegionUnitType */
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
The element name "ContentRegionUnits" may need to be replaced with "RegionUnits" as a comparison with PwgCommon.xsd will reveal.
=============
<xs:complexType name="ContentRegionType">
<xs:sequence>
<xs:element ref="pwg:Height"/>
<xs:element ref="pwg:Width"/>
<xs:element ref="pwg:XOffset" minOccurs="0"/>
<xs:element ref="pwg:YOffset" minOccurs="0"/>
<xs:element ref="RegionUnits"/> /* This is correct. It was called "ContentRegionUnits" in ScanService.xsd */
<xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType>
Likewise, a similar change may need to be performed in the PwgWellKnownValues.xsd
======================= <xs:simpleType name="ContentRegionUnitWKV"> /* This needs to be changed to "RegionUnitsWKV" */
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="Other"/>
<xs:enumeration value="Unknown"/>
<xs:enumeration value="TenThousandthsOfInches"/>
<xs:enumeration value="Micrometers"/>
<xs:enumeration value="Pixels"/>
<xs:enumeration value="Percent"/>
</xs:restriction>
</xs:simpleType>
------------------ Allow multiple objects with same type.
Certain Scan Service elements can be enhanced to allow multiple objects with same type to be available in the service. For example, there could be two ADFs (ADF-upper and ADF-side) of the same type (ADF) on the same device / service. In order to do this, Norbert suggested adding an ID or make it extensible (via "any namespace=##other").
What we have in ScanService.xsd and what may need to be added.
================
<xs:element name="InputSource" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:element name="AllowedValues" type="InputSourceType" maxOccurs="unbounded"/>
<xs:element name="ID" type="InputSourceType" maxOccurs="unbounded" /> /* This needs to be added */
</xs:sequence>
</xs:complexType>
</xs:element>
Likewise, another element that needs to be modified is DocumentFormat (allowing not only different formats for scan capture viz. PDF, TIFF, PwgRaster, etc., but also allowing different versions of a format viz. TIFF1, TIFF2, etc).
<xs:element name="DocumentFormat" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:element name="AllowedValue" type="DocumentFormatType" maxOccurs="unbounded"/>
<xs:element name="ID" type="DocumentFormatType" maxOccurs="unbounded" /> /* This needs to be added */ </xs:sequence>
</xs:complexType>
</xs:element>
------------------Question on the need to replace InputSourceType.
Bill mentioned that it was discussed in the IPP Scan meeting there was a need to replace InputSourceType with some other element that captures the characteristics of input sources other than ADF, Platen, etc., and which also takes other elements such as scanner resolution, encoding, etc. Ira/Mike might know this better.
_______________________________________________
sm3 mailing list
sm3 at pwg.orghttps://www.pwg.org/mailman/listinfo/sm3
_______________________________________________
sm3 mailing list
sm3 at pwg.orghttps://www.pwg.org/mailman/listinfo/sm3
Conexant E-mail Firewall (Conexant.Com) made the following annotations
---------------------------------------------------------------------
********************** Legal Disclaimer ****************************
"This email may contain confidential and privileged material for the sole use of the intended recipient. Any unauthorized review, use or distribution by others is strictly prohibited. If you have received the message in error, please advise the sender by reply email and delete the message. Thank you."
**********************************************************************
---------------------------------------------------------------------