MHonArc v2.5.0b2 -->
office message
[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]