OASIS Open Document Format for Office Applications (OpenDocument) TC

 View Only
Expand all | Collapse all

Re: [office] preferred view mode upon opening document

  • 1.  Re: [office] preferred view mode upon opening document

    Posted 10-24-2008 10:17
    Hi Mingfei,
    
    
    On 10/24/08 11:24 AM, Ming Fei Jia wrote:
    > Sure, namespaceToken can satisfy the name extension requirement, the 
    > name will be like "xxxx:yyyy". This gets me out of the case that I'm 
    > defining new data type:) Thanks Michael. Also I agree with Michael's 
    > suggestion that separate custom view modes from the pre-defined values.
    > 
    > BTW, I think Rob's URI solution is also a good solution, in which it is 
    > not necessary to separate custom view modes from pre-defined values,and 
    > only needs one attribute "manifest:preferred-view-mode". Moreover, that 
    > method can be used to solve those general enumeration extension issues.
    
    The reason I have suggested an additional attribute was only that this 
    would permit that documents contain a standardized view mode in addition 
    to a user defined one. This means that one could use
    
    manifest:extended-preferred-view-mode"http://www.openoffice.org/my-special-read-only-view-mode", 
    
    
    or
    
    manifest:extended-preferred-view-mode="ooo:my-special-read-only-view-mode" 
    with an additional xmlns:ooo="http://www.openoffice.org",
    
    as user defined view mode. And at the same time one could also provide a
    
    manifest:preferred-view-mode="read-only"
    
    as a fall-back for those applications that don't know what 
    ooo:my-special-read-only-view-mode" is. Without an additional attribute 
    an application could only fall-back to the default "edit" mode.
    
    So, this is something that may be also combined with the URI and the 
    namespace token proposal, but that could also be omitted in both cases. 
    Whether this additional attribute is reasonable or not is something that 
    you and Warren probably know better than me. So this was just a suggestion.
    
    If we don't want to have this additional attribute, one could also use a 
    namespaced token rather than an URI in the schema that Rob has 
    suggested. Which means, we could also list the pre-defined values, and 
    additionally allow a namespace token.
    
    I'm personally a little bit in favor of using namespaced tokens rather 
    URIs, simply because this is what we use in ODF already. And they are 
    actually a subset of a new specification  called CURIE that the W3C is 
    developing to address the issue of, as they call it, extensible value 
    collections.
    
    Best regards
    
    Michael
    > 
    > I really feel the community's capabilities:)
    > 
    > Mingfei
    > Inactive hide details for Michael Brauer - Sun Germany - ham02 - Hamburg 
    > ---10/24/2008 02:50:44 PM---The way we resolved this sMichael Brauer - 
    > Sun Germany - ham02 - Hamburg ---10/24/2008 02:50:44 PM---The way we 
    > resolved this situation elsewhere in ODF are namespaced
    > 
    > 
    > From:	
    > Michael Brauer - Sun Germany - ham02 - Hamburg 


  • 2.  Re: [office] preferred view mode upon opening document

    Posted 10-24-2008 13:38
    Michael.Brauer@Sun.COM wrote on 10/24/2008 06:21:26 AM:
    
    
    > 
    > I'm personally a little bit in favor of using namespaced tokens rather 
    > URIs, simply because this is what we use in ODF already. And they are 
    > actually a subset of a new specification  called CURIE that the W3C is 
    > developing to address the issue of, as they call it, extensible value 
    > collections.
    > 
    
    That is fine with me as well.  Since the namespace prefix is associated 
    with a URI, we still are encouraging global uniqueness of the identifiers.
    
    -Rob
    


  • 3.  Re: [office] preferred view mode upon opening document

    Posted 10-24-2008 16:46
    I think the namespaced token solution sounds good.
    
    On the issue of having a separate attrs to specify a standard and a
    custom view. I am not sure that's neccessary. I think that we should
    just leave it up to the user agent. Maybe we could suggest the user
    agent default to read-only or edit depending on whether the file is
    read-only or editable at the FS level?
    
    wt
    
    On Fri, Oct 24, 2008 at 6:43 AM,  


  • 4.  Re: [office] preferred view mode upon opening document

    Posted 10-26-2008 15:42

    I think without separating an extended-preferred-view-mode attribute works as well, because, according to the string pattern, namespacedToken value can be identified from the pre-defined values. So Michael's concerns can be resolved.

    Now the revised proposal should be like as below:

    Preferred View Mode
    The manifest:preferred-view-mode attribute is meant to provide a preference on how the author of the document would like the document to be presented upon the document is opened. This attribute is only applicable to the root file entry with the full path “/”.There are 3 view modes pre-defined: “edit”, “presentation-slide-show” and “read-only”. Beyond that, a namespaced value is defined to enable the specific application to customize its preferred view mode. View modes are not necessarily generally applicable to all MIME types. No default value is defined, and the way in which an application responds when no “preferred-view-mode” attribute is specified is undefined.
    <define name="file-entry-attlist" combine="interleave">
    <optional>
    <attribute name="manifest:preferred-view-mode">
    <choice>
    <value>edit</value>
    <value>presentation-slide-show</value>
    <value>read-only</value>
    <ref name=”namespacedToken”>
    </choice>
    </attribute>
    </optional>
    </define>

    I updated the wiki about this proposal at this link:
    http://wiki.oasis-open.org/office/proposal%3Aauto-play_presentation_file_format?highlight=(CategoryNewProposal\b)|(CategoryCategory\b)|(ProposalTemplate\b)

    Also I updated the odt proposal document at this link:
    http://www.oasis-open.org/apps/org/workgroup/office/download.php/29788/08-06-08-proposal00070

    I would like to ballot on the next TC call if no fundermental changes occur.

    Best Regards,

    Mingfei Jia(贾明飞)
    IBM Lotus Symphony Development
    IBM China Software Development LAB, Beijing
    Tel: 86-10-82452493 Fax: 86-10-82452887
    NOTES:Ming Fei Jia/China/IBM E-mail: jiamingf@cn.ibm.com
    Address: No.28 Building, Zhong Guan Cun Software Park, No.8 Dong Bei Wang West Road, ShangDi, Haidian District, Beijing 100193, P.R.China

    "Warren Turkal" <turkal@google.com> wrote on 10/25/2008 12:48:54 AM:

    > From:

    >
    > "Warren Turkal" <turkal@google.com>

    >
    > To:

    >
    > robert_weir@us.ibm.com

    >
    > Cc:

    >
    > office@lists.oasis-open.org

    >
    > Date:

    >
    > 10/25/2008 12:52 AM

    >
    > Subject:

    >
    > Re: [office] preferred view mode upon opening document

    >
    > I think the namespaced token solution sounds good.
    >
    > On the issue of having a separate attrs to specify a standard and a
    > custom view. I am not sure that's neccessary. I think that we should
    > just leave it up to the user agent. Maybe we could suggest the user
    > agent default to read-only or edit depending on whether the file is
    > read-only or editable at the FS level?
    >
    > wt
    >
    > On Fri, Oct 24, 2008 at 6:43 AM,  <robert_weir@us.ibm.com> wrote:
    > > Michael.Brauer@Sun.COM wrote on 10/24/2008 06:21:26 AM:
    > >
    > >
    > >>
    > >> I'm personally a little bit in favor of using namespaced tokens rather
    > >> URIs, simply because this is what we use in ODF already. And they are
    > >> actually a subset of a new specification  called CURIE that the W3C is
    > >> developing to address the issue of, as they call it, extensible value
    > >> collections.
    > >>
    > >
    > > That is fine with me as well.  Since the namespace prefix is associated
    > > with a URI, we still are encouraging global uniqueness of the identifiers.
    > >
    > > -Rob
    > >
    > > ---------------------------------------------------------------------
    > > To unsubscribe from this mail list, you must leave the OASIS TC that
    > > generates this mail.  Follow this link to all your TCs in OASIS at:
    > > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
    > >
    > >
    >
    > ---------------------------------------------------------------------
    > To unsubscribe from this mail list, you must leave the OASIS TC that
    > generates this mail.  Follow this link to all your TCs in OASIS at:
    > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
    >



  • 5.  RE: [office] preferred view mode upon opening document

    Posted 10-27-2008 16:00
    In the ODF TC Call, there was a request for clarification of the 


  • 6.  RE: [office] preferred view mode upon opening document

    Posted 10-28-2008 06:38

    Hi Dennis,


    "Dennis E. Hamilton" <dennis.hamilton@acm.org> wrote on 10/28/2008 12:03:34 AM:

    > From:

    >
    > "Dennis E. Hamilton" <dennis.hamilton@acm.org>

    >
    > To:

    >
    > <office@lists.oasis-open.org>

    >
    > Cc:

    >
    > Ming Fei Jia/China/IBM@IBMCN

    >
    > Date:

    >
    > 10/27/2008 09:04 PM

    >
    > Subject:

    >
    > RE: [office] preferred view mode upon opening document

    >
    > In the ODF TC Call, there was a request for clarification of the <choice>
    > rule for manifest:preferred-view-mode and the passage beginning "Beyond
    > that, ... ."
    >
    > Here is my recommendation for changes to the text to clarify what is
    > intended:
    >
    > In the current proposal,
    > http://wiki.oasis-open.org/office/proposal%3Aauto-play_presentation_file_for
    > mat
    >
    > Under "(1) simple option", change
    > "Add an attribute <presentation:auto-slide-show> ..."
    > to
    > "Add an attribute presentation:auto-slide-show ..."


    option 1 will not be considered again since most of members prefer the extended option. Anyway, thanks.

    >
    > Under "(2) extended option"
    > in the added paragraph on "Preferred View Mode" replace the sentence
    > "Beyond that, a namespaced value is defined to enable the specific
    > application to customize its preferred view mode."
    > with
    > "Alternatively, a namespaced value may be used to specify a custom value for
    > the preferred view mode."


    I think this wording is better than the original one, thanks.

    >
    > I also suggest that the the sentence
    > "No default value is defined, and the way ... undefined."
    > be replaced by the two sentences
    > "There is no default value.  The behavior of application software is not
    > specified for cases where manifest:preferred-view-mode is absent or the
    > value is one not provided for."
    >
    > This last change is intended to cover situations where a custom value is not
    > known to the implementation as well as when a well-known value is
    > inappropriate or simply not supported.  

    Agree, this will be more extensible:)

    >I avoided use of "undefined" because
    > this can be taken to mean that some sort of failure or rejection of the
    > document is also an option.

    Agree, I am not English native speaker, not aware this sensitive meaning.

    >
    > It seems valuable that the down-level behavior of ignoring the attribute is
    > also consistent with the defined behavior for 1.2.
    >
    >  - Dennis
    >
    > PS: I did not suggest any particular way that agreement on custom values
    > might occur.  It seems simplest to leave that unstated and be something that
    > happens by unspecified means.  Everything I thought to say was either very
    > clumsy or too limited.  

    Currently what we can make certain is the 3 pre-defined values. For those uncertain values, some members prefer to define a pattern to specify the custom values. This may be mainly for those non traditional office software. I also agree with this because extensibility is not a bad thing for me.
    >
    > PPS: There is a question on whether the attribute should be preserved where
    > it is not recognized or is not being honored.  It is not a foreign
    > attributed but it can have a foreign value.  It is technically not a foreign
    > attribute down-level because it is in a standard namespace, although
    > implementations are known that drop attributes that are unsupported,
    > whatever the namespace.   This is a meta-topic that we might want to discuss
    > separately.

    It is surely the case that native attribute may have a foreign value. This is an example that extensibility requires such solution. Maybe this topic will become a general topic in the whole ODF spec. Anyway, discuss it separately.
    >
    >



  • 7.  Re: [office] preferred view mode upon opening document

    Posted 10-24-2008 16:47

    Michael,

    Thanks the detailed explanatilon. Understand, the namespaceToken solution works for me.

    Best Regards,

    Mingfei Jia(贾明飞)
    IBM Lotus Symphony Development
    IBM China Software Development LAB, Beijing
    Tel: 86-10-82452493 Fax: 86-10-82452887
    NOTES:Ming Fei Jia/China/IBM E-mail: jiamingf@cn.ibm.com
    Address: No.28 Building, Zhong Guan Cun Software Park, No.8 Dong Bei Wang West Road, ShangDi, Haidian District, Beijing 100193, P.R.China

    Michael Brauer - Sun Germany - ham02 - Hamburg ---10/24/2008 06:24:23 PM---Hi Mingfei,


    From:

    Michael Brauer - Sun Germany - ham02 - Hamburg <Michael.Brauer@Sun.COM>

    To:

    Ming Fei Jia/China/IBM@IBMCN

    Cc:

    office@lists.oasis-open.org

    Date:

    10/24/2008 06:24 PM

    Subject:

    Re: [office] preferred view mode upon opening document




    Hi Mingfei,


    On 10/24/08 11:24 AM, Ming Fei Jia wrote:
    > Sure, namespaceToken can satisfy the name extension requirement, the
    > name will be like "xxxx:yyyy". This gets me out of the case that I'm
    > defining new data type:) Thanks Michael. Also I agree with Michael's
    > suggestion that separate custom view modes from the pre-defined values.
    >
    > BTW, I think Rob's URI solution is also a good solution, in which it is
    > not necessary to separate custom view modes from pre-defined values,and
    > only needs one attribute "manifest:preferred-view-mode". Moreover, that
    > method can be used to solve those general enumeration extension issues.

    The reason I have suggested an additional attribute was only that this
    would permit that documents contain a standardized view mode in addition
    to a user defined one. This means that one could use

    manifest:extended-preferred-view-mode"
    http://www.openoffice.org/my-special-read-only-view-mode",


    or

    manifest:extended-preferred-view-mode="ooo:my-special-read-only-view-mode"
    with an additional xmlns:ooo="
    http://www.openoffice.org",

    as user defined view mode. And at the same time one could also provide a

    manifest:preferred-view-mode="read-only"

    as a fall-back for those applications that don't know what
    ooo:my-special-read-only-view-mode" is. Without an additional attribute
    an application could only fall-back to the default "edit" mode.

    So, this is something that may be also combined with the URI and the
    namespace token proposal, but that could also be omitted in both cases.
    Whether this additional attribute is reasonable or not is something that
    you and Warren probably know better than me. So this was just a suggestion.

    If we don't want to have this additional attribute, one could also use a
    namespaced token rather than an URI in the schema that Rob has
    suggested. Which means, we could also list the pre-defined values, and
    additionally allow a namespace token.

    I'm personally a little bit in favor of using namespaced tokens rather
    URIs, simply because this is what we use in ODF already. And they are
    actually a subset of a new specification  called CURIE that the W3C is
    developing to address the issue of, as they call it, extensible value
    collections.

    Best regards

    Michael
    >
    > I really feel the community's capabilities:)
    >
    > Mingfei
    > Inactive hide details for Michael Brauer - Sun Germany - ham02 - Hamburg
    > ---10/24/2008 02:50:44 PM---The way we resolved this sMichael Brauer -
    > Sun Germany - ham02 - Hamburg ---10/24/2008 02:50:44 PM---The way we
    > resolved this situation elsewhere in ODF are namespaced
    >
    >
    > From:
    > Michael Brauer - Sun Germany - ham02 - Hamburg <Michael.Brauer@Sun.COM>
    >
    > To:
    > robert_weir@us.ibm.com
    >
    > Cc:
    > office@lists.oasis-open.org
    >
    > Date:
    > 10/24/2008 02:50 PM
    >
    > Subject:
    > Re: [office] preferred view mode upon opening document
    >
    > ------------------------------------------------------------------------
    >
    >
    >
    > The way we resolved this situation elsewhere in ODF are namespaced
    > tokens, that is, a namespace prefix, followed by an identifier.
    >
    > If we use that for the manifest:preferred-view-mode attribute, then the
    > schema would look like this:
    >
    > <define name="file-entry-attlist" combine="interleave">
    >   <optional>
    >     <attribute name="manifest:preferred-view-mode">
    >       <ref name="namespacedToken"/>
    >     </attribute>
    >   </optional>
    > </define>
    >
    > We would pre-define the values
    >
    > manifest:edit
    > manifest:presentation-slide-show
    > manifest:read-only
    >
    >
    > One question is whether we want to provide fallback values for user
    > defined values, so that application that don't understand the user
    > defined view mode can at least choose one of the pre-defined modes that
    > is close to the use defined mode. If we want to have this, then we may
    > define two attributes. One that is exactly what we have in the original
    > proposal, and an additional one, let's say
    > "manifest:extended-preferred-view-mode" that takes a namespaced value.
    > Depending on whether we want the fallback value to be optional or
    > mandatory, the schema may look like this:
    >
    > <define name="file-entry-attlist" combine="interleave">
    >   <optional>
    >     <attribute name="manifest:preferred-view-mode">
    >             <choice>
    >             <value>edit</value>
    >             <value>presentation-slide-show</value>
    >             <value>read-only</value>
    >             </choice>
    >     </attribute>
    >   </optional>
    >   <optional>
    >     <attribute name="manifest:extended-preferred-view-mode">
    >       <ref name="namespacedToken"/>
    >     </attribute>
    >   </optional>
    > </define>
    >
    > or like this
    >
    > <define name="file-entry-attlist" combine="interleave">
    >   <optional>
    >     <attribute name="manifest:preferred-view-mode">
    >             <choice>
    >             <value>edit</value>
    >             <value>presentation-slide-show</value>
    >             <value>read-only</value>
    >             </choice>
    >     </attribute>
    >     <optional>
    >       <attribute name="manifest:extended-preferred-view-mode">
    >         <ref name="namespacedToken"/>
    >       </attribute>
    >     </optional>
    >   </optional>
    > </define>
    >
    > 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: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer
    > Vorsitzender des Aufsichtsrates: Martin Haering
    >
    >
    > ---------------------------------------------------------------------
    > To unsubscribe from this mail list, you must leave the OASIS TC that
    > generates this mail.  Follow this link to all your TCs in OASIS at:
    >
    https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
    >
    >


    --
    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: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer
    Vorsitzender des Aufsichtsrates: Martin Haering

    ---------------------------------------------------------------------
    To unsubscribe from this mail list, you must leave the OASIS TC that
    generates this mail.  Follow this link to all your TCs in OASIS at:
    https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 




  • 8.  Re: [office] preferred view mode upon opening document

    Posted 10-27-2008 15:04
    
    
      
    
    
    Ming Fei,

    Two questions about the proposal:

    1. Isn't a good idea to explicitly define an default view mode (e.g. Edit) to all applications that doesn't support a custom view mode ?

    2. What about a sentence on the specification like: "It is recommended that all custom view mode specification documentation is made available to enhance documents interoperability" ?

    I think that too much application-defined things may gives to the users wrong impressions about interoperability.

    Best,

    Jomar

    Ming Fei Jia escreveu:
    OFB03540DB.91BB4946-ON482574EC.005C6E76-482574EC.005C0149@cn.ibm.com" type="cite">

    Michael,

    Thanks the detailed explanatilon. Understand, the namespaceToken solution works for me.

    Best Regards,

    Mingfei Jia(贾明飞)
    IBM Lotus Symphony Development
    IBM China Software Development LAB, Beijing
    Tel: 86-10-82452493 Fax: 86-10-82452887
    NOTES:Ming Fei Jia/China/IBM E-mail: jiamingf@cn.ibm.com
    Address: No.28 Building, Zhong Guan Cun Software Park, No.8 Dong Bei Wang West Road, ShangDi, Haidian District, Beijing 100193, P.R.China

    Michael Brauer - Sun Germany - ham02 - Hamburg ---10/24/2008 06:24:23 PM---Hi Mingfei,


    From:

    Michael Brauer - Sun Germany - ham02 - Hamburg <Michael.Brauer@Sun.COM>

    To:

    Ming Fei Jia/China/IBM@IBMCN

    Cc:

    office@lists.oasis-open.org

    Date:

    10/24/2008 06:24 PM

    Subject:

    Re: [office] preferred view mode upon opening document





    Hi Mingfei,


    On 10/24/08 11:24 AM, Ming Fei Jia wrote:
    > Sure, namespaceToken can satisfy the name extension requirement, the
    > name will be like "xxxx:yyyy". This gets me out of the case that I'm
    > defining new data type:) Thanks Michael. Also I agree with Michael's
    > suggestion that separate custom view modes from the pre-defined values.
    >
    > BTW, I think Rob's URI solution is also a good solution, in which it is
    > not necessary to separate custom view modes from pre-defined values,and
    > only needs one attribute "manifest:preferred-view-mode". Moreover, that
    > method can be used to solve those general enumeration extension issues.

    The reason I have suggested an additional attribute was only that this
    would permit that documents contain a standardized view mode in addition
    to a user defined one. This means that one could use

    manifest:extended-preferred-view-mode"
    http://www.openoffice.org/my-special-read-only-view-mode",


    or

    manifest:extended-preferred-view-mode="ooo:my-special-read-only-view-mode"
    with an additional xmlns:ooo="
    http://www.openoffice.org",

    as user defined view mode. And at the same time one could also provide a

    manifest:preferred-view-mode="read-only"

    as a fall-back for those applications that don't know what
    ooo:my-special-read-only-view-mode" is. Without an additional attribute
    an application could only fall-back to the default "edit" mode.

    So, this is something that may be also combined with the URI and the
    namespace token proposal, but that could also be omitted in both cases.
    Whether this additional attribute is reasonable or not is something that
    you and Warren probably know better than me. So this was just a suggestion.

    If we don't want to have this additional attribute, one could also use a
    namespaced token rather than an URI in the schema that Rob has
    suggested. Which means, we could also list the pre-defined values, and
    additionally allow a namespace token.

    I'm personally a little bit in favor of using namespaced tokens rather
    URIs, simply because this is what we use in ODF already. And they are
    actually a subset of a new specification  called CURIE that the W3C is
    developing to address the issue of, as they call it, extensible value
    collections.

    Best regards

    Michael
    >
    > I really feel the community's capabilities:)
    >
    > Mingfei
    > Inactive hide details for Michael Brauer - Sun Germany - ham02 - Hamburg
    > ---10/24/2008 02:50:44 PM---The way we resolved this sMichael Brauer -
    > Sun Germany - ham02 - Hamburg ---10/24/2008 02:50:44 PM---The way we
    > resolved this situation elsewhere in ODF are namespaced
    >
    >
    > From:
    > Michael Brauer - Sun Germany - ham02 - Hamburg <Michael.Brauer@Sun.COM>
    >
    > To:
    > robert_weir@us.ibm.com
    >
    > Cc:
    > office@lists.oasis-open.org
    >
    > Date:
    > 10/24/2008 02:50 PM
    >
    > Subject:
    > Re: [office] preferred view mode upon opening document
    >
    > ------------------------------------------------------------------------
    >
    >
    >
    > The way we resolved this situation elsewhere in ODF are namespaced
    > tokens, that is, a namespace prefix, followed by an identifier.
    >
    > If we use that for the manifest:preferred-view-mode attribute, then the
    > schema would look like this:
    >
    > <define name="file-entry-attlist" combine="interleave">
    >   <optional>
    >     <attribute name="manifest:preferred-view-mode">
    >       <ref name="namespacedToken"/>
    >     </attribute>
    >   </optional>
    > </define>
    >
    > We would pre-define the values
    >
    > manifest:edit
    > manifest:presentation-slide-show
    > manifest:read-only
    >
    >
    > One question is whether we want to provide fallback values for user
    > defined values, so that application that don't understand the user
    > defined view mode can at least choose one of the pre-defined modes that
    > is close to the use defined mode. If we want to have this, then we may
    > define two attributes. One that is exactly what we have in the original
    > proposal, and an additional one, let's say
    > "manifest:extended-preferred-view-mode" that takes a namespaced value.
    > Depending on whether we want the fallback value to be optional or
    > mandatory, the schema may look like this:
    >
    > <define name="file-entry-attlist" combine="interleave">
    >   <optional>
    >     <attribute name="manifest:preferred-view-mode">
    >             <choice>
    >             <value>edit</value>
    >             <value>presentation-slide-show</value>
    >             <value>read-only</value>
    >             </choice>
    >     </attribute>
    >   </optional>
    >   <optional>
    >     <attribute name="manifest:extended-preferred-view-mode">
    >       <ref name="namespacedToken"/>
    >     </attribute>
    >   </optional>
    > </define>
    >
    > or like this
    >
    > <define name="file-entry-attlist" combine="interleave">
    >   <optional>
    >     <attribute name="manifest:preferred-view-mode">
    >             <choice>
    >             <value>edit</value>
    >             <value>presentation-slide-show</value>
    >             <value>read-only</value>
    >             </choice>
    >     </attribute>
    >     <optional>
    >       <attribute name="manifest:extended-preferred-view-mode">
    >         <ref name="namespacedToken"/>
    >       </attribute>
    >     </optional>
    >   </optional>
    > </define>
    >
    > 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: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer
    > Vorsitzender des Aufsichtsrates: Martin Haering
    >
    >
    > ---------------------------------------------------------------------
    > To unsubscribe from this mail list, you must leave the OASIS TC that
    > generates this mail.  Follow this link to all your TCs in OASIS at:
    >
    https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
    >
    >


    --
    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: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer
    Vorsitzender des Aufsichtsrates: Martin Haering

    ---------------------------------------------------------------------
    To unsubscribe from this mail list, you must leave the OASIS TC that
    generates this mail.  Follow this link to all your TCs in OASIS at:
    https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 





  • 9.  Re: [office] preferred view mode upon opening document

    Posted 10-28-2008 05:23

    Hi Jomar,


    Jomar Silva <jomar.silva@br.odfalliance.org> wrote on 10/27/2008 09:14:03 PM:

    > From:

    >
    > Jomar Silva <jomar.silva@br.odfalliance.org>

    >
    > To:

    >
    > Ming Fei Jia/China/IBM@IBMCN

    >
    > Cc:

    >
    > office@lists.oasis-open.org

    >
    > Date:

    >
    > 10/27/2008 08:10 PM

    >
    > Subject:

    >
    > Re: [office] preferred view mode upon opening document

    >
    > Ming Fei,
    >
    > Two questions about the proposal:
    >
    > 1. Isn't a good idea to explicitly define an default view mode (e.g.
    > Edit) to all applications that doesn't support a custom view mode ?
    >


    Good question. In the very original proposal, I have defined an default view mode "edit". Later, Warren suggested that do not define a default value because the ODF applications are not limited to trational office software, some other ODF applications such as e-book may have their specific view mode by default. Since this attribute is optional, most of applications may have no explict value specified, as well as different applications may have different default value. So I agree with Warren's suggestion, not define a default value. This is a compromised result. Warren, pls correct me if I'm wrong.

    > 2. What about a sentence on the specification like: "It is
    > recommended that all custom view mode specification documentation is
    > made available to enhance documents interoperability" ?
    >
    > I think that too much application-defined things may gives to the
    > users wrong impressions about interoperability.

    In this proposal, it is difficult to avoid application-defined things since what we are defining preferred view mode is just to be defining the application behavior. I think here whether the custom view mode specification documentation is made available or not does not affect the document interoperability. Actually, as long as the preferred view mode value is specified explictly in the file, every application will display the content with the same mode upon opening the file. Only when no explict value is specificed, there exists the document interoperability issue, that is, different applications diplay the content with different view modes. But as I mentioned above ,this is a compromised result.If no this proposal, this issue still exists. Maybe I do not understand your meaning of document interoperability in this case completely. If any, correct me.

    >
    > Best,
    >
    > Jomar
    >



  • 10.  Re: [office] preferred view mode upon opening document

    Posted 10-28-2008 07:50
    On Mon, Oct 27, 2008 at 19:19, Ming Fei Jia 


  • 11.  Re: [office] preferred view mode upon opening document

    Posted 10-29-2008 21:11
     > 2. What about a sentence on the specification like: "It is 
    > recommended that all custom view mode specification documentation is
    > made available to enhance documents interoperability" ?
    > 
    
    The issue Warren raises is a general issue, not exclusive to view mode 
    alone.  One way to address this globally is two add two things to the ODF 
    text:
    
    1) Where ever something like this occurs, explicitly call the behavior 
    "implementation-defined".  Use that as a uniform label of areas where ODF 
    allows implementations to implement their own behaviors.  So we say 
    something like "Additional view modes may be used, but they shall be 
    prefixed by a namespace qualifier not defined by this standard.  The 
    behavior of such view modes is implementation-defined".
    
    2) Then in the conformance clause, we add language like:  "An 
    implementation shall be accompanied by a document that defines all 
    implementation-defined and locale-specific characteristics and all 
    extensions."  (That is the language directly out of ISO/IEC 9899:1999 C 
    Programming Language.  You can see here what one implementation created to 
    define its "implementation-defined" features:  
    http://gcc.gnu.org/onlinedocs/gcc/C-Implementation.html
    
    We don't need that exact language, but you get the idea.  A standard can 
    allow implementation-defined behavior, but can also require that these be 
    documented.  If we're going to do this, I'd rather we do it pervasively in 
    the standard rather than just in the view mode attribute.
    
    What do TC members think? 
    
    Regards,
    
    -Rob
    


  • 12.  Re: [office] preferred view mode upon opening document

    Posted 10-29-2008 22:56
    Amen.
    
    On Wed, Oct 29, 2008 at 14:09,  


  • 13.  RE: [office] preferred view mode upon opening document

    Posted 10-31-2008 02:24
    I also support this idea.  
    
    In the proposal at hand, there are two places where implementation-defined
    is appropriate.  One has to do with saying
    
    "Alternatively, a namespaced value may be used for implementation-defined
    preferred views."
    
    The other might be to say 
    
    "The behavior of application software is implementation-defined for cases
    where manifest:preferred-view-mode is absent or the value is one not
    provided for."
    
    I suppose the first case applies to emitters and the second seems to apply
    to accepters.
    
     - Dennis