Hi,
I think Lars is right here. I've checked what SVG does: It has the
following classes of conformance rules:
* G.1 Introduction
* G.2 Conforming SVG Document Fragments
* G.3 Conforming SVG Stand-Alone Files
* G.4 Conforming SVG Included Document Fragments
* G.5 Conforming SVG Generators
* G.6 Conforming SVG Interpreters
* G.7 Conforming SVG Viewers
They say something about conforming document per se. They say something
about implementations that produce documents. And they say something
about implementations that interpret and view documents. But they say
nothing about implementations used to edit documents. Why not?
If we look at the above conformance rule classes they have something in
common. They say something about a single document instance.
In the context of metadata, we are talking about conformance of
applications used to edit documents. Editing involves two documents, the
original one, and the document that has been edited. So we are talking
about two document instances. Furthermore, file formats are used in
general to encode information. When editing a document, the information
contained in a document is changed. That means, the two documents
actually contain different information. We, at the time we write our
specification, don't know what is different. We only know that something
is different, otherwise the document would not have been loaded and
saved again.
The question is now: Can we in our conformance definitions make
assumptions about the relation of two documents that encode different
information? I don't think so. At least not until we have exactly
specified what operation has taken place between loading and saving
documents. But if we define these operations, we actually start to
define application behavior. That is, we start to define how an
application shall behave if the user calls a menu entry, etc. I think we
are in agreement that this does not belong into a standard for a file
format. File format specification for XML based file formats define what
the meaning of XML elements and attributes is, but they do not define
how this elements and attributes get into a document, nor what happens
to them if a document is modified. This of cause could be standardized,
too, but that would be a standard for office application behavior, and
that's not what we are working on.
However, if we cannot resolve the issue using conformance clauses, how
can we resolve it all?
Maybe we can resolve the issue similar as accessibility SC. The
accessibility SC also has defined some new features for ODF. They have
been added to ODF. They are all optional from the specification point of
view, and the specification itself does not say anything how these
features are implemented by applications. It only states what
information they encode. But the accessibility SC is also working on
guidelines for authors and implementors. And these guidelines are
exactly the place where it is said how these features should be used in
implemented in order to achieve that documents get accessible.
So, maybe the solution is to work on such guidelines for metadata, too?
Just my two cents.
Michael
Lars Oppermann wrote:
> Rob,
>
> This is am important point. The kind of conformance that is dealt with
> in standards such as HTML is quite different. HTML is mostly authored
> once and then rendered by various browsers. Interoperbility with
> optional or even 'forign' elements and attributes in that case means
> that the UA should still render the page as good as it can and it
> shouldn't crash. HTML UAs are not round-tripping HTML.
>
> Office documents are edited by many different people, hence the
> situation is a very different one.
>
> I am not saying that this cannot be resolved. However, it is not
> appropriate to apply HTML-reasoning (one author - multiple readers) to
> office documents (multiple authors/readers).
>
> Consider the following example. Given a paragraph with an id (I am not
> using xml:id here as the example is meant to be more general):
>
>
> Assume someone opens this document in a text processor, selects the
> string "Lars" and changes it to "Hamlet". Or maybe they would select all
> the text and type "This is not a paragraph"...
>
> Now, if the specification would mandate the preservation of the my:id
> attribute at all costs, the document may have become inconsistent;
> depending on the specific semantics of the my:id attribute.
>
> Thus, just preserving unknown information while changing the document is
> not always appropriate. When a paragraph is edited, does it become a new
> paragraph? When is a document just a revision and when is a different
> document? In my opinion such questions cannot be answered in the
> specification. Henceforth we should be very careful about mandating
> application behavior.
>
> /Lars
>
> robert_weir@us.ibm.com wrote:
>>
>> I think you're reading too much into the IETF's definition of MAY. It
>> explicitly says that a vendor is permitted to omit the item, though it
>> must accommodate itself and degrade functionality as necessary. What
>> is not permitted is that the application utterly crash when presented
>> with an item it does not understand. At least that is the way it
>> works for the IETF standards I'm familiar with.
>>
>> Although intuitively we want to say, "Preserve metadata unless the
>> user explicitly intended otherwise," I don't see how to express this
>> in standards terms. We can't have a conformance depend on "user
>> intent". And reference to a user doesn't help. Documents can be
>> processed by automation, and I think we would equally be unhappy if
>> metadata were arbitrarily stripped there. In any case, I think we
>> need to work along the lines of "shall be capable of" or "shall allow
>> at least one mode of operation where" or something like that. That
>> would be testable.
>> You suggested that a devious implementation might makes this mode of
>> operation hard to find in order to hurt interoperability. But then I
>> could also suggest a devious user who arbitrarily deletes metadata in
>> order to hurt interoperabiity. I'm not sure a document format
>> standard can prevent either.
>> -Rob
>>
>>
>> marbux