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,
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