[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]