Re: [office-metadata] Groups - ODF-Metadata-Proposal-22August2007(07-08-22-ODF-Metadata-Proposal.odt) uploaded

[Patrick Durusau <patrick@durusau.net>]

Marbux,

You would contribute more effectively to this work if you would become 
familiar with modern programming techniques that don't require the byte 
for byte sameness that you seem to equate with interoperability. Sure, 
byte for byte sameness is one way to achieve interoperability but it is 
an extremely limited one and employed mostly by MS VB 1.0 vintage 
programmers. Programming techniques and applications have improved a 
good bit since then.

The problem with byte for byte compatibility "interoperability" 
requirements is that we have to guess "right" at the sweet spot for the 
requirements that we mandate that all applications must meet. If we 
guess wrong, too few features or too many, then the standard will be 
irrelevant to people writing applications.

I am sure one of your complaints, if you could articulate a technical 
complaint, would be that xml-id is optional on the elements where it 
will appear in the revised ODF standard. Yes?

What that means is that if I want to write an ODF based application that 
is solely concerned with adding in-content metadata to a document, say 
in a clerk of court office, that processes the file as a stream, adding 
attributes and markup as appropriate based on content, I don't have to 
support the use of xml-id. And why would I? Oh, yes, because the MS VB 
1.0 vintage programming contingent in the ODF TC said that I had to 
support it so it would fit their notion of interoperability.

What ODF 1.2 will do, I hope, is provide a set of features that when 
implemented support interoperability for features that are implemented 
and provide a basis for more sophisticated applications that routinely 
support things like use of xml-id. What features are implemented is a 
matter of market forces.

Imposing some universal overhead works, sometimes, if you are MS. You 
know, you can't say that MS hides behind screen names or disses work 
without offering a constructive (at least in their view) alternative. So 
I guess you should add those to your list of how you are different from MS.

BTW, you really don't need to bother the ODF TC lists with your various 
diatribes. You can just send them directly to me as I have set a marbux 
kill filter so you can enjoy writing your posts and I won't have to 
manually delete them.

Patrick

marbux wrote:
>
>
> On 22 Aug 2007 20:35:51 -0000, *patrick@durusau.net 
> <mailto:patrick@durusau.net>* <patrick@durusau.net 
> <mailto:patrick@durusau.net>> wrote:
>
>     Greetings!
>
>     After much hard work by all concerned I am pleased to announce the
>     final
>     version of the Metadata Proposal has now been filed!
>
>     Special thanks to all the member of the SC who made this possible.
>
>
> It's a spectacular achievement, Patrick. Only a single requirement in 
> the whole document and even it uses the undefined term, "mandatory." 
> But did you get Sun's ok for having any mandatory requirements at all?
>
> In reviewing the document, I was struck by how adroitly its authors 
> managed to avoid using defined requirements terms. Only 7 occurrences 
> of "may" and 3 of "should," and even those negated by not being placed 
> in boldface. See ODF 1.2 draft, section 1.2 (terms to be interpreted 
> as defined by ISO Directives only "if they appear in bold letters." 
> Creative writing teachers may counsel avoidance of the passive voice. 
> See e.g., Wikipedia ("Many English educators and usage guides, such as 
> The Elements of Style, discourage the use or overuse of the passive 
> voice, seeing it as unnecessarily verbose (when the agent is included 
> in a by phrase), or as obscure and vague (when it is not)." < 
> http://en.wikipedia.org/wiki/English_passive_voice>.
>
> But hey, Strunk & White weren't writing file format standards, were 
> they? In standards work, the passive voice is the least confining 
> voice, akin to elastic graph paper that allows data outliers to be 
> stretched into the right position to support the hypothesis.
>
> Indeed, it is obvious that studious avoidance of the active voice is 
> precisely what enabled the document's authors to avoid having to make 
> all those hard decisions about what requirements terms should apply to 
> all those sentences. E.g., the very first sentence:
>
>     "Metadata in OpenDocument format is expressed using the model of
>     the W3C Resource Description Framework [RDF-CONCEPTS]."
>
>
> Notice how the difficult choice between use of the mandatory "SHALL" 
> and the permissive "SHOULD" was avoided by resort to the passive 
> voice? "Is expressed" is so much easier to write than "implementers 
> SHALL express" or "SHOULD express," precisely because of the ambiguity 
> induced by the  passive voice; to use the active voice would actually 
> require reaching consensus on troublesome and divisive topics like 
> interoperability.
>
>
> And this same bit of magic was worked on practically every sentence in 
> the document! I had no idea it was even possible to string together so 
> many consecutive passive sentences.
>
> I bow before masters of the art. I can only imagine the years of work 
> it took to produce a document with only a single mandatory 
> requirement. And who knows? Maybe the TC will get rid of that 
> requirement too and we can have a metadata proposal entirely free of 
> mandatory requirements.
>
> Kudos to all who participated. It is an incredible piece of work. You 
> have successfully quashed the forces of Interoperability.
>
>
> Best regards,
>
> Marbux

-- 
Patrick Durusau
patrick@durusau.net
Chair, V1 - US TAG to JTC 1/SC 34
Acting Convener, JTC 1/SC 34/WG 3 (Topic Maps)
Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)
Co-Editor, OpenDocument Format (OASIS, ISO/IEC 26300)