[no subject]

8. It is somewhat difficult to know exactly how your proposed model should
work. The markup approaches taken in your submission on 9 July and in your
more recent submission are difficult to reconcile. There seem to be multiple
ways of associating captions with the text to which they relate. Your model
creates containers and it allows them to be arranged hierarchically but they
can also appear in any order, repeatedly, at the top level. Captions can
float around almost anywhere. It seems to us that an author **could** easily
create a structure that completely avoids representation of the true
hierarchical structure of the document and would make the data no more
useful than HTML.


9. Further, there is no way of knowing what function a block is to perform.
To know what these containers are, one has to add rdf:type elements to
blocks everywhere. Users can effectively call any object anything they like
from the dictionary. We believe this will completely frustrate document
authoring. This will occur at two levels:

(a) The proposal throws all the burden for producing consistent data onto
the drafting application. You say: "...its relatively foolish to pretend
that the vast majority of attorneys will ever want to enter XML directly --
they'll use products that'll choose the correct XML elements for them, that
will then write the markup for them."
This is a massive oversimplification of the problem. None of us is expecting
or advocating that anyone should enter XML markup directly, as in a text
editor. In our experience, it is possible to provide a very easy to use
interface for XML authoring so that it can be significantly simpler than
using a word processor such as Word for most operations.
Under your model, it will be necessary for the drafting interface to define
the type of document you want to create so that the user can pick objects
and apply the correct rdf:type values. In effect, the drafting interface
becomes the Schema. This potentially means that the interface is much more
complicated and less flexible than under a true structural model.

(b) Unfortunately, the initial, sequential authoring is only the start of
most document creation. Authors need to re-order content both in sequence
and in hierarchical relationship as they edit their work. As soon as this
happens, the author comes face to face with the markup. The application can
help with common operations but it gets harder to shield the author. We have
not seen any XML authoring application which can avoid this with any kind of
structural model. Your RDF proposal will make it extremely difficult to edit
content because many such operations will require changes to the metadata.
We know of no XML authoring tools that could provide authors with a simple
way of doing this based on the RDF syntax. In other words, there is no
current application support for your approach. RDF authoring tools that are
available are not designed as general content editors that could be used for
preparation of contracts or other office documents.


10. Most users cannot consistently tell you whether an object is a clause, a
subclause a paragraph a list item or whatever. What's more, they don't care.
This was explained by reference to the example in the clause model
requirements. As a general proposition, there is no reason to ask them to
use these terms in the markup. The hierarchical and sequential relationship
of objects is all that is needed for basic processing. It would not matter
if item was changed to "gorp", it would work just as well. Its just that
"item" is not as ugly a word as gorp and it distinguishes the element from
block or para (whichever is used).


11. Despite your assertion to the contrary, the Harrop/Meyer item model
avoids presentation information entirely in its basic element structure.
Component numbering is not presentational and cannot be equated with
pagination. Component numbering is part of the content and part of the
structure. Its omission from your model is a serious problem. It is not
realistic to expect a sender and receiver's applications to generate the
same numbering in all but the simplest of cases. It is not a scaleable
approach to build a model on the assumption this will work.


12. Now to the real problem. You promote the RDF model as something that is
the way of the future for document markup. We do not believe there is any
evidence of this. Fundamentally, we do not see how the use of RDF for
document markup is within the anticipated use of the standard. RDF (Resource
Description Framework) is intended to describe information objects,
documents, people & organisations etc. Its about marking up data not
narrative text content. The use of bag, seq and alt is consistent with this
approach. They provide a way of typing data that is not particularly helpful
when marking up text content.

The RDF standard states:
	"The development of RDF has been motivated by the following uses, among
others:
	* Web metadata: providing information about Web resources and the systems
that use them (e.g.
	  content rating, capability descriptions, privacy preferences, etc.)
	* Applications that require open rather than constrained information models
(e.g. scheduling
	  activities, describing organizational processes, annotation of Web
resources, etc.)
	* To do for machine processable information (application data) what the
World Wide Web has
	  done for hypertext: to allow data to be processed outside the particular
environment in which it
	  was created, in a fashion that can work at Internet scale.
	* Interworking among applications: combining data from several applications
to arrive at new
	  information.
	* Automated processing of Web information by software agents: the Web is
moving from having
	  just human-readable information to being a world-wide network of
cooperating processes. RDF
	  provides a world-wide lingua franca for these processes."
		Source: http://www.w3.org/TR/rdf-concepts/#section-motivation

The overwhelming flavour of all this is data markup, not document content
markup.
RDF should have a long and fruitful life as a data description language.


13. The item based structural model is not intended to be a complete model
at this stage. The process clearly laid out in the clause model requirements
is to separate issues and to concentrate at first on the basic structural
model for the data and to then deal with other issues. It is clear that much
needs to be added to make it complete. One of those things is metadata
discussed in point 2 above. It may well be the case that RDF will provide a
very good basis for metadata structures in the model. We see no reason why
it should not be added (This will require full namespace support so will
necessitate use of Schema or a very complex DTD implementation). However,
this is an issue yet to be addressed.


14. You have raised the issue of linking as one of the justifications for
use of RDF. Linking is out of scope for the structural markup requirements.
There are several approaches that may be taken to linking. These should be
considered in due course. There is no reason why your requirements should
not be included at that stage. Fundamentally, there is no reason why any
desired linking functionality cannot be provided without using RDF for core
structural markup.


15. In summary, we believe the RDF proposal is not the way of the future:
(a) Its an inappropriate use of the RDF standard. It was never envisaged
that the standard would be used to markup document content in this way. The
RDF approach offers no advantages for basic structural markup. There is no
reason to believe that developers will support your approach to RDF markup
in their document authoring applications. Without such support no one will
use the model. By contrast, the structural approach of the Harrop/Meyer
approach is tried and true.

(b) It adds only complexity to a simple problem. It mingles metadata and
structural concepts in a way that burdens authors and application
developers. The proposal clearly fails under requirement 8.

(c) It is doubtful that it will produce sufficiently consistent markup that
it will meet the needs of application developers who need markup of distinct
components for content re-use and sharing. There are too many ways different
authors can markup the same content. It is seriously doubtful that it will
satisfy requirements 2 and 9.


Regards
Peter Meyer


---------------------------------------------------------------------------
Elkera Pty Limited (ACN 092 447 428) - Knowledge management
Email: pmeyer@elkera.com.au
Ph: +61 2 8440 6900 * Fax: +61 2 8440 6988
http://www.elkera.com.au