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

 


Help: OASIS Mailing Lists Help | MarkMail Help

office message

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


Subject: [OASIS Issue Tracker] Issue Comment Edited: (OFFICE-2306) PublicComment: Comments on ODF 1.2 CD Part 3: Packages



    [ http://tools.oasis-open.org/issues/browse/OFFICE-2306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19110#action_19110 ] 

Michael Brauer edited comment on OFFICE-2306 at 5/5/10 6:09 AM:
----------------------------------------------------------------

Re 3.8.3 forward references to extended package consumer: OASIS rules requite that conformance clauses are at the end of the specification. Forward references therefore cannot be avoided. Making all of them explicit is an option, but appears not to be essential, since the term "conforming" already makes clear the we are talking of a conformance class here.

Re 3.8.4: manifest:full-path
Re: Why not a proper, absolute reference?: This comment is unclear. The attribute cannot be an absolute reference (in URI terminology) because the location of a package is not known. Within the package, the path is already absolute, since it contains all path segments from the package root up to the referenced files.
Re allowing URIs. This is a feature request that may be considered in future versions.

Re 3.8.6: manifest:start-key-generation-name
Re password: See previous comment
Support for encryption is not mandatory. The meaning of the term "support" seams to be clear from the context. The algorithms are linked to the conformance classes because only extended package allow the use of alternative algorithms.

Re 3.8.9: manifest:key-derivation-name
"should" should indeed be replaces with "shall" here.

Re 3.8.10: manifest:media-type
Suggestion: Remove: All files that have XML content should have the media type "text/xml".
Replace 2nd paragraph with: A manifest:media-type attribute should be present for all files and *directories* where a MIME media type exists for the content of the file or *document or sub document contained in a directory*.

Re 3.8.11: manifest:preferred-view-mode
Re "slide-show": Slide Show seems to be an appropriate term, since it includes running presentation effects. The suggested description would leave that open.
Re "read-only". This does not mean a preview, but a read-only (or non editable) document.
Re sound-level: This is a suggestion for a future version of ODF.
Re update of dynamic objects: This is a suggestion for a future version of ODF.
Re default value: Implementations may have complex strategies to choose the initial view mode of a document, and they may also allow the user to control this. For instance, an implementation may open document in a read-only mode if the document is physically read-only. This is a reasonable behavior. Mandating that such document are opened in an editable mode would disallow that behavior.

Re 3.8.12: manifest:salt
There are no length constrains, but it is of course up to the implementation to ensure that stack overflows do not occur.

Re 3.8.14: manifest:version
"The specified version refers to the format specified in the
media-type attribute of the manifest entry at which it occurs." means that if a media type of an entry is for instance ODF, then the attribute specified the ODF version of the entry.

Re 4.3: <xmldsig:Signature>
The different base URI is used because signatures are a package feature. This means digital signature files are not considered to be part of the document that is stored in a package, but of the package structure itself. All files that belong the the package structure are stored in the META-INF directory. However, the paths used in these files are relative to the package root.
An application does not need to indicate that it uses extensions of XML DSig, because such extensions are already indicated by the existence of the XML elements and attributes that constitute the extension.

Re  5: Metadata Manifest Files
Suggestion: *The* Metadata manifest files for *a* sub *document* shall be stored in the sub document's *directory*.
This should make clear that we are talking about the directory where the sub document is stored rather than of any sub directory.

Re 6: Datatypes
The location of a chapter is an editor's choice. The typos were corrected in OpenDocument-v1.2-part3-cd01-rev03.

Re 7.2.1: Conforming OpenDocument Packages
The term "following" may be added.
Re META-INF and manifest files: An application can of course throw these entries away, but that is something different than stating that these are not allowed.
The order of conformance clauses is entirely independent of the order of files in zip file.
The encoding of the mimetype stream has been clarified in OpenDocument-v1.2-part3-cd01-rev03

Re Section 7.4:
The wish that editing applications don't throw away anything is understandable, but a complex topic: First, ODF specifies a document format, not office application behavior. That is, it describes the meaning elements and attributes, but it does not describe how implementation create or edit documents. Second, editing a document has a purpose, and whether it is reasonable or not to keep some information depends on the purpose and the kind of application. Third, conformance clauses should be testable. Conformance clauses that involve edit operation are only testable if the edit operation itself is defined. But that is outside the scope of the ODF specification.






      was (Author: michael.brauer):
    Re 3.8.3 forward references to extended package consumer: OASIS rules requite that conformance clauses are at the end of the specification. Forward references therefore cannot be avoided. Making all of them explicit is an option, but appears not to be essential, since the term "conforming" already makes clear the we are talking of a conformance class here.

Re 3.8.4: manifest:full-path
Re: Why not a proper, absolute reference?: This comment is unclear. The attribute cannot be an absolute reference (in URI terminology) because the location of a package is not known. Within the package, the path is already absolute, since it contains all path segments from the package root up to the referenced files.
Re allowing URIs. This is a feature request that may be considered in future versions.

Re 3.8.6: manifest:start-key-generation-name
Re password: See previous comment
Support for encryption is not mandatory. The meaning of the term "support" seams to be clear from the context. The algorithms are linked to the conformance classes because only extended package allow the use of alternative algorithms.

Re 3.8.9: manifest:key-derivation-name
"should" should indeed be replaces with "shall" here.

Re 3.8.10: manifest:media-type
Suggestion: Remove: All files that have XML content should have the media type "text/xml".
Replace 2nd paragraph with: A manifest:media-type attribute should be present for all files and *directories* where a MIME media type exists for the content of the file or *document or sub document contained in a directory*.

Re 3.8.11: manifest:preferred-view-mode
Re "slide-show": Slide Show seems to be an appropriate term, since it includes running presentation effects. The suggested description would leave that open.
Re "read-only". This does not mean a preview, but a read-only (or non editable) document.
Re sound-level: This is a suggestion for a future version of ODF.
Re update of dynamic objects: This is a suggestion for a future version of ODF.
Re default value: Implementations may have complex strategies to choose the initial view mode of a document, and they may also allow the user to control this. For instance, an implementation may open document in a read-only mode if the document is physically read-only. This is a reasonable behavior. Mandating that such document are opened in an editable mode would disallow that behavior.

Re 3.8.12: manifest:salt
There are no length constrains, but it is of course up to the implementation to ensure that stack overflows do not occur.

Re 3.8.14: manifest:version
"The specified version refers to the format specified in the
media-type attribute of the manifest entry at which it occurs." means that if a media type of an entry is for instance ODF, then the attribute specified the ODF version of the entry.

Re 4.3: <xmldsig:Signature>
The different base URI is used because signatures are a package feature. This means digital signature files are not considered to be part of the document that is stored in a package, but of the package structure itself. All files that belong the the package structure are stored in the META-INF directory. However, the paths used in these files are relative to the package root.
An application does not need to indicate that it uses extensions of XML DSig, because such extensions are already indicated by the existence of the XML elements and attributes that constitute the extension.

Re  5: Metadata Manifest Files






  
> Public Comment: Comments on ODF 1.2 CD Part 3: Packages
> -------------------------------------------------------
>
>                 Key: OFFICE-2306
>                 URL: http://tools.oasis-open.org/issues/browse/OFFICE-2306
>             Project: OASIS Open Document Format for Office Applications (OpenDocument) TC
>          Issue Type: Bug
>          Components: Packaging
>    Affects Versions: ODF 1.2 Part 3 CD 1
>            Reporter: Robert Weir 
>
> Copied from office-comment list
> Original author: Michiel Leenaars <Michiel.ml@nlnet.nl> 
> Original date: 13 Jan 2010 02:08:03 -0000
> Original URL: http://lists.oasis-open.org/archives/office-comment/201001/msg00006.html

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


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