OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office-metadata message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


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.

Cute, Patrick, very cute. Only it doesn't wash.

Let's see. You begin with an ad hominem attack, the insinuation that my knowledge of interoperability is limited to that of "MS VB 1.0 vintage programmers." Knowing that ad hominem attacks are a logical fallacy (and as a former lawyer yourself, you assuredly do as well), I feel complimented, as I did every time in the courtroom that an opponent attacked me personally instead of the substance of my argument. It's like waving a red flag at the judge that you have nothing of substance on the merits of your position.

Next you serve your first straw man argument, another logical fallacy, mischaracterizing my position as being one that argues for byte-for-byte interoperability.  Odd that you didn't bother to link a post in the archives where I made such an argument, isn't it?  Well, you and I know why you didn't provide a link; it's because I never made such a ridiculous argument.

But having erected your straw man, you pretend to to demolish it with a non sequitur, yet another logical fallacy, your premise that round-trip interoperability requires a 1:1 feature match among implementing applications. As to your non sequitur:

First, your argument fails on its own terms because there are well known ways to match features even when one app is more featureful than another using profiles. See e.g., the W3C Compound Document Formats, <http://www.w3.org/2004/CDF/>, with its extensive support for profiles via an interoperability framework that could feasibly be incorporated in ODF. See particularly, the Compound Document by Reference Framework conformance section, <http://www.w3.org/TR/2007/CR-CDR-20070718/#conformance>   

User Agent Conformance

  1. User agents must allow the child DOM to access the parent DOM.
  2. User agents must allow the parent DOM to access any child DOM. The contentDocument attribute must represent the child document.
  3. A conformant user agent of a superset profile specification must process subset profile content as if it were the superset profile content.
...

In short, no single "sweet spot" of required features in a file format standard need be identified. There can be as many "sweet spots" as are necessary.

Should I presume you are ignorant of such programming techniques? You seemed to personally advocate a "super format" very much like CDF only a month ago, in a comment at  <http://www.oreillynet.com/xml/blog/2007/07/can_a_file_be_odf_and_open_xml.html>, where you said:

"If we could craft, as both OpenDocument and OpenXML evolve, a standard abstraction that enables applications that deliver the format desired by a another application (as well as creating a super format with that mapping) then the overhead of that "extra" ability to interchange would be borne by those who really need it.

"Make no mistake, I think lossless interchange is an absolute necessity in many situations, but I am less certain that every application has to support it. I can easily imagine a public application site that allows a user to toss a file in the super format at it and the user is returned a file in a requested format. All of which are XML formats."

Second, you simply ignore the several previous times, most recently on August 13, <http://lists.oasis-open.org/archives/office/200708/msg00033.html>, when I have described the WordPerfect <unknown> tags that are used in that application to enable lossless round-tripping of documents among all versions of WordPerfect from 6.x to 13.x, despite feature mismatches between the versions, pointing out that it was a scheme very similar to the ODF foreign elements and attributes, but depended entirely on unknown metadata not being trashed by one of those WordPerfect versions. For a more detailed description of the WordPerfect handling of the <unknown> tags, see this post, <http://lists.oasis-open.org/archives/office/200707/msg00024.html>. So lossless round-trip interoperability among apps supporting the same file format is unquestionably feasible despite mismatches in features supported by implementing applications, and that is even without profiles.

Third, what I have actually advocated in regard to xml:id attributes is the necessity for a "shall preserve unless" gramatical construct that recognizes as many exceptions as are needed to accommodate any use case anyone could bring forward illustrating a need to destroy the atttributes. See e.g., my post here responding to one of yours, <http://lists.oasis-open.org/archives/office/200707/msg00024.html>, where I said:

"So thus far, we have "SHALL preserve unless destroyed through user-initiated action." Any other use cases that require exceptions?"

Not once did I ever argue that implementations should be required to "support" xml:id attributes as you claim.  It is a distinction you recognized yourself during the relevant discussion on the list, <http://lists.oasis-open.org/archives/office/200706/msg00137.html>. Here are your own words:

"I am curious about the term "support" in this context.

"Does preservation of data imply that a feature is supported?

"In other words, what if I have a very lite weight application that doesn't actually read any of the content of an ODF file or parse any of the existing metadata files but simply adds an entry to the metadata manifest to add metadata about the document as a whole (such as would happen in a clerk of court's office with filing date, who filed it, etc.) and added an appropriate metadata file. It then saves *all* of the file.

"Granted, I haven't implemented a lot of the features offered by ODF but I have preserved the file, even for features I don't support.

"Is there a useful distinction to make between implementation of a feature and preservation of a file's contents that you are given for processing?

"Granting that I could also implement a very lite weight application that doesn't offer metadata or any number of other features since we don't require an application to implement any specific set of features.

"So, is preservation separate from feature implementation? (I am asking because I haven't seen it raised in this context and while it seems evident to me the two are different, opinions may and probably do vary on that point.)"

And later, you personally started a separate thread of that discussion that you titled, "Preservation question." <http://lists.oasis-open.org/archives/office/200707/msg00016.html>.

In fact, the entire debate was about Sun's proposal to remove the mandatory requirement of preserving xml:id attributes and related metadata that as I recall you personally added to the draft Metadata proposal at the request of both Bruce and myself, not application "support" of the xml:id attribute feature. As was concisely explained by Bruce d'Arcus in response to Sun's 11th hour proposal to remove the mandatory preservation of xml:id attributes requirement, <http://lists.oasis-open.org/archives/office/200706/msg00125.html>:

"Preserving files and attributes is a trivial requirement. Not doing so will introduce large compatibility problems. Really, just to be clear: if applications do not preserve xml:id attributes, fields will break, and any metadata about document fragments will be made invalid. Is that really in anyone's interest? They need not support metadata in any explicit way to do this."

Bruce later elaborated, <http://lists.oasis-open.org/archives/office-metadata/200706/msg00066.html>.

"The bottomline is, because we move so much of the RDF logic into the package, the xml:id attributes become crucial anchor points. In short, if an application removes, say, the xml:id from a text:meta-field or otherwise causes the URI binding to be invalid, the field will break. It would be bad for interoperability for applications to do this."

And indeed, even Our Illustrious Chairman Brauer agreed it was all about preservation of metadata, not support for metadata, when he suggested:

"1. We may move all the metadata related should/shall language into the general conformance section. This has the advantage that it is not overlooked as easy as it would be if it is in the element and attribute description. It further has the advantage that metadata is mentioned at a very prominent position.

"2. We may introduce the term of a metadata-aware application (or something like that), and define conformance definitions along the following lines for it:
- A metadata aware ODF implementation *shall* not remove the xml:id attributes defined in sections [?] or change its values unless the removal or modification is the result of an edit operation caused be the user, or a similar action taken by some automatic processing of the document.
- [any other requirement that may exist]

"3. We may rephrase the above statement for general ODF implementation, replacing the *shall* with a *should*: - An ODF implementation *should* not remove the xml:id attributes defined in sections [?] or change its values unless the removal or modification is the result of an edit operation caused be the user, or a similar action taken by some automatic processing of the document."

<http://lists.oasis-open.org/archives/office-metadata/200706/msg00065.html >; see also my response at <http://lists.oasis-open.org/archives/office-metadata/200706/msg00072.html>.

I find it very difficult to believe that you simply forgot about that lengthy debate, Patrick, and the distinction between feature support and metadata preservation. But if you respond that you merely forgot, I cannot prove otherwise.

Fourth, atop your ad hominem attack, your straw man argument, and your non sequitur, you stack a use case that is yet another strawman, also premised on your grosss mischaracterization of my position as advocating mandatory "support" for xml:id attributes rather than my actual position of  advocating their mandatory preservation, except in specifically identified exceptional situations that can be demonstrated by use cases.

In your use case about the court document processor, what is the resulting harm if your hypothesized application is required by the ODF standard to preserve xml:id attributes created by another application? Is it the danger that a judge might open the document in yet another application that allows her to view the file? Or that she might open a copy of it in another editor that supports RDF metadata and be able to edit the document herself, perhaps adding her own annotations complete with metadata? Or is it the danger that she might use another application to automatically add hyperlinks links in the document to the Westlaw database corresponding to the content of the fields in the document's citations? See e.g., <http://west.thomson.com/westcitelink/>.

Of course you avoided all need to address such issues by grossly mischaracterizing my position and then belittling the mischaracterization. But that was not the only thing you avoided.

"Where are 'the conformity requirements that are essential to achieve the interoperability' in this situation, Patrick?"

<http://lists.oasis-open.org/archives/office-metadata/200708/msg00022.html> (my post quoting ISO/IEC Directives). Is your post I am responding to the best answer you will have to that question at JTC 1, Patrick, when ODF 1.2 arrives at ISO? You can duck, bob, and weave all you want, but that won't make the Directives go away.

Fifth, you top off your stack of logical fallacies with a somewhat wistful "hope:"

"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."

So your goal is a networked world where metadata is routinely trashed by apps developed by those who are too dumb or otherwise disabled to preserve metadata and only the big boys get to do interoperability, right? So if I send you a document for your editing, I can't count on getting it back with xml:id attributes intact.

No thanks, Patrick. That sounds way too much like how things have worked ever since office productivity software first came on the market. In your world, interoperability belongs only to those who can map features 1:1 with the most featureful apps. And that is precisely why OpenDocument never should have been approved as a standard. Your kind of interoperability makes ODF a de facto Sun Microsystems standard wearing the clothing of a de jure standard. Why not just standardize the whole world on Microsoft apps and be done with it? Are two monopolies maintained by an interoperability barrier between them better than one?

Fortunately, we don't have to debate the issue because the Directives resolve the issue. You lose under the rules of the game.

And may i remind you of something else you said, Patrick?

"I have worked for a very long time on the metadata proposal and I have every intention of ODF having an interoperable metadata mechanism. I think I know enough about both to make sure that happens."

<http://lists.oasis-open.org/archives/office-metadata/200706/msg00061.html>.

When, Patrick, when? And how? By private agreements among implementers? By an informative best practices guide? ISO/IEC Directives say that neither are good enough, that interoperability conformance requirements are mandatory. So why not deal with the problem instead of attacking the messenger?

By the way, I regard my criticism that the Metadata proposal as being non-compliant with the Directives as being constructive. And so was my sarcasm quoted following this post. The former pointed you to an enormous bug in the Metadata subcommittee's work. The latter pointed you more precisely to the sentences that need repair, the ones that are written in passive voice.

Or are you so blinded by your own vision of how you want things to be that bug reports are not welcome?

Best regards,

Marbux
(who still has a stack of personal emails from you addressing me by my given name)

 

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)




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]