OASIS Open Document Format for Office Applications (OpenDocument) TC

  • 1.  Re: [office] Re: [office-metadata] Suggested Changes on the Metadataproposal

    Posted 07-02-2007 08:19
    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 


  • 2.  Re: [office] Re: [office-metadata] Suggested Changes on the Metadataproposal

    Posted 07-02-2007 11:45
    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 


  • 3.  Re: [office] Re: [office-metadata] Suggested Changes on the Metadata proposal

    Posted 07-02-2007 13:08
    On Jul 2, 2007, at 7:45 AM, Michael Brauer - Sun Germany - ham02 - 
    Hamburg wrote:
    
    > 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?
    
    It seems to me the question of preservation for accessibility is the 
    same as that for metadata. If an application strips accessibility 
    attributes silently, it's the same problem as if they do so with an 
    xml:id attribute.
    
    Therefore, while I can't speak for the accessibility group, I tend to 
    believe that dealing with this issue piecemeal is rather inadequate. It 
    should be done in a general conformance section.
    
    E.g. if the metadata SC creates some "Metadata in ODF Guidelines and 
    Suggestions" document, it should NOT be our job there to tell 
    developers not to strip attributes or delete files.
    
    Bruce
    
    


  • 4.  Re: [office] Re: [office-metadata] Suggested Changes on the Metadataproposal

    Posted 07-02-2007 13:54
    Hi Bruce,
    
    Bruce D'Arcus wrote:
    > 
    > On Jul 2, 2007, at 7:45 AM, Michael Brauer - Sun Germany - ham02 - 
    > Hamburg wrote:
    > 
    >> 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?
    > 
    > It seems to me the question of preservation for accessibility is the 
    > same as that for metadata. If an application strips accessibility 
    > attributes silently, it's the same problem as if they do so with an 
    > xml:id attribute.
    
    I of cause can't speak for the a11y SC as well, but I believe the reason 
    the current solutions works for them is because they assume that all 
    vendors are interested in allowing to create accessible documents with 
    their applications, and that therefore no application will silently 
    remove the a11y information. And if it would, the resulting document 
    wouldn't be accessible.
    
    As for metadata: Metadata are cool feature, and the SC has created a 
    very good specification. I therefore believe that vendors are really 
    interested in implementing that part of the specification. So, I don't 
    think that we in practice really have an issue.
    
    > 
    > Therefore, while I can't speak for the accessibility group, I tend to 
    > believe that dealing with this issue piecemeal is rather inadequate. It 
    > should be done in a general conformance section.
    
    In my mail I have provided some concerns regarding formal conformance 
    rules that are related to editing documents. Do you think these concerns 
    are justified?
    
    Michael
    
    
    -- 
    Michael Brauer, Technical Architect Software Engineering
    StarOffice/OpenOffice.org
    Sun Microsystems GmbH             Nagelsweg 55
    D-20097 Hamburg, Germany          michael.brauer@sun.com
    http://sun.com/staroffice         +49 40 23646 500
    http://blogs.sun.com/GullFOSS
    
    Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1,
    	   D-85551 Kirchheim-Heimstetten
    Amtsgericht Muenchen: HRB 161028
    Geschaeftsfuehrer: Marcel Schneider, Wolfgang Engels, Dr. Roland Boemer
    Vorsitzender des Aufsichtsrates: Martin Haering
    


  • 5.  Re: [office] Re: [office-metadata] Suggested Changes on the Metadata proposal

    Posted 07-02-2007 14:02
    On Jul 2, 2007, at 9:53 AM, Michael Brauer - Sun Germany - ham02 - 
    Hamburg wrote:
    
    >> Therefore, while I can't speak for the accessibility group, I tend to 
    >> believe that dealing with this issue piecemeal is rather inadequate. 
    >> It should be done in a general conformance section.
    >
    > In my mail I have provided some concerns regarding formal conformance 
    > rules that are related to editing documents. Do you think these 
    > concerns are justified?
    
    Yes. I'm not necessarily meaning formal "rules." I agree with the 
    thrust of this discussion that this would be difficult.
    
    Bruce