UOML (Unstructured Operation Markup Language) Part 1 Version 1.0

OASIS Standard

10 October 2008

Specification URIs:

This Version:

http://docs.oasis-open.org/uoml-x/v1.0/os/uoml-part1-v1.0-os.pdf (Authoritative)

http://docs.oasis-open.org/uoml-x/v1.0/os/uoml-part1-v1.0-os.odt

http://docs.oasis-open.org/uoml-x/v1.0/os/uoml-part1-v1.0-os.html

Previous Version:

http://docs.oasis-open.org/uoml-x/v1.0/cs01/uoml-part1-v1.0-cs01.pdf

http://docs.oasis-open.org/uoml-x/v1.0/cs01/uoml-part1-v1.0-cs01.odt (Authoritative)

http://docs.oasis-open.org/uoml-x/v1.0/cs01/uoml-part1-v1.0-cs01.html

Latest Version:

http://docs.oasis-open.org/uoml-x/v1.0/uoml-part1-v1.0.odt

http://docs.oasis-open.org/uoml-x/v1.0/uoml-part1-v1.0.html

http://docs.oasis-open.org/uoml-x/v1.0/uoml-part1-v1.0.pdf

Technical Committee:

OASIS Unstructured Operation Markup Language Extended (UOML-X) Technical Committee

Chair(s):

Alex Wang, Sursen Corp <alexwang@sursen.com>

Bo Yan, Sursen Corp <yanbo@sursen.com> (until September 2007)

Allison Shi, Sursen Corp <allison_shi@sursen.com> (since September 2007)

Editor(s):

Guo Xu, Sursen Corp. <guoxu@sursen.com>

Allison Shi, Sursen Corp. <allison_shi@sursen.com>

Pine Zhang, UOML Alliance <pine_zhang@sursen.com>

Related work:

[N/A]

Declared XML Namespace(s):

urn:oasis:names:tc:uoml:xmlns:uoml-x:1.0 (prefix: uoml)

Abstract:

This document defines a markup language for unstructured document operation, including the definitions of abstract document model and document operating instructions to the abstract document model.



Status:

This document was last revised or approved by the OASIS Unstructured Operation Markup Language eXtended (UOML-X) Technical Committee on the above date. The level of approval is also listed above. Check the "Latest Version" or "Latest Approved Version" location noted above for possible later revisions of this document.

Technical Committee members should send comments on this specification to the Technical Committee's email list. Others should send comments to the Technical Committee by using the "Send A Comment" button on the Technical Committee's web page at http://www.oasis-open.org/committees/uoml-x/.

For information on whether any patents have been disclosed that may be essential to implementing this specification, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the Technical Committee web page http://www.oasis-open.org/committees/uoml-x/ipr.php.

The non-normative errata page for this specification is located at http://www.oasis-open.org/committees/uoml-x/.

Notices

Copyright © OASIS® 2008. All Rights Reserved.

All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to OASIS, except as needed for the purpose of developing any document or deliverable produced by an OASIS Technical Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must be followed) or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

OASIS requests that any OASIS Party or any other party that believes it has patent claims that would necessarily be infringed by implementations of this OASIS Committee Specification or OASIS Standard, to notify OASIS TC Administrator and provide an indication of its willingness to grant patent licenses to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification.

OASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership of any patent claims that would necessarily be infringed by implementations of this specification by a patent holder that is not willing to provide a license to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification. OASIS may include such claims on its website, but disclaims any obligation to do so.

OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS' procedures with respect to rights in any document or deliverable produced by an OASIS Technical Committee can be found on the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this OASIS Committee Specification or OASIS Standard, can be obtained from the OASIS TC Administrator. OASIS makes no representation that any information or list of intellectual property rights will at any time be complete, or that any claims in such list are, in fact, Essential Claims.

The names "OASIS" and “UOML” are trademarks of OASIS, the owner and developer of this specification, and should be used only to refer to the organization and its official outputs. OASIS welcomes reference to, and implementation and use of, specifications, while reserving the right to enforce its marks against misleading uses. Please see http://www.oasis-open.org/who/trademark.php for above guidance.










Table of Contents

1. Introduction 7

1.1.Terminology 7

1.2.Overview 7

1.3.Normative References 8

1.4.Non-Normative References 8

2.UOML Document Structure 9

2.1.Document Architecture 9

2.1.1.DOCBASE 9

2.1.2. DOCSET 10

2.1.3. DOC 10

2.2.Internal Structure of Document 10

2.3. Document Global Data 11

2.3.1.Metadata 11

2.3.1.1.METALIST 11

2.3.1.2. META 11

2.3.2.Font Definition 12

2.3.2.1. FONTLIST 12

2.3.2.2. FONTMAP 12

2.3.2.3. EMBEDFONT 12

2.4.Page Data 12

2.4.1. PAGE 12

2.4.2.LAYER 13

2.4.3.OBJSTREAM 13

2.4.4.Page Rendering Models 13

2.5.Graphics Objects 13

2.5.1. ARC 13

2.5.2. BEZIER 14

2.5.3. CIRCLE 14

2.5.4. ELLIPSE 14

2.5.5. IMAGE 15

2.5.6. LINE 15

2.5.7. RECT 15

2.5.8.ROUNDRECT 16

2.5.9. SUBPATH 16

2.5.10. PATH 16

2.5.11. TEXT 17

2.5.12. The Coordinate and Path Encoding Rules 17

2.5.13. Definition of Referenced Type 18

2.5.13.1.COLOR_RGB 18

2.5.13.2. MATRIX 18

2.6.Command Objects. 19

2.6.1.CMD 19

2.6.2.CMD's name property values 20

2.6.2.1. COLOR_LINE 20

2.6.2.2. COLOR_FILL 20

2.6.2.3. COLOR_SHADOW 20

2.6.2.4. COLOR_OUTLINE 20

2.6.2.5. COLOR_TEXT 21

2.6.2.6. LINE_WIDTH 21

2.6.2.7. LINE_CAP 21

2.6.2.8. LINE_JOIN 21

2.6.2.9. MITER_LIMIT 22

2.6.2.10. FILL_RULE 23

2.6.2.11. RENDER_MODE 24

2.6.2.12. RASTER_OP 24

2.6.2.13. TEXT_DIR 25

2.6.2.14. CHAR_DIR 25

2.6.2.15. CHAR_ROTATE 25

2.6.2.16. CHAR_SLANT 26

2.6.2.17. CHAR_SIZE 26

2.6.2.18. CHAR_WEIGHT 26

2.6.2.19. CHAR_STYLE 26

2.6.2.20. TEXT_MATRIX 27

2.6.2.21. IMAGE_MATRIX 27

2.6.2.22. GRAPH_MATRIX 28

2.6.2.23. EXT_MATRIX 28

2.6.2.24. PUSH_GS 28

2.6.2.25. POP_GS 28

2.6.2.26. SHADOW_WIDTH 28

2.6.2.27. SHADOW_LEN 28

2.6.2.28. SHADOW_DIR 29

2.6.2.29. SHADOW_ATL 30

2.6.2.30. SHADOW_NEG 30

2.6.2.31. CLIP_AREA 31

2.6.2.32. FONT 31

2.6.2.33. OUTLINE_BORDER 31

2.6.2.34. OUTLINE_WIDTH 31

2.6.2.35. HOLLOW_BORDER 32

2.7.Default Value of Graphics State 32

3.UOML Instructions 34

3.1.OPEN 34

3.2.CLOSE 34

3.3.USE 35

3.4.GET 35

3.5.SET 36

3.6.INSERT 37

3.7.DELETE 38

3.8.SYSTEM 38

3.9.RET 39

3.10.Definition of Referenced Type 40

4.Conformance 43

Appendix A. Acknowledgments 44



1. Introduction

1.1 Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

Keywords:

UOML: short for "Unstructured Operation Markup Language".

Docbase: comes from "Database", means document base, is the container of mass documents; it is the root level of the UOML document structure.

DoCbase Management System: the software which implements the function defined by UOML, short as DCMS.

Docset: a set of documents, like directory in file system.

Layer: a page is composed of one or more layers, each layer has the same size as the page, and the visual appearance of the page is added up by these layers.

Path: refers to the open or closed region collection, which consists of one or multiple line/curve segment(s), its first letter should always be uppercase. In this document, we also use 'path' (all lowercase) to refer to filename, location of Docbase or image file, it is different from 'Path'.

Graphics Object: refers to the objects that could make render engine to draw, it is used to describe the appearance of a page. It includes: text, image, Path, etc.

Command Object: uses for modifying the current graphics state that holds current graphics control parameters, such as text size, typeface and color.

Object Stream: a sequence of graphics objects and command objects.

Sub-object: in a tree structure, the upper level object is called parent object, and its' connected lower level object is called sub-object. One parent object can connect multiple sub-objects, but one sub-object can only have one parent object. Sub-object is created by INSERT instruction.

1.2 Overview

UOML is interface standard to process unstructured document; it plays the similar role as SQL (Structured Query Language) to structured data. UOML is expressed with standard XML, featuring compatibility and openness

UOML deals with layout-based document and its related information (such as metadata, rights, etc.) Layout-based document is two dimensional, static paging information, i.e. information can be recorded on traditional paper. The software which implements the UOML defined function, is called DCMS, applications can process the document by sending UOML instructions to DCMS.

UOML first defines abstract document model, then operations to the model. Those operations include read/write, edit, display/print, query, security control; it covers the operations which required by all different kinds of application software to process documents. UOML is based on XML description, and is platform-independent, application-independent, programming language-independent, and vendor neutral. This standard will not restrict manufacturers to implement DCMS in their own specific way.

This specification is the 1st part of UOML, which defines the operations used for read/write, edit, and display/print layout-based document.

This specification defines UOML objects and UOML instructions as following.

1.3 Normative References

[XML1.0] Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler, François Yergeau , Extensible Markup Language (XML) 1.0 (Third Edition),

http://www.w3.org/TR/2004/REC-xml-20040204, W3C, 2004.



[xml-names] Tim Bray, Dave Hollander, Andrew Layman, Namespaces in XML, http://www.w3.org/TR/REC-xml-names/, W3C, 1999.

[xmlschema-1] W3C XML Schema Definition Language (XSDL) 1.1 Part 1: Structures http://www.w3.org/TR/xmlschema11-1/



[xmlschema-2] Paul V. Biron, Ashok Malhotra, XML Schema Part 2: Datatypes Second Edition, http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/, W3C, 2004.



[RFC2119] S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, http://www.ietf.org/rfc/rfc2119.txt, IETF RFC 2119, March 1997.



[PNG] ISO/IEC 15948:2004 Portable Network Graphics (PNG): Functional specification

http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=29581.



[JBIG] ISO/IEC 11544, Coded representation of picture and audio information -- Progressive bi-level image compression



[JPEG] ISO/IEC 10918, Digital compression and coding of continuous-tone still images



[OpenFont] ISO/IEC 14496-22:2007, "Open Font Format Specification"

http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=43466

1.4 Non-Normative References


[PDF] ISO/IEC FDIS 32000, Portable Document Format based on PDF1.7: Part 1


2. UOML Document Structure

UOML works on abstract document model. The abstract document model can be regarded as a hierarchy of objects, the UOML instructions deal with these objects. This chapter specifies what kinds of objects are included in abstract document model, and also addresses the detailed description of each object.

This chapter covers the following issues:


2.1 Document Architecture

Documents are organized with Docbase, Docset and Document. Within one Docbase, it must have one and only one Docset, as the root Docset, which is the collection and entrance for all the documents, similar to the root directory of a file system. As the container for Document, Docset can be embedded, which means it may contain sub-Docset. Therefore, Docbase, Docset and Document can construct a multiple level tree structure, just like the file system.



2.1.1. DOCBASE

Semantics: UOML document structure's top level. It has only one root DOCSET, other DOCSET and DOC are the root DOCSET's direct or indirect sub-objects. The root DOCSET will be generated automatically when the DOCBASE is created.

Properties:

name: name of Docbase.

path: location of the Docbase.

Sub-element: N/A

Sub-object: root DOCSET.



2.1.2. DOCSET

Semantics: a set of DOC and/or DOCSET.

Properties:

name: name of Docset.

Sub-element: N/A

Sub-object: DOC, DOCSET.



2.1.3. DOC

Semantics: refers layout-based document, a single document has 0 to multiple pages.

Properties:

name: name of document.

Sub-element:

metainfo: metadata of the document, METALIST type.

Sub-object: Page Data and Document Global Data.


2.2. Internal Structure of Document

Document is consisted of Document Global Data and Page Data.

Document Global Data can be used globalize among the document, it includes Metadata and Font. Metadata is the list for a set of keys and values, and is a sub-object of DOC, while Font is a list of font mappings (FONTMAP) and is also a sub-object of DOC. Each font mapping describes a font type used in the document, including font name, font sequential number defined in the document, and optional embedded Font.

Page Data may include 0 to multiple page(s) (PAGE). Each page has properties to describe width, height, resolution; each page may contain one to multiple layer(s) (LAYER), and each layer may contain one to multiple object stream; each object stream may contain a sequence of objects, which include graphics objects (details about this, see 2.5 Graphics objects) and non-displayable command objects CMD(details about this, see 2.6 Command Objects).



2.3. Document Global Data

Document Global Data includes Metadata and Font definition.


2.3.1. Metadata

General information, such as the document's title, author, creation and modification date, is called metadata. Metadata consists of a METALIST, the METALIST consists of 1 to multiple META.

2.3.1.1. METALIST

Semantics: a list of all the metadata in the document.

Properties: N/A

Sub-element:

meta: META type.

Sub-object: N/A


2.3.1.2. META

Semantics: one metadata, including two properties: key and value.

Properties:

key: character string value which presents the key of metadata.

val: character string value which presents the value of metadata.

Sub-element: N/A

Sub-object: N/A



2.3.2. Font Definition

Font contains of a FONTLIST, the FONTLIST consists of 1 to multiple FONTMAP, and FONTMAP consists of zero or one EMBEDFONT. EMBEDFONT, FONTMAP, FONTLIST in the order given above, the previous one is the sub-object of the latter one,and can be generated by UOML's INSERT instruction.



2.3.2.1. FONTLIST

Semantics: a list of all the fonts used in the document

Properties: N/A

Sub-element: N/A

Sub-object: FONTMAP



2.3.2.2. FONTMAP

Semantics: defines one font used in the document.

Properties:

name: name of the font

no: the id of the font quoted in document.

Sub-element: N/A

Sub-object: EMBEDFONT


2.3.2.3. EMBEDFONT

Semantics: one embedded font type.

Properties: N/A

Sub-element: N/A

Sub-object: N/A

Note:

Use OpenFont as embedded font type. After encoding OpenFont using base64 format, put the result into EMBEDFONT's content section as the embed font data



2.4. Page Data

Page data includes PAGE, LAYER, OBJSTREAM, Graphics Objects and Command Objects, please check Figure 2 for their structure.


LAYER is PAGE's sub-object, OBJSTREAM is LAYER's sub-object, Graphics Objects and Command Objects are OBJSTREAM's sub-object, they can be generated by UOML INSERT instruction. Graphics Objects refers all the visible objects, check 2.5 for details. Command Objects refers objects that can control graphics state of the render engine, check 2.6 for details.

2.4.1. PAGE

Semantics: page within document.

Properties:

width: width of the page.

height: height of the page.

resolution: resolution of the page.

Sub-element: N/A

Sub-object: 1 to multiple LAYER

2.4.2. LAYER

Semantics: layers inside page.

Properties: N/A

Sub-element: N/A

Sub-object: 0 to multiple OBJSTREAM.



2.4.3. OBJSTREAM

Semantics: a sequence of objects.

Properties: N/A

Sub-element: N/A

Sub-object: 0 to multiple Graphic Objects (see details on 2.5) and / or Command Objects (see details on 2.6).


2.4.4. Page Rendering Models

Page rendering steps:

2.5. Graphics Objects


Graphics objects refer to the objects that could make render engine to draw, such as text, image, and Path. They describe the appearance of the page. The types and definitions of graphics objects are given as follows.


2.5.1. ARC

Semantics:

ARC includes five properties: starting point, ending point, center, direction and angle.

Properties:

start: starting position of arc.

end: ending position of arc.

center: center of ellipse arc.

clockwise: direction for arc is from the starting point to the ending point, which can be clockwise or anti-clockwise. It is a Boolean value, "true" means clockwise, "false" means anti-clockwise.

angle: inclination from coordinate system's x-axis to arc's x-axis. It is calculated by radian. Positive value means anti-clockwise, negative value means clockwise.

Sub-element: N/A

Sub-object: N/A

2.5.2. BEZIER

Semantics:

Bezier curve includes four properties: starting point, control point 1, control point 2 and ending point.

Properties:

start: starting point of Bezier curve.

ctrl: the first control point of Bezier curve.

ctrl2: the second control point of Bezier curve, it is optional.

end: ending point of Bezier curve.

Sub-element: N/A

Sub-object: N/A

Note:

The above is the definition of a third-order Bezier curve. However, if ctrl2 doesn't exist, the curve then becomes a second-order Bezier curve.


2.5.3. CIRCLE

Semantics:

Circle includes two properties: center and radius.

Properties:

center : coordinate of circle center

radius: radius of circle

Sub-element: N/A

Sub-object: N/A


2.5.4. ELLIPSE

Semantics:

Ellipse includes four properties: center, radius x, radius y and rotation angle.

Properties:

center: coordinates of ellipse center.

xr: length of radius x.

yr: length of radius y.

angle: inclination from coordinate system's x-axis to ellipse's x-axis. It is calculated by radian. Positive value means anti-clockwise, negative value means clockwise.

Sub-element: N/A

Sub-object: N/A


2.5.5. IMAGE

Semantics:

Image includes four properties: coordinates of top-left corner, coordinates of bottom-right corner, image type, image file pathname or inline image data.

Properties:

tl: coordinates of top-left corner as the image is displayed in the page

br: coordinates of the bottom-right corner as the image is displayed in the page

type: image type, possible value includes "bmp", "png", "jpeg", "jbig", "tiff", representing BMP, PNG, JPEG, JBIG, TIFF image respectively.

path(optional): path of the image file. If present, the content of IMAGE element should leave blank, otherwise the content of IMAGE element contains the base64 encoded raw image data.

Sub-element: N/A

Sub-object: N/A

Note:

Image may contains large amount of bytes, and it will greatly reduce the performance of XML parser, it is recommended to transfer large image using a file by specifying the filename in the 'imgpath' property.


2.5.6. LINE

Semantics:

Line has two properties: starting point and ending point

Properties:

start: coordinates of where the line starts

end: coordinates of where the line ends

Sub-element: N/A

Sub-object: N/A


2.5.7. RECT

Semantics:

Rectangle has two properties: coordinates of the top-left corner and coordinates of bottom-right corner.

Properties:

tl: coordinates of the top-left corner as the rectangle is shown in the page

br: coordinates of the bottom-right corner as the rectangle is shown in the page

Sub-element: N/A

Sub-object: N/A


2.5.8. ROUNDRECT

Semantics:

Round rectangle has four properties: coordinates of the top-left corner, coordinates of the bottom-right corner, radius x and radius y.

Properties:

tl: coordinates of the top-left corner of the rectangle

br: coordinates of the bottom-right corner of the rectangle

xr: radius x of the round corner

yr: radius y of the round corner

Sub-element: N/A

Sub-object: N/A


2.5.9. SUBPATH

Semantics:

Sub-path refers to an irregular chain of curves consists of lines, Bezier curves and arcs, it can be either closed or not.

Properties:

data: defines the starting point and ending point of the sub-path, as well as each curve segment which makes up the sub-path.

Sub-element: N/A

Sub-object: N/A

Note: for encoding of property 'data', please refer to 2.5.12


2.5.10. PATH

Semantics:

Path refers to the open or closed region collection consist of one or multiple sub-path(s), circle(s), ellipse(s), rectangle(s) and round rectangle(s). PATH itself does not have data.

Properties: N/A

Sub-element:

circle: CIRCLE type, defines a circle.

ellipse: ELLIPSE type, defines ellipse.

rect: RECT type, defines rectangle.

roundrect: ROUNDRECT type, defines rectangle with round corners.

subpath: SUBPATH type, defines sub-path.

Sub-object: N/A


2.5.11. TEXT

Semantics:

Text has four properties: origin, encoding information, text data and character spacing list.

Properties:

origin: the coordinate of the first character's origin, origin of a character is defined by its font data.

encode: character set or encoding of text data.

text: character data contained in text, string data.

spaces: defines distances between adjacent characters' origin, separated by comma.

Sub-element: N/A

Sub-object: N/A



2.5.12. The Coordinate and Path Encoding Rules

In order to provide short and efficient expression for coordinates and path, this section defines the encoding rules used by UOML.



Coordinates encoding rules


<coord>     ::= <coord_x>,<coord_y>
<coord_x>   ::= <int>
<coord_y>   ::= <int>



In this Backus-Naur Form rule expression, 'coord' is coordinates, 'coord_x' is coordinate x, and 'coord_y' is coordinate y; <int> represents a string form of integer number.


Path encoding rules


<path> ::= <start> { <blank> ( <line> | <bezier2> | <bezier3> | <arc> ) }
<start> ::= s <blank> <coord>
<line> ::= l <blank> <coord>
<bezier2> ::= b <blank> <coord> <blank> <coord>
<bezier3> ::= B <blank> <coord> <blank> <coord> <blank> <coord>
<arc> ::= a <clockwise> <blank> <angle> <blank> <coord> <blank> <coord>
<clockwise> ::= true | false

<angle> ::= <float>


Semantics Definition

'coord' represents coordinates, refer to its previous definition.

'start' represents start point of sub-path.

'line' represents line segment.

'bezier2' represents second-order Bezier curve.

'bezier3' represents third-order Bezier curve.

'<blank>' represents one or multiple blank(s) or equivalent character, such as tab.



In the definition of 'line', 'coord' represent the ending point.

In the definition of 'bezier2', two 'coord' are for the control point and the ending point.

In the definition of 'bezier3', three 'coord' are for the control point 1, control point 2 and ending point.

In the definition of 'arc', two 'coord' are center and end point.

Note:

Start point of each curve is the previous end point.



2.5.13. Definition of Referenced Type

2.5.13.1. COLOR_RGB

Semantics: color setting

Properties:

r: red component

g: green component

b: blue component

a: alpha component, it is optional.

Sub-element: N/A

Sub-object: N/A



2.5.13.2. MATRIX

Semantics: transformation matrix

Properties:

f11: floating point number

f12: floating point number

f21: floating point number

f22: floating point number

f31: floating point number

f32: floating point number

Sub-element: N/A

Sub-object: N/A

Note:

A transformation of matrix in UOML shall be specified by six numbers. In its most general form, this array is denoted [f11 f12 f21 f22 f31 f32]; it can represent any linear transformation from one coordinate system to another. The transformation is carried out as follows:


x′ = f11×x + f21×y + f31

y′ = f12×x + f22×y + f32


Translations shall be specified as [1 0 0 1 tx ty], where tx and ty shall be the distances to translate the origin of the coordinate system in the horizontal and vertical dimensions, respectively.

Scaling shall be obtained by [sx 0 0 sy 0 0]. This scales the coordinates so that 1 unit in the horizontal and vertical dimensions of the new coordinate system is the same size as sx and sy units, respectively, in the previous coordinate system.

Rotations shall be produced by [cos(q) sin(q) –sin(q) cos(q) 0 0], which has the effect of rotating the coordinate system axes by an angle q counterclockwise.

Skew shall be specified by [1 tan(a) tan(b) 1 0 0], which skews the x axis by an angle a and the y axis by an angle b.




2.6. Command Objects.



Command objects are Page Data's sub-object, are used for modifying the current graphics state that holds current graphics control parameters, such as text size, typeface and color. The properties include command name, command value and other possible data (such as clip, transformation matrix, color and so on).

2.6.1. CMD

Semantics: non-displayable command objects

Properties:

name: name of the command, refer to 2.6.2 to 2.6.37 for its possible value..

v1: optional command value.

v2: optional command value.

Sub-element:

rgb: COLOR_RGB type, used when 'name' is one of COLOR_LINE, COLOR_FILL, COLOR_SHADOW, COLOR_OUTLINE or COLOR_TEXT, refer corresponding sections below.

matrix: MATRIX type, used when 'name' is one of TEXT_MATRIX, IMAGE_MATRIX, GRAPH_MATRIX or EXT_MATRIX, refer corresponding sections below.

cliparea: PATH type, used when 'name' is CLIP_AREA, refer corresponding section below.

Sub-object: N/A

EXAMPLE 1:

<CMD name="COLOR_LINE" >

<rgb r="128" g="3" b="255" a="120"/>

</CMD>



EXAMPLE 2:

<CMD name="LINE_CAP" v1="END_BUT"/>



EXAMPLE 3:

<CMD name="TEXT_MATRIX">

<matrix f11="2" f12="0" f21="0" f22="1.5" f31="10" f32="20"/>

</CMD>



2.6.2 CMD's name property values

Following sections describes what values can be used for 'name' property, and properties and sub-elements can be used for each valid 'name' value.



For example, if the CMD's 'name' property is 'COLOR_LINE', then CMD's sub-element is 'rgb'.



In order to simplify the parsing process, properties (command values) within command objects all have a general name called v1, and v2 if there is second property, no matter what they represent.

2.6.2.1. COLOR_LINE

Semantics: set the current line color

Properties: N/A

Sub-elements:

rgb: element of COLOR_RGB type, rgb specifies the color used to stroke lines and curves.

2.6.2.2. COLOR_FILL

Semantics: set the current fill color

Properties: N/A

Sub-elements:

rgb: element of COLOR_RGB type, rgb specifies the color used to fill an area.

2.6.2.3. COLOR_SHADOW

Semantics: set the current character shadow color

Properties: N/A

Sub-elements:

rgb: element of COLOR_RGB type, rgb specifies the color used to draw shadow of characters.

2.6.2.4. COLOR_OUTLINE

Semantics: set the current character outline color

Properties: N/A

Sub-elements:

rgb: element of COLOR_RGB type, rgb specifies the color used to draw outline of characters.

2.6.2.5. COLOR_TEXT

Semantics: set the current text color

Properties: N/A

Sub-elements:

rgb: element of COLOR_RGB type, rgb specifies the color used to draw characters.



2.6.2.6. LINE_WIDTH

Semantics: set the current line width

Properties:

v1: a floating point number, representing width of line.

Sub-elements: N/A



2.6.2.7. LINE_CAP

Semantics: set the current line cap style

Properties:

v1: a character string, representing line cap style. Possible value includes END_BUT, END_ROUND and END_SQUARE.

Sub-elements: N/A

Note:

END_BUT: the stroke shall be squared off at the endpoint of the path. There shall be no projection beyond the end of the path.



END_ROUND: a semicircular arc with a diameter equal to the line width shall be drawn around the end point the endpoint and shall be filled in.



END_SQUARE: the stroke shall continue beyond the endpoint of the path for a distance equal to half the line width and shall be squared off.



2.6.2.8. LINE_JOIN

Semantics: set the current line join style

Properties:

v1: a character string, representing line join style. Possible value includes JOIN_MITER, JOIN_BEVEL and JOIN_ROUND

Sub-elements: N/A

Note:

JOIN_MITER: the outer edges of the strokes for the two segments shall be extended until they meet at too sharp an angle, a JOIN_BEVEL shall be used instead.



JOIN_BEVEL: the two segments shall be finished with END_BUT and the resulting notch beyond the end of the segments shall be filled with triangle.



JOIN_ROUND: an arc of a circle with a diameter equal to the line width shall be drawn around the point where the two segments meet, connecting the outer edges of the strokes for the two segments. This pie slice-shaped figure shall be filled in, producing a rounded corner.

2.6.2.9. MITER_LIMIT

Semantics:

impose a maximum on the ratio of the miter length to the line width. When the limit is exceeded, the join is converted from a miter to a bevel.

Properties:

v1: a floating point number, representing the maximum ratio.

Sub-elements: N/A





2.6.2.10. FILL_RULE

Semantics: set the current fill rules

Properties:

v1: a character string, representing fill rules. Its possible value includes RULE_EVENODD and RULE_WINDING.

Sub-elements: N/A

Note:

RULE_EVENODD: Specifies that areas are filled according to the even-odd parity rule. According to this rule, you can determine whether a test point is inside or outside a closed curve as follows: Draw a line from the test point to a point that is distant from the curve. If that line crosses the curve an odd number of times, the test point is inside the curve; otherwise, the test point is outside the curve.

RULE_WINDING: Specifies that areas are filled according to the nonzero winding rule. According to this rule, you can determine whether a test point is inside or outside a closed curve as follows: Draw a line from a test point to a point that is distant from the curve. Starting with a count of 0, the rule adds 1 each time a curve segment crosses the ray from left to right and subtracts 1 each time a segment crosses from right to left. After counting all the crossings, if the result is 0, the point is outside the path; otherwise, it is inside.

2.6.2.11. RENDER_MODE

Semantics: set the current render mode (line, fill, clip, or their combination)

Properties:

v1: a character string, representing render mode. Its possible value includes LINE, FILL, CLIP, or some of them connected by comma.

Sub-elements: N/A

Note:

LINE: draw a line along the path..

FILL: draw the entire region enclosed by the path..

CLIP: current clip area will be set as the intersection of the next path graphics and current clip area.



2.6.2.12. RASTER_OP

Semantics: set the current raster operation.

Properties:

v1: a character string, representing raster operation. Its possible value includes ROP_COPY, ROP_N_COPY, ROP_RESET, ROP_SET, ROP_NOP, ROP_REV, ROP_AND, ROP_AND_N, ROP_N_AND, ROP_N_AND_N, ROP_OR, ROP_OR_N, ROP_N_OR, ROP_N_OR_N, ROP_XOR, and ROP_EOR.

Sub-elements: N/A

Note:

ROP_COPY: pixel_color = src

ROP_N_COPY: pixel_color = ~src

ROP_RESET: pixel_color = 0 (all bits of pixel_color are set zero)

ROP_SET: pixel_color = 1 (all bits of pixel_color are set 1)

ROP_NOP: pixel_color = dest

ROP_REV: pixel_color = ~dest

ROP_AND: pixel_color = src & dest

ROP_AND_N: pixel_color = src & ~dest

ROP_N_AND: pixel_color = ~src & dest

ROP_N_AND_N: pixel_color = ~src & ~dest

ROP_OR: pixel_color = src | dest

ROP_OR_N: pixel_color = src | ~d

ROP_N_OR: pixel_color = ~src | dest

ROP_N_OR_N: pixel_color = ~src | ~dest

ROP_XOR: pixel_color = src ^ dest

ROP_EOR: pixel_color = src ^ ~dest



Here, pixel color is the color after rendering; 'src' is the current used color, also called foreground color; 'dest' is the current color the page has, also called background. '&' is bitwise AND,'|' is bitwise OR,'^' is bitwise XOR,'~' is bitwise NOT. Also '~' has the highest priority.



2.6.2.13. TEXT_DIR

Semantics: set the current text direction. The direction is from the end of a text row to the beginning..

Properties:

v1: a character string, representing the text direction. The possible values include HEAD_LEFT, HEAD_RIGHT, HEAD_TOP and HEAD_BOTTOM.

Sub-elements: N/A

Note:

HEAD_LEFT: the text direction is from left to right.

HEAD_RIGHT: the text direction is from right to left.

HEAD_TOP: the text direction is from top to bottom.

HEAD_BOTTOM: the text direction is from bottom to top.



2.6.2.14. CHAR_DIR

Semantics: set the current character direction, the direction is from the bottom to the top of the character.

Properties:

v1: a character string, representing character direction. The possible values include HEAD_LEFT, HEAD_RIGHT, HEAD_TOP and HEAD_BOTTOM.

Sub-elements: N/A

Note:

HEAD_LEFT: the character is heading left.

HEAD_RIGHT: the character is heading right.

HEAD_TOP: the character is heading up.

HEAD_BOTTOM: the character is heading down.



2.6.2.15. CHAR_ROTATE

Semantics: set the current character rotation angle.

Properties:

v1: a floating point number, representing the character rotating radian. Positive value means anti-clockwise; negative value means clockwise.

v2: a character string, representing whether the rotation is around the character center or around the top-left corner. The possible value includes ROT_CENTER and ROT_LEFTTOP.

Sub-elements: N/A

2.6.2.16. CHAR_SLANT

Semantics: set slant of the current character.

Properties:

v1: a floating point number, representing the character slanting radian, 0π/2 representing right slant, 3π/22π representing left slant, and 0 representing non-slant; other values are not used.

Sub-elements: N/A

2.6.2.17. CHAR_SIZE

Semantics: set the current character width and height.

Properties:

v1: a floating point number, representing the character width.

v2: a floating point number, representing the character height.

Sub-elements: N/A

2.6.2.18. CHAR_WEIGHT

Semantics: set the current character weight.

Properties:

v1: a floating point number, from 0 to 1, representing the character weight.

Sub-elements: N/A

2.6.2.19. CHAR_STYLE

Semantics: set the current character style.

Properties:

v1: a character string, representing the character style. The possible values include SHADOW, HOLLOW and OUTLINE, or some of them connected with commas. If the string is empty, that means to clean the old setting.

Sub-elements: N/A

Note:

SHADOW: set shadow style.

HOLLOW: set hollow style

OUTLINE: set outline style.



2.6.2.20. TEXT_MATRIX

Semantics:

set the current text transformation matrix. The visual effect of transforming a character is shown below:

Properties: N/A

Sub-elements:

matrix: element of MATRIX type, responsible for transforming coordinates of text.

2.6.2.21. IMAGE_MATRIX

Semantics: set the current image transformation matrix

Properties: N/A

Sub-elements:

matrix: element of MATRIX type, used for transforming coordinates of image.

2.6.2.22. GRAPH_MATRIX

Semantics: set the current line/curve transformation matrix

Properties: N/A

Sub-elements:

matrix: element of MATRIX type, used for transforming coordinates of path graphics, such as line, Bezier curve, arc, circle, ellipse, rect, roundrect, sub-path, path, etc.

2.6.2.23. EXT_MATRIX

Semantics: set the current extension transformation matrix

Properties: N/A

Sub-elements:

matrix: element of MATRIX type, used for transforming coordinates of all path graphics, images and texts (after dedicated transformation matrix for path graphics, images and texts).

2.6.2.24. PUSH_GS

Semantics: put the current graphics state onto stack.

Properties: N/A

Sub-elements: N/A

2.6.2.25. POP_GS

Semantics: pop out the top value from the graphics state stack, replace current graphics state

Properties: N/A

Sub-elements: N/A

2.6.2.26. SHADOW_WIDTH

Semantics: set the border width of the current character shadow.

Properties:

v1: a floating point number, representing shadow border width.

Sub-elements: N/A

2.6.2.27. SHADOW_LEN

Semantics: set the length of the current character shadow

Properties:

v1: floating point number, representing the character shadow length.

Sub-elements: N/A

2.6.2.28. SHADOW_DIR

Semantics: set the direction of the current character shadow

Properties:

v1: a character string. The possible values include SHADOW_LT, SHADOW_LB, SHADOW_RT and SHADOW_RB.

Sub-elements: N/A

Note:

SHADOW_LT: the character shadow direction is top left.



SHADOW_LB: the character shadow direction is bottom left.



SHADOW_RT: the character shadow direction is top right.



SHADOW_RB: the character shadow direction is bottom right.



2.6.2.29. SHADOW_ATL

Semantics: set whether to adjust the coordinates of a character when the direction of character shadow is to the left or top

Properties:

v1: a boolean value, representing whether to alter the coordinates of a character

Sub-elements: N/A

2.6.2.30. SHADOW_NEG

Semantics: set the current shadow character as an intaglio character

Properties:

v1: a boolean value, representing whether it is an intaglio character

Sub-elements: N/A

2.6.2.31. CLIP_AREA

Semantics: set the current clip area

Properties: N/A

Sub-elements:

cliparea: PATH type, representing the clip area

2.6.2.32. FONT

Semantics: set the font used by some encoding/character set, for example set English character to use "Arial" font.

Properties:

v1: a character string, representing the encoding/character set.

v2: a character string, representing the font that will be used by the encoding/character set.

Sub-elements: N/A



2.6.2.33. OUTLINE_BORDER

Semantics: set the border width of the current outline character

Properties:

v1: a floating point number, representing the border width.

Sub-elements: N/A

2.6.2.34. OUTLINE_WIDTH

Semantics: set the outline width of the current outline character

Properties:

v1: a floating point number, representing the outline width.

Sub-elements: N/A

2.6.2.35. HOLLOW_BORDER

Semantics: set the border width of the current hollow character

Properties:

v1: a floating point number, representing the border width.

Sub-elements: N/A


2.7. Default Value of Graphics State


line color: black

fill color: black

character shadow color: black

character outline color: black

text color: black

line width: 1

line cap style: END_BUT

line join style: JOIN_MITER

miter limit: 10

fill rule: RULE_WINDING

render mode: LINE

raster operation: ROP_COPY

text direction: HEAD_LEFT

character direction: HEAD_TOP

character rotation: ROT_CENTER, no rotation

character slant: non-slant

character width: undefined

character height: undefined

character weight: 0

character style: normal style (no shadow, not hollow, no outline)

text transformation matrix: identity matrix ( [1, 0, 0, 1, 0, 0] )

image transformation matrix: identity matrix

path graphics transformation matrix: identity matrix

extension transformation matrix: identity matrix

clip area: current page.

font: undefined

3. UOML Instructions



UOML Instructions are used to define operations to UOML objects, such as create a Docbase, insert a sub-object, delete a object, change attribute of a object, etc.



This chapter will define the syntax and semantics of the following UOML instructions

3.1. OPEN

Semantics:

OPEN creates or opens a Docbase.

Properties:

create: a boolean value, representing whether to create a Docbase if it does not exist, default value is "true".

del_exist: a boolean value, representing whether to delete the Docbase if it already exists, default value is "false"..

path: a character string value, representing the path of a Docbase.

Sub-elements: N/A

Return value:

If it succeeds, the returned RET element contains a 'stringVal' sub-element with the 'name' property as HANDLE and the 'val' property to represent the handle of the Docbase.

If it fails, the return value is defined by RET.

EXAMPLE: create a docbase, named 1.sep

<uoml:OPEN path="/home/admin/storage/1.sep" create="true" del_exist="false"/>

3.2. CLOSE

Semantics:

CLOSE closes a Docbase

Properties:

handle: a character string value, representing the handle of the Docbase to be closed.

Sub-elements: N/A

Return value:

Defined by RET

EXAMPLE: close a docbase.

<uoml:CLOSE handle="db_handle_xxxxx"/>

3.3. USE

Semantics:

USE sets an object as the current object

Properties:

handle: a character string value, representing the handle of current object to be set up.

Sub-elements: N/A

Return value:

Defined by RET

EXAMPLE: set up the handle represented object as current object.

<uoml:USE handle="obj_handle_xxxxxx"/>

3.4. GET

Semantics:

GET can retrieve the sub-object handle, the count of sub-objects, the property value of an object, a page bitmap.

Properties:

usage: a character string value, representing the usage of GET. The possible values include GET_SUB, GET_SUB_COUNT, GET_PROP, GET_PAGE_BMP, representing respectively getting sub-object, getting sub-object count, getting properties, getting page bitmap.

handle: a character string value, representing object handle of the current operation. It is optional, if not exists, use the handle set by USE instead.

Sub-elements:

pos: used when usage=GET_SUB. It has one property listed below.

Property of this sub-element:

val: represents position number of the specified sub-object, starts from 0.

Sub-element of this sub-element: N/A



property: used when usage=GET_PROP. It has one property listed below.

Property of this sub-element:

name: represents the getting property name.

Sub-element of this sub-element: N/A



disp_conf: used when usage=GET_PAGE_BMP. It has five properties and one option sub-element listed below.

Properties of this sub-element:

end_layer: represents the end layer of drawing operation (the drawing operation ends at this layer and this layer is not drawn any more)

resolution: represents resolution of bitmap

format: represents bitmap format. The only valid value is "bmp", representing the uncompressed BMP format.

output: represents whether to put out to the file or to the memory and the value to be chosen is FILE or MEMORY;

addr: represents the path of output file or memory address.

Sub-element of this sub-element:

clip: represents clip area for output, PATH type.



Usage Value / Return Value:

return value based on usage value.



GET_SUB_COUNT: If the usage is GET_SUB_COUNT, indicates to get the number of sub-objects of this specific object. In this case, there is no sub-element needed. The return value, which is within RET, contains one 'intVal' sub-element, and its 'name' property is "sub_count",'val' property represents number of sub-objects.



GET_SUB: If the usage is GET_SUB, indicate to get the handle of some specific sub-object. In this case, GET contains sub-element of 'pos'. The return value, which is within RET, contains one 'stringVal' sub-element, and its 'name' property is handle, its 'val' property presents this sub-object's handle



GET_PROP: If the usage is GET_PROP, indicate to get some specific property of this specific object. In this case UOML instruction GET shall contain sub-element of 'property'; If the operation succeeds, the sub-element of return value, which is within RET, is not certain and the concrete sub-element name relies on the type it has got, the 'name' property of the sub-element is the property name to get, 'val' property is the value of the property.



GET_PAGE_BMP: If the usage is GET_PAGE_BMP,indicate to get the this specific page bitmap In this case, GET shall contain sub-element 'disp_conf'; It only use return value defined by RET

When it fails, the return value is defined by RET.


EXAMPLE 1: get the total number of sub-objects of the specific object

<uoml:GET handle="obj_handle_xxx" usage="GET_SUB_COUNT"/>


EXAMPLE 2: get a specific sub-object handle

<uoml:GET handle="obj_handle_xxx" usage="GET_SUB">

<pos val="0"/>

</uoml:GET>


EXAMPLE 3: get specific property of the object

<uoml:GET handle="obj_handle_xxxxx" usage="GET_PROP">

<property name="start"/>

</uoml:GET>


EXAMPLE 4: get specific page's bitmap

<uoml:GET handle="page_obj_handle_xxx" usage="GET_PAGE_BMP">

<disp_conf format="bmp" output="FILE" end_layer="1" resolution="600"

path="/home/admin/output/page.bmp">

<clip>

<SUBPATH data="s 0,0 l 3000,0 l 3000, 5000 l 0, 5000 l 0,0"/>

</clip>

</disp_conf>

</uoml:GET>


3.5. SET

Semantics:

SET property values for object. It may contain one to multiple sub-element(s) listed below.

The 'name' property of the sub-element represents which property of specific object will be modified.

The 'val' property of the sub-element contains the new property value.

Properties:

handle: a character string value, representing the handle, of whose property value needs to be modified. It is optional, if not exists, use the handle set from USE instead.

Sub-element:

intVal: set up integer type value, INT type

floatVal: set up float type value, DOUBLE type.

timeVal: set up time value, TIME type.

dateVal: set up date value, DATE type.

dateTimeVal: set up date and time value, DATETIME type.

durationVal: set up time duration value, DURATION type.

stringVal: set up string type value, STRING type.

binaryVal: set up binary type value, BINARY type.

compoundVal: set up compound type value, COMPOUND type.

boolVal: set up boolean type value, BOOLEAN type.

Return value:

defined by RET.

EXAMPLE: set specific object's angle property.

<uoml:SET handle="obj_handle_xxxxxx">

<floatVal name="angle" val="0.1"/>

</uoml:SET>



3.6. INSERT

Semantics:

INSERT inserts an object under another one as its sub-object.

Properties:

handle: a character string value, representing the handle of parent-object. It is optional. If not exist, use the handle set from USE instead.

pos: int value, representing the inserting place, starts from 0. It is optional. If not exist, insert after the last sub-object.

Sub-element:

xobj: xml expression of the sub-object.

Return value:

If the insertion succeeds, RET shall contain one sub-element 'stringVal' and its 'name' property is handle, its 'val' property represents the handle of the newly inserted sub-object.



EXAMPLE 1: insert a text data

<uoml:INSERT pos="1"/>

<xobj>

<TEXT origin="100, 200" encode="ASCII" text="UOML" spaces="20,20,20"/>

</xobj>

</uoml:INSERT>


EXAMPLE 2:insert a layer.

<uoml:INSERT handle="page_obj_handle_xxxxxx">

<xobj>

<LAYER/>

</xobj>

</uoml:UOML_INSERT>

3.7. DELETE

Semantics:

DELETE deletes an object.

Properties:

handle: a character string value, representing the object to be deleted. It is optional, if not exist, use the handle set from USE instead.

Sub-element: N/A

Return value:

Defined by RET

EXAMPLE: delete an object

<uoml:DELETE handle="img_obj_handle_xxx"/>



3.8. SYSTEM

Semantics:

SYSTEM executes system maintenance. Within this version, it has only one function: to save the docbase. It includes a sub-element:

flushto save the Docbase

Properties:

N/A

Sub-element:

flush: the 'handle' property of this sub-element represents the handle of a Docbase object and 'path' property represents the saving path for the Docbase.

Return value:

Defined by RET

EXAMPLE: save the Docbase example.sep

<uoml:SYSTEM>

< flush handle="docbase_handle_xxxxx" path="/home/admin/storage/example.sep"/>

</uoml:SYSTEM>

3.9. RET

Semantics:

RET is the return value from DCMS to application software, which may contain one to multiple return values and each value is represented by one sub-element( which can be boolVal, stringVal, intVal, floatVal, compountVal etc.).

The 'name' property of the sub-element represents the name of this return value.

If the return value is a simple type, the 'val' property of sub-element contains the return value.

If the return value is a complicated type, a sub-element will be added under the corresponding sub-element to represent the complicated return value.

For example: <boolVal name="SUCCESS" val="true"/>

Properties: N/A

Sub-element:

intVal: integer type return value, INT type

floatVal: float type return value, DOUBLE type.

TimeVal: time type return value, TIME type.

DateVal: date type return value, DATE type.

DateTimeVal: date and time type return value, DATETIME type.

DurationVal: time duration type return value, DURATION type.

StringVal: string type return value, STRING type.

BinaryVal: binary type return value, BINARY type.

CompoundVal: compound type return value, COMPOUND type.

BoolVal: boolean type return value, BOOLEAN type.

Note:

RET contains at least one 'boolVal' sub-element to describe whether the operation is successful or not. Its 'name' property is SUCCESS, and its 'val' property describes whether it is successful.

When the operation fails, RET also contains one 'stringVal' sub-element. Its 'name' property is ERR_INFO, and its 'val' property describes the failure information; for other return value, check the definition of concrete instruction for reference.

EXAMPLE: Return three values.

<uoml:RET>

<intVal name="xxx" val="0"/>

<boolVal name="SUCCESS" val="false"/>

<stringVal name="ERR_INFO" val="required resource not available"/>

</umol:RET>

3.10. Definition of Referenced Type

3.10.1. INT

Properties:

name: a character string value, xs:string type

val: xs:integer type

Sub-element: N/A



3.10.2. DOUBLE

Properties:

name: a character string, xs:string type

val: xs:double type

Sub-element: N/A



3.10.3. LONG

Properties:

name: a character string, xs:string type

val: xs:long type

Sub-element: N/A



3.10.4. DATE

Properties:

name: a character string, xs:string type

val: xs:date type

Sub-element: N/A



3.10.5. TIME

Properties:

name: a character string, xs:string type

val: xs:time type

Sub-element: N/A



3.10.6. DATETIME

Properties:

name: a character string, xs:string type

val: xs:datetime type

Sub-element: N/A



3.10.7. DURATION

Properties:

name: a character string, xs:string type

val: xs:duration type

Sub-element: N/A



3.10.8. STRING

Properties:

name: a character string, xs:string type

val: xs:string type

Sub-element: N/A



3.10.9. BINARY

Properties:

name: a character string, xs:string type

val: xs:base64Binary type

Sub-element: N/A



3.10.10. BOOL

Properties:

name: a character string, xs:string type

val: xs:boolean type

Sub-element: N/A



3.10.11. COMPOUND

Property:

name: a character string, xs:string type

Sub-element:

arc: ARC type

bezier: BEZIER type

circle: CIRCLE type

cmd: CMD type

rgb: COLOR_RGB type

doc: DOC type

docbase: DOCBASE type

docset: DOCSET type

ellipse: ELLIPSE type

embedfont: EMBEDFONT type

fontlist: FONTLIST type

fontmap: FONTMAP type

image: IMAGE type

layer: LAYER type

line: LINE type

matrix: MATRIX type

meta: META type

metalist: METALIST type

page: PAGE type

path: PATH type

rect: RECT type

roundrect: ROUNDRECT type

subpath: SUBPATH type

text: TEXT type

objstream: OBJSTREAM type

Note:

Each sub-element may occur 0 to multiple times

4. Conformance


In order to conform to this specification, an implementation:



A conformance implementation SHALL satisfy the conformance requirements of the applicable parts of this specification.

Appendix A. Acknowledgments

The following individuals have participated in the creation of this specification and are gratefully acknowledged:



Participants:

Alex Wang, Sursen Corporation

Xu Guo, Sursen Corporation

Allison Shi, Sursen Corporation

Liwei Wang, Sursen Corporation

Stephen Green, Individual

Charles H. Schulz, Ars Aperta

Pine Zhang, UOML Alliance

Mendy Liu, UOML Alliance

Andy Li, Changfeng Open Standards Platform Software Alliance

Lin Cheng, Beijing Redflag CH2000 Software Co. Ltd.