Re: [office] preferred view mode upon opening document

[Ming Fei Jia <jiamingf@cn.ibm.com>]

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