[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]