Title of Invention

XML PRINTER SYSTEM

Abstract An XML printer system adapted to print bar code labels based upon an extensible markup language (XML} input data stream, the XML printer system including a printer apparatus having a media control system, a print head assembly, and a print head driver, the XML printer system comprising: a computer system operatively coupled to the printer apparatus; the computer system farther including: an XML processor configured to receive and process the XML input data stream so as to generate formatted XML data based m part upon extensible stylesheet language formatting object (XSLFO) instructions contained in the XML input, data stream; and a barcode rendering subsystem configured to receive the formatted XML data and generate a bit map representative of the bar code label.
Full Text Original
FORM 2
THE PATENTS ACT, 1970 (39 of 1970)
COMPLETE SPECIFICATION (See Section 10, rule 13)
XML PRINTER SYSTEM
ZIH CORP. of 3, GORHAM ROAD, HAMILTON HM08, BERMUDA, BERMUDA Company
The following specification particularly describes the nature of the invention and the manner in which it is to be performed : -
GRANTED
12-5-2004

WO 03/052658

PCT/US02/36322

XML PRINTER SYSTEM
CROSS-REFERENCE TO RELATED APPLICATIONS
This application claims the benefit of priority from co-pending provisional patent application U.S. Serial No. 60/345,389, filed January 4, 2002, entitled XML Printer Technology, from co-pending provisional patent application U.S. Serial No. 60/341,427, filed December 17, 2001, entitled Bar Code Labeling Systems Having Machine Readable Standards, and from co-pending non-provisional application U.S. Serial No. 10/197,014, filed on July 17, 2002, entitled Native XML Printer. Provisional patent application Serial Nos. 60/345,389 and 60/341,427 are incorporated herein by reference in their entirety. This application is a continuation-in-part of application U.S. Serial No. 10/197,014, filed July 17, 2002, entitled Native XML Printer.
STATEMENT REGARDING COPYRIGHT RIGHTS
A portion of this disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office Patent files or records, but otherwise reserves all copyright rights whatsoever.
FIELD OF THE INVENTION
The present invention relates generally to a method and apparatus for printing bar code labels and more specifically in one embodiment, to an XML (Extensible Mark-up Language) printer that prints bar code labels based on an XML data stream using existing ZPL-based (Zebra Programming Language) format template.
BACKGROUND
Printer systems for printing barcodes and for transmitting data to a barcode printer are known. However, many such systems use proprietary methods of data encoding, and therefore such methods cannot be used interchangeably with other barcode printers. Also, known data encoding methods typically render the underlying data unreadable by humans. While this presents no impediment to the computer systems, it may be burdensome to humans attempting

WO 03/052658

PCT/US02/36322

to review, debug or understand certain data appearing in the underlying barcode element names. In that regard, XML is an open standard that is being adopted by many business entities and is human-readable. Use of XML may avoid many of the problems and pitfalls associated with non-human readable methods.
Barcode labeling is used extensively in many facets of commerce. In particular, packages or merchandise shipped from one destination to another are identified by the shipper by a specific barcode label. Conversely, merchandise received may also be identified and entered into the receiver's inventory system by use of the barcode label. Often, the receiver of merchandise may dictate the form and content of the barcode applied by the shipper. This is referred to as "compliance labeling." Of course, merchandise need not be shipped to avail itself of the benefits of barcode labeling. For example, inventory control systems make extensive use of barcode labeling to track and monitor various goods within a facility or between facilities.
Compliance labeling is typically used by buyers of merchandise having relatively large market power or purchasing power. Because of their economic power, they may be able to dictate the form and content of the barcode labels applied to products provided to them by their suppliers or vendors. Although this may be burdensome to the supplier, if the supplier desires to do business with the buyer, they must comply with their demands with respect to labeling. For example, large retailers, such as Wal-Mart, Inc., not only have the ability and purchasing power to require that suppliers meet their compliance labeling demands, but may also fine suppliers who fail to comply with the labeling requirements.
Further, such barcode labeling requirements may change at the whim of the entity demanding compliance. Accordingly, the supplier must implement the new labeling requirements and test the modified barcode to insure that it meets all specifications. This is relatively inefficient and time consuming. It is also prone to errors, which may translate into monetary fines.
A need exists to permit an enterprise resource planning system (ERP) to format its data for transmission to a barcode printer system in XML, while additionally making use of existing ZPL format templates that govern the layout of the label and/or by making use of a pure XML format template that uses XSL (extensible stylesheet language) to govern the


WO 03/052658

PCT/US02/36322

layout of the label to be printed.
BRIEF DESCRIPTION OF THE DRAWINGS
The features of the present invention which are believed to be novel are set forth with particularity in the appended claims. The invention, together with further objects and advantages thereof, may best be understood by reference to the following description in conjunction with the accompanying drawings.
Fig. 1 is a high-level hardware block diagram of a specific embodiment of a printer system according to the present invention;
Fig. 2 is a high-level software block diagram of a specific embodiment of a printer system;
Fig. 3 is a combined high-level software block diagram and data flow diagram of a specific embodiment of a printer system;
Fig. 4 is a high-level software block diagram of a specific embodiment of a bitmap/barcode rendering engine;
Fig. 5 is a specific representation of a barcode label produced in accordance with the printer system of Figs. 1-4;
Fig. 6 is a specific example of an alternate embodiment of a printer system configured as a barcode rendering server;
Fig. 7 is a high-level software block diagram of a specific alternate embodiment of a printer system;
Fig. 8 is a combined high-level software block diagram and data flow diagram of a specific alternate embodiment of a printer system; and
Fig. 9 is a specific representation of a barcode label produced in accordance with the printer system of Figs. 7-8.
DETAILED DESCRIPTION
In this written description, the use of the disjunctive is intended to include the conjunctive. The use of definite or indefinite articles is not intended to indicate cardinality. In particular, a reference to "the" object or thing or "an" object or "a" thing is intended to also describe a plurality of such objects or things.
Referring now to Fig. 1, a specific embodiment of a high-level hardware block diagram


WO 03/052658

PCT/TJS02/36322

of an XML printer system 10 is shown generally. In the embodiment of Figs. 1-6, the native or natural "language" of the system is XML, thus the printer system 10 may be referred to as a "native XML printer." The XML printer system 10 includes a computer or processing system 12, which includes various hardware components, such as RAM 14, ROM 16, hard disk storage 18, cache memory 20, database storage 22, and the like (also referred to as "memory subsystem" 26), as is known in the art. The computer system 12 may include any suitable processing device 28, such as a computer, microprocessor, RISC processor (reduced instruction set computer), CISC processor (complex instruction set computer), mainframe computer, work station, single-chip computer, distributed processor, server, controller, micro¬controller, discrete logic computer and the like, as is known in the art. For example, the processing device 28 may be an Intel Pentium® microprocessor, x86 compatible microprocessor, or equivalent device.
A user interface 30 may be coupled to the computer system 12 and may include various input devices 36, such as switches selectable by the user and/or a keyboard. The user interface also may include suitable output devices 40, such as an LCD display, a CRT, various LED indicators and/or a speech output device, as is known in the art.
To communicate between the computer system 12 and external sources, a communication interface 42 may be operatively coupled to the computer system. The communication interface 42 may be, for example, a local area network, as an Ethernet network, intranet, or other suitable network 43. The communication interface 42 may also be connected to a public switched telephone network (PSTN) 46 or POTS (plain old telephone system), which may facilitate communication via the Internet-44. Dedicated and remote networks may also be employed. Any suitable commercially available communication device or network may be used, as is known in the art.
The computer system 12 is further coupled to a printer system 50. The printer system 50 may include a media/paper control system 52, a printer driver 54 and a print head mechanism 56. Any suitable printer capable of printing barcode labels may be used, which may include various dot matrix, ink jet, laser and/or thermal printers. Of course, dot matrix printers are usually of lower quality and require closer monitoring of the label output. Preferably, the printer system 50 is a thermal transfer printer. Such suitable printers, for example, are




WO 03/052658

PCT/US02/36322

available from Zebra Technologies Corporation of Vernon Hills, Illinois, and may include the Model Xi series barcode printers (XiIJI+, 90XiIII, 96XiIII, 140XiIII, 170XiIII, 220XiIII, etc.), the 2800 Series barcode printers, Model Z4M, Z6M, 105SL barcode printers, and others. Any suitable barcode label printer may be used.
Typically, such printers may include various motors, label cutters, ribbon handlers, sensors, and the like (not shown). Additionally, such printers may include various control inputs or sensors, such as a media sensor, print head temperature sensor, head open sensor, ribbon sensor, and the like (not shown), as is known in the art. The printer system 50 may include one or more additional processors 60, other than the processor 28 residing in the computer system 12. Alternatively, the processor 28 in the computer system 12, if sufficiently powerful, may control and handle the printer system 50 functions without the need for a separate processing device. Greater detail concerning the control of the print-head may be found in U.S. Patent No. 5,372,439 entitled "Thermal Transfer Printer With Controlled Ribbon Feed," issued December 13, 1994, and owned by the owner of the present invention. U.S. Patent No. 5,372,439 is hereby incorporated by reference in its entirety.
Preferably, the computer system 12 and the printer system 50 are located in a common enclosure, but need not necessarily be constructed in this manner. For example, the computer system 12 may be housed in an enclosure separate and apart from the printer system 50.
Referring now to Figs. 1-3, Fig. 2 illustrates a specific embodiment of a high-level software block diagram, while Fig. 3 illustrates a specific embodiment of a combined high-level software block diagram and data flow diagram. The software described below may be executed by the processor.28 of the computer system 12 of Fig. 1. Again, the processor 28 may perform functions common to both the computer system 12 and the printer system 50. There may be one or more processors, which may function in concert or which may function separately. It is not material to the scope of this invention whether the processing or processing functions are performed by or in the computer system or by or in the printer system.
The software blocks illustrated in Figs. 2-3 include an XML (extensible mark-up language) processor 70 (also referred to as the "XML parser"), an XSLT (extensible stylesheet language transformation) processor 74, an XSLFO (extensible stylesheet language


WO 03/052658

PCT/US02/36322

formatting object) processor 78, a barcode rendering engine 80 (also referred to as the "bitmap/barcode rendering engine"), and the printer driver 54 (Fig. 1). Note that the printer driver 54 is an example of a component described above whose function may be performed by either the processing device in the computer system 12 or the processing device 60 (Fig. 1) in the printer system 50, depending upon the physical location of the associated processing device. Again, a single processing device, if sufficiently powerful, may handle all functions for the XML printer system \0.
An XML schema repository 82 (schema repository) may provide input to the XML processor 70 while an XSLT stylesheet repository 84 (stylesheet repository) may provide input to the XSLT processor 74. Also shown is an enterprise resource planning (ERP) system 88, which may be, for example, a warehouse management system that transmits an XML input data stream 90 to the XML processor 70. The ERP system 88 essentially initiates the request to print the barcode label, and provides the XML data that forms the bar code and other variable label or element fields to be printed. Such variable label fields may include, for example, any or all of the human-readable text and/or characters printed on the label. Of course, any enterprise computer system may be used, and this invention is not limited to use with any specific type of enterprise computer system.
When referring to the XML data, two basic types shall be referred to herein, namely, the XML value data and the XML element name. The XML value data is the changeable data or the data that is desired to be printed on the barcode label, such as the data "1122 Green Street," which may be part of the XML value data corresponding to, for example, a shipping address. The XML element names are part of the XML language semantics where an arbitrary label or element name may be selected to represent the XML value data, the use of which is defined by the XML language. Typically, the element names appear between angled bracket ("").
As described above, known barcode label systems often use proprietary software encoding schemes. Additionally, such schemes are often prone to errors, and the underlying value data is usually unreadable by a non-technical individual. In known systems, if an error exists in the underlying value data sent from the enterprise system, or if the data is missing or otherwise incorrect, the barcode printer will print what it is instructed to do, which of course,


WO 03/052658

PCT/US02/36322

produces an error in the barcode label, rendering it inaccurate or useless.
Moreover, when dealing with compliance labeling, known systems require non-trivial changes in the data encoding when the form or content of the label changes in accordance with the compliance label demands. Such changes in the form or content of the barcode, again, are susceptible to errors, which in turn can lead to monetary fines by the entity demanding compliance. Business relationships may also be damaged by continued problems in the barcode labeling system, especially if such errors disrupt the business of the compliance demander.
The present XML printer system 10 utilizes an open format. In particular, the formatting requirements and the form of the barcode label are all defined in the XML language. Moreover, not only is XML well defined and available for all to use, but non-programmers can understand the data and commands in an XML data stream or file (or hard copy) with minimal training.
Various XML software blocks shown in Figs. 2-3 are commercially available. Several different commercially available XML processors 70 may be used interchangeably or with little modification. For example, the following commercially available XML processors 70 may be used: "XML for C++" available from IBM Corporation, "MSXML3" available from Microsoft Corporation, "Oracle XML Developers Kit for C" available from Oracle Corporation, "Expat" available from Thai Open Source Software Center, Ltd., or "Xerces-C++" available from the Apache Software Foundation. However, any suitable XML processor may be used.
Similarly, several different commercially available XSLT processors 74 may be used interchangeably or with little modificatioa For example, the following XSLT processors 74 may be used: "iXSLT" available from Infoteria Corporation, "MSXML3" available from Microsoft Corporation, and "Xibxslt" available from Gnome. However, any suitable XSLT processor may be used.
Again, several different commercially available XSLFO processors 78 may be used interchangeably or with little modification. For example, the following XSLFO processors 78 may be used: "XEP" available from RenderX Corporation, "XSL Formatter" available from Antenna House Corporation, and "FOP" available from the Apache Software Foundation.


WO 03/052658

PCT/US02/36322

However, any suitable XSLFO processor may be used.
Still referring to Figs. 1-3, the XML processor 70 receives the XML input data stream 90 from an external source 88. For example, the external source may be the ERP system 88, such as the warehouse management system. The XML processor 70 is essentially parses and processes the XML input data stream 90 and generates a set of nodes, which may be in a "tree" structure, as is known in the art. Each of the software processing blocks shown in Figs. 2-3 act on the nodes of the "tree" to perform their required function. The underlying value data contained in the XML input data stream 90 from the ERP system 88 is processed and entered into a "label values node tree," 100 which holds the data.
The following is a brief overview of the operation of the various software components. First, note that the XML input data stream 90 includes text that identifies the name and location of other required. XML documents or files. One such document is referred to as "XML schema" or "schema." The schema is used to validate the XML input data stream, including the underlying value data. If validation is successful, a stylesheet is applied, as will be described below. The name and location of the stylesheet is also specified in the XML input data stream 90. Application of the stylesheet is handled by the XSLT processor 74, which under the direction of the stylesheet, may transform the underlying XML element names and/or underlying value data. Next, the data is processed by the XSLFO processor 78, which handles formatting and "layout" of the underlying value data, which may include, for example, formatting the underlying value data in accordance with, for example, font type, font size, color, and the like. Next, the underlying value data is processed by the bitmap rendering engine 80, which creates a bitmap 92 of the barcode label corresponding to the transformed and formatted data. The bitmap rendering engine 80 may utilize an "instream foreign object" residing in the stylesheet to direct creation of the bitmap. The bitmap 92 is then sent to the printer driver 54 (Fig. 1) for subsequent printing of the barcode label by the barcode printer.
As described above, the schema functions to validate the entire input data stream 90,
in particular, the underlying value data, where errors may be typically found. In practice,
errors are often inadvertently introduced when changes are made to the form or content of the
bar code labeL
' The name and location of the schema document is contained in the XML input data


WO 03/052658

PCT/US02/36322

stream 90, which XML input data stream corresponds to the request to print a barcode label. The XML processor 70 in conjunction with a schema validation module 110 validates the underlying value data. The use of schema is cost effective because it prevents errors and omissions with respect to the final output, namely, the bar code label or "shipping label."
If the XML input data stream 90 is rejected or flagged as having an error, an error message may be transmitted back to the source 88. This may flag or trigger human intervention to correct the error. For example, in this specific example, the source is the ERP system 88. In this way, the data is initially checked prior to processing to insure that it complies with all required label and barcode rules.
This may be particularly beneficial when dealing with compliance labeling. In known systems, the compliance demander would merely notify the supplier as to the changes in the compliance labeling requirements. If the supplier then makes an error in interpreting or implementing these changes or instructions, the labels produced and applied to products shipped to the compliance demander may have errors, which could jeopardize future business or cause monetary fines to be applied.
In the present invention, the compliance demander preferably makes the changes directly to the schema and/or the XSLT stylesheet. For example, if the physical layout of the label has been changed or if element names have been changed, the compliance demander will modify the XSLT style sheet. Similarly, if the underlying value data has been added or deleted or otherwise qualified (i.e., a new acceptable numerical range for a zip code), the compliance demander may modify the schema. In this way, the supplier need only modify the output of its ERP system 88 to ensure that it matches the modified XML input data stream 90. If only the physical layout of the label has changed, the supplier does not need to make any modifications at all.
For example, the compliance demander may now require that a nine digit zip code be used rather than the original five digit zip code. Accordingly, the compliance demander will modify the schema to require both a first and second zip code field, and the second field will also be limited to numerical digits within a certain range, perhaps 0000-9999. The compliance demander may also modify the stylesheet to accommodate that change. In response thereto, the supplier must insert the added zip code field in its ERP system so that it appears in the


WO 03/052658

PCT/US02/36322

XML input data stream 90 sent to the XML printer system 10. If such modification of the XML input data stream 90 is not performed correctly, the schema will cause an error to be reported back to the ERP system 88, and the label will not be printed.
Thus, the supplier need only access the modified schema and/or stylesheet from the repository 82, 84, which is automatically applied to the underlying value data when received. Essentially, minor changes, and significantly, major changes, to the form and content of the barcode label are transparent to the supplier, and such changes to the content of the barcode label are validated in accordance with the schema. Accordingly, the supplier need not incur costs to change the form or content of the barcode label dictated by the compliance demander, and cannot make any errors in implementing such changes. If there are any errors, such errors would have been inadvertently made by the compliance demander, who could not then blame the supplier.
The schema documents are preferably obtained from the XML schema repository 82. In one specific embodiment, the schema repository 82 may be external to the XML printer system 10 and the computer system 12, and may be accessed via the network, the Internet, or via any suitable network 43, 44 to which the computer system is coupled. The schema repository 82 may contain a plurality of schema documents. Thus, the XML input data streams 90 representing the various requests to create a barcode label may each specify the name and location of the corresponding schema in the repository 82. When the request is received by the XML processor 70, the corresponding schema may be retrieved from the schema repository 82.
In another embodiment, the schema obtained, from the schema repository 82 via the network 42, 43 may be kept locally, and thus may temporarily reside in the memory subsystem 26 (Fig. 1), such as the hard disk 18 or database 22. In this way, if the same schema is used for multiple XML input data streams 90 or for subsequent barcode label requests, the XML processor 70 need not retrieve the same schema externally via the network 42, 44, but rather, may retrieve that schema from the memory subsystem 26, which may be more efficient. According to this embodiment, the compliance demander may change or modify the schema in the external repository 82 at only certain times. For example, the compliance demander may change the stylesheet only at 1:00 AM each day. Thus, the supplier need only update the


WO 03/052658

PCT/US02/36322

schema from the repository 82 into the memory subsystem 26 only once per day, for example, after the compliance demander has performed the schema update. The supplier would then know that the schema saved temporarily in the memory subsystem 26 is the most recent schema document, at least up until the time that the updating is scheduled to occur.
Regardless of the location from where the schema is obtained, the schema validation module 110 performs the checking and validation of the underlying data. Although the schema validation module 110 is shown as a separate block from the XML processor 70 in Fig. 2, it is shown in thisf location for purposes of illustration only so that it may be shown on the drawing adjacent to the label values node tree 100, which is the data upon which it acts. However, the schema validation module 110 may be part of and integrated into the XML processor 70, or it may be a separate and apart therefrom.
Of course, the schema is also an XML document, and thus it is also processed by the XML processor 70. Accordingly, the result of the processing of the schema is the XML schema node tree 114 shown in Fig. 3, which is the "memory representation" or working model of the schema that was processed. The XML schema node tree 114 may be in the form of a "document object model" (DOM), as is known in the art. Further, the XML schema node tree 114 may reside in cache memory for efficiency, as shown in an XML schema cache 116. The schema validation module 110 and/or the XML processor 70 operate on the data in the XML schema node tree 114 to perform its function of validating the underlying value data in accordance with the schema document.
As described above, if an error exists in the XML input data stream 90, as determined by application of the schema, an error message may be generated. If the XML input data stream 90 is validated, the data remains essentially "untouched." The data in the label value node tree 100 is then processed by the XSLT processor 74 using the XSLT stylesheets.
The stylesheet documents are preferably obtained from the XSLT stylesheet repository 84. In one specific embodiment, the stylesheet repository 84 may be external to the XML printer system 10 and the computer system 12, and may be accessed via the network, the Internet, or via any suitable network 43, 44 to which the computer system is coupled. The stylesheet repository 84 may contain a plurality of stylesheets. Thus, XML input data streams 90 representing the various requests to create a barcode label may each specify the name and


WO 03/052658

PCT/US02/36322

location of the corresponding stylesheet in the repository 84. When the request is received by the XML processor 70, the corresponding stylesheet may be retrieved from the stylesheet repository 84.
In another embodiment, the stylesheet obtained from the stylesheet repository 84 via the network 43, 44 may be kept locally, and thus may temporarily reside in the memory subsystem 26 (Fig. 1), such as the hard disk 18 or database 22. In this way, if the same stylesheet is used for multiple XML input data streams 90 or for subsequent barcode label requests, the XML processor 70 need not retrieve the same stylesheet externally via the network 43, 44, but rather, may retrieve that stylesheet from the memory subsystem 26, which may be more efficient.
According to this embodiment, the compliance demander may change or modify the stylesheet in the external stylesheet repository 84 at only certain times. For example, the compliance demander may change the stylesheet only at 1:00 AM each day. Thus, the supplier need only update the stylesheet from the stylesheet repository 84 into the memory subsystem 26 only once per day, for example, after the compliance demander has performed the stylesheet update. The supplier would then know that the stylesheet saved temporarily in the memory subsystem 26 is the most recent stylesheet, at least up until the time that the updating is scheduled to occur.
Of course, the stylesheet is also an XML document, and thus it is also processed by the XML processor 70. Accordingly, the result of the processing of the stylesheet is the XSLT stylesheet node tree 120 shown in Fig. 3, which is the "memory representation" or working model of the stylesheet that was processed. The XSLT stylesheet node tree 120 may be in the form of a "document object model" (DOM), as is known in the art. Further, the XSLT stylesheet node tree 120 may reside in cache memory for efficiency, as shown in an XSLT stylesheet cache 126. The XSLT processor 74 operates on the data in the XSLT stylesheet node tree 120 to perform its function of transforming the underlying value data or underlying element names in accordance with the stylesheet.
Note that although the XSLT style sheet is shown as an input to the XML processor 70 in Fig. 3, the XSLT processor 74 processes the stylesheet. It is initially provided to the XML processor 70 because all XML documents are first processed and placed into the


WO 03/052658

PCT/US02/36322

appropriate data structure for subsequent processing.
The XSLT processor 74 may modify, reposition, and rearrange the underlying value data or may add to the underlying value data or delete some of the underlying value data. For example, under direction of the stylesheet, the underlying value data may be rearranged into table format or into columns. In particular, the stylesheet may add XSLFO formatting elements and attributes.
After the underlying value data in the label value node tree 100 has been processed in accordance with the corresponding stylesheet, an XSLFO instance node tree 130 is produced. Again, the XSLFO instance node tree 130 may be in the form of a document object module, as is known in the art The XSLFO instance node tree 130 contains XSLFO commands (layout instructions) that directs the XSLFO processor 78 with respect to formatting and layout. The XSLFO processor 78 then interprets the XSLFO commands and applies such commands to the underlying value data so as to properly format and layout the underlying value data. The XSLFO processor 78 produces the XSLFO area node tree 130, which represents the final output of formatting before rendering.
Turning now to Fig. 3 and a code segment shown immediately below entitled "code segment 1 for an XML input data stream," the code segment 1 illustrates an XML input data stream 90 in hard copy, which may, for example, be sent to the XML printer system 10 by the ERP or warehouse management system 88. Line numbering has been inserted for purposes of illustration only and is not part of the code.
Code Segment 1 For An XML Input Data Steam
1 href="D:\Projects\XML\Native\Docs\ShipLabels.xsl"?> 5 xmlns:xsi="http://www.w3.org/2001/XMLScheroa-instance"
xsi:noNamespaceSchemaLocation=
"D:\Projects\XML\Native\Docs\ShipLabels.xsd"> 15
The XML input data stream identifies the schema document as "ShipLabels.xsd," and that schema document may be found, in this specific example, in a directory called "D:/Projects/XML/Native/Docs," as shown at line 7 in code segment 1. Further, the XML input data stream identifies the stylesheet document as "ShipLabels.xsl," and that stylesheet document may also be found in a directory called "D:/Projects/XML/Native/Docs," as shown at line 3 of the code segment 1. Of course, the schema document and the stylesheet document may be located anywhere, for example, as identified by an Internet address.
This specific example shows the underlying value data and element names for three shipping labels to be printed. Each shipping label contains an XML element name defined between angular brackets as follows: ,
, , and . The value of the first element name, , is "Albert Einstein," the value of the second element name,
, is "1234 Relative Way," the value of the third element name, , is "Princeton," the value of the forth element name, , is "NJ" and the value of the fifth element name, , is "08540." This is the underlying value data.
Now turning to Fig. 3, code segment 1, and a code segment shown immediately below entitled "code segment 2 for XML schema," the code segment 2 illustrates a specific example of an XML document in the form of the XML schema document specified in the XML input data stream of code segment 1. Line numbering has been inserted for purposes of illustration only and is not part of the code.
Code Segment 2 For XML Schema
1 xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"> 5


WO 03/052658

PCT/US02/36322


10




15




20




25



30




35




40


As mentioned above, the schema is used to validate the underlying value data. This entails checking to determine that all required data is present, that no extraneous data is present, that the data present is within the specified ranges, and the like. Any suitable validation scheme may be specified in the schema, depending upon the application. The XML language is robust and code may be written to handle a vast multitude of requirements.
For example, the schema document shown in code segment 2 above specifies that the underlying value data corresponding to the element name,
, must be a string, as defined in the XML Schema specification, as shown by line 5 in the code segment 2. The schema document also specifies that the underlying value data corresponding to the element names of ,
, , , and must also be present in the sequence indicated, as shown by lines 9-15 in the code segment 2. Further, this specific schema document shown in the code segment 2 specifies that the underlying value data corresponding


WO 03/052658

PCT/US02/36322

to the element name, , must be one of three states, namely, "CA," "NJ," or "NY." Of course, this is only an abbreviated example, and not all states have been included for purposes of illustration only. The schema document shown in code segment 2 also specifies that the underlying value data corresponding to the element name, , must be in the range from
00000 to 99999. If any of the above-mentioned schema criteria are not met by the data in the
XML input data stream, the schema validation module 110 will reject it, and will preferably
return an error message back to the source 88.
Now turning to Fig. 3, code segments 1-2, and a code segment shown immediately below entitled "code segment 3 for an XSLT stylesheet," the code segment 3 shows a specific example of an XML document in the form of the XSLT stylesheet document specified in the XML input data stream of the code segment 1. Line numbering has been inserted for purposes of illustration only and is not part of the code.
Code Segment 3 For An XSLT Stylesheet
1
xmlnB:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:fo="http://www.w3.org/1999/XSL/Format" 5 xmlns:bo="http://www.zebra.com/2002/XSL/Barcode">

Documents:


Patent Number 205953
Indian Patent Application Number 275/MUMNP/2004
PG Journal Number 42/2008
Publication Date 17-Oct-2008
Grant Date 13-Apr-2007
Date of Filing 12-May-2004
Name of Patentee ZIH CORP.
Applicant Address 3, GORHAM ROAD, HAMILTON HMO8, BERMUDA.
Inventors:
# Inventor's Name Inventor's Address
1 ALLESHOUSE, BRUCE, N 1426 FOREST AVENUE, WILMETTE, IL 60091-1634, U.S.A.
PCT International Classification Number G 06 F 17/60
PCT International Application Number PCT/US02/36322
PCT International Filing date 2002-11-13
PCT Conventions:
# PCT Application Number Date of Convention Priority Country
1 10/197,014 2002-07-17 U.S.A.
2 60/341,427 2001-12-17 U.S.A.
3 60/345,389 2002-01-04 U.S.A.