W3C is pleased to receive the "DrawML" submission from Excosoft AB.
DrawML is a language, written in XML, for describing simple diagrams such as process flow diagrams, organisation charts, and similar. Being written in XML, DrawML can be used together with other markup schemas in a single document. A DTD is provided, and it is possible to include this as an entity in a larger document type definition to produce valid XML documents which include DrawML diagrams. Availability of a Java implementation on the client is a requirement to use DrawML.
The defining characteristic of DrawML is that the artistic layout of the diagram is secondary to its structural nature, expressed through the hierarchical nature of XML, and that the precise layout determines on both the available drawing space on the display surface and the marked-up content which may be placed inside any DrawML shape. This content reflows, in a similar manner to the content of table cells, and this can trigger relayout of the diagram. This facilitates hand authoring and revision of documents containing diagrams which themselves contain text or other markup.
This makes DrawML a suitable candidate for a wide range of common diagramming tasks. It is not suited to (or intended for) artistic graphics, architectural drawings and the like where the precise graphical design is important; nor is it necessarily suited to complex diagrams such as electronic circuit schematics which would require more complex layout constraints and routing logic. By restricting the scope of the layout constraints, DrawML makes the automatic layout of diagrams a tractable problem.
The most similar specification to DrawML in terms of intended use is the Web Schematics submission. Technical similarities include the treatment of text within graphics as a first class object and the constraint that all graphical objectss have a well defined, rectangular bounding box within which child elements can be drawn.
Reflow of child shapes is limited to reflowing a one dimensional stack; children may be grouped either horizontaly or vertically, but not both. For example, it is not possible to request that child elements are grouped in a rectangle which is wider than it is tall, or grouped in a minimal area. However, these restrictions make the auto-layout problem tractable. There can be problems with routing of connectors between boxes when the canvas is resized, because polylines used for connectors are given absolute coordinates in points.
Compared to the primitives available in Web Schematics, DrawML has a smaller set of shapes and these cannot be extended through the markup; however the shape repertoire can be extended by writting additional Java class files which implement methods both to draw the new shape, so that it fits around its children, and to report its size, so that other shapes of which it is a child may lay themselves out. This eases document maintenance, since there is no extensibility in the XML, but also makes the creation of new shapes harder since these must be written in Java rather than built by aggregating graphical primitives.
Noting that the Java code for declaring new shapes is very simple, consisting of method invocations to draw lines, etc, it is possible that this graphical part could be made declarative and expressed in XML. The co-ordinates of the external and internal bounding boxes could then reference variables computed by the layout logic. Such an approach might remove the complete reliance on Java and allow implementations in a number of languages of which Java would be one possibility.
The interaction with style sheets, in particular:
has not been explored in the DrawML specification. This would seem to require a Java interface, not only to the CSS object model, but also to the CSS layout engine.
The assumption that child shapes are always laid out in a left-to-right, top-to-bottom manner make sense for many Western documents but is not internationalized. For example in a Hebrew or Arabic document, it would be more natural to have children placed right to left.
Excosoft are invited to join the Scalable Vector Graphics Working Group, to contribute their expertise with higher semantic level graphics, particularly for diagraming applications, to the design of the Scalable Vector Graphics specification. This group has already published a Requirements Document and expects to release an initial draft of the SVG specification in January 1999.
