[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Metadata Charter
Greetings! A couple of quick comments for the discussion later today: 1. From the comments I have seen, I think there is a general feeling that the requirements and use case deliverables should be combined into one deliverable: > 1. A list of meta data use cases for OpenDocument documents and > OpenDocument > enabled applications, together with a classification of the use cases. > 2. A list of meta data related requirements for future versions of > OpenDocument, which will be prioritized by the OpenDocument TC. With just a little judicious editing those can be arranged in such a way as to allow the OpenDocument TC to set priorities for further deliverables. 2. On the "main" editing tool portion of the charter: > The proposed enhancements further must consider office applications as > the > main editing tool for OpenDocument documents, which means, they must not > conflict with the processing model of OpenDocument documents for office > applications. a. I don't think that not being in "conflict with the processing model of OpenDocument documents for office applications" has any relationship to "consider[ing] office applications as the main editing tool for OpenDocument documents...." Further, I think the suggestion has been made that levels of conformance, the default I suppose being the "ignore but preserve" strategy of the current standard, be specified for any metadata additions. I rather like the idea of conformance levels for metadata support. **A use case/example of non-office application editing an OpenDocument document follows, feel free to ignore as the main points are above.** Background: Bankruptcy courts in the US are used by individuals and corporations who are unable to pay their debts as they come due. The filing of a bankruptcy petition (a highly stylized form) triggers certain legal consequences for others, even if they are unaware of the bankruptcy filing. The following senario is based on my memory of bankruptcy procedure which is almost 20 years out of date but should be generally valid in terms of the steps. A bankruptcy petition is electronically filed in ODF format with the clerk of the bankruptcy court. That transmission is accepted by the Durusau-Bankruptcy module which does a number of things. It validates the petition according to the local rules, such as verifying that the attorney of record has been admitted to the local bar and more importantly, initiates a transfer of funds to the clerk's office to pay the filing fee. Assuming the petition is accepted, the petition is accepted and electronically signed by the module. As a consequence of filing, bankruptcy notices have to be generated and delivered to all the creditors listed in the petition, any banks where accounts are held, etc. Those notices are automatically generated, in ODF format, and electronically delivered to all the creditors, banks, local law enforcement (who are often in charge of selling property seized in court proceedings), etc. As electronic acknowledgements arrive concerning that notice, both the delivery and acknowledgement information is written to the ODF doucment from the debtor that lists those parties. Creditors file their claims in ODF format and the metadata in those documents is used to write further information to the documents submitted by the debtor concerning the claim of that particular creditor. (This is not required by ODF but suggested so that any creditor can obtain a copy of the appropriate document and have all the current information on claims and the basis for them, with links to the original documents.) Note that none of the writing to the file has been done with anything that could be considered a traditional office application. Nor is it necessary that the application in question be able to engage in processing of the OpenDocument in any traditional sense of the word. It need only be able to process the portion of the metadata necessary to do its task and no more. Whatever processing model it uses for that task should be irrelevant, so long as it results in a comformant ODF document. Actually, for security purposes, I suspect that none of the process could be invoked other than by the automated process. Apologies for going on at such length but I think it is important to realize that ODF has the potential to enable this sort of automated and collaborative processing without everyone having to adopt a single vendor solution. Hope everyone is at the start of a great day! Patrick -- Patrick Durusau Patrick@Durusau.net Chair, V1 - Text Processing: Office and Publishing Systems Interface Co-Editor, ISO 13250, Topic Maps -- Reference Model Member, Text Encoding Initiative Board of Directors, 2003-2005 Topic Maps: Human, not artificial, intelligence at work!
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]