Re: [office] preferred view mode upon opening document

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

"Warren Turkal" ---10/24/2008 07:16:02 AM---If we want to impose IRI across the board, that'd be ok. I was

From:	"Warren Turkal" <turkal@google.com>
To:	robert_weir@us.ibm.com
Cc:	office@lists.oasis-open.org
Date:	10/24/2008 07:16 AM
Subject:	Re: [office] preferred view mode upon opening document

---

> If we want to impose IRI across the board, that'd be ok. I was
> picturing something a little simpler. Maybe any non-official
> preferred-view-modes should just be prefixed with "x-" (like
> unofficial email headers).
The URI solution sounds good. Thanks Rob. Also I do not think it is strange if this method applies throughout the whole ODF although currently only this place has the extension requirement. This method can apply to the similar case in the future.

Warren, your idea seems good, but could you give a detailed solution? I've checked the Relax-NG tutorial, seems not convenient to express this meaning.

> wt

On Thu, Oct 23, 2008 at 2:52 PM,  <robert_weir@us.ibm.com> wrote:
> As currently proposed, option 2 does not allow extensions.  Valid values
> of the manifest:preferred-view-mode attribute are the three listed in the
> proposal, and no more.
>
> If we wanted to allow additional values, and encourage uniqueness, we
> could allow IRI values as well, like "
> http://www.google.com/schemas/odf/view-mode1".
>
> This is similar to package naming conventions in Java, where the use of
> packages like com.ibm.Foo piggybacks on the domain name registry
> uniqueness.
>
> Of course, nothing can force ODF users to do this correctly, so we can
> never enforce global uniqueness.  But we can encourage it.
>
> Doing this change would look like this:
>
>
> <define name="file-entry-attlist" combine="interleave">
> <optional>
> <attribute name="manifest:preferred-view-mode">
>            <choice>
>            <choice>
>            <value>edit</value>
>            <value>presentation-slide-show</value>
>            <value>read-only</value>
>            </choice>
>                           <ref name="anyURI"/>
>                    </choice>
> </attribute>
> </optional>
> </define>
>
> But do we want to go down that path?  This solution, although I've seen it
> used in other standards, is not used in ODF anywhere else, to my
> knowledge, although the issues of extensibility and namespace collisions
> are universal.  I dislike introducing a new design pattern, and have it be
> used in only one place.  "Creeping elegance" is the term that comes to
> mind.
>

> Other ways of handling this might be:
>
> 1) Apply this technique throughout ODF, wherever we currently have a fixed
> enumeration and we wish to allow additional custom choices.
>
> 2) Don't add the IRI support to the schema, but in some introductory
> material, specify that any identifiers used in extensions "should" or
> "shall" be based on IRI's in order to encourage global uniqueness.
>
> Regards,
>
> -Rob
>
>
> "Warren Turkal" <turkal@google.com> wrote on 10/23/2008 12:07:02 PM:
>
>>
>> We should have a policy for naming custom views so that applications
>> can innovate in that space. I don't think that the proposal should be
>> approved until we have defined a method for someone to make a custom
>> view without spraying all over a global namespace.
>>
>> wt
>>
>> 2008/10/22 Ming Fei Jia <jiamingf@cn.ibm.com>:
>> > Dear TC members,
>> >
>> > This is a proposal submitted many days ago. Here is the proposal link
>> > (http://wiki.oasis-open.org/office/proposal%3Aauto-
>> play_presentation_file_format).
>> >
>> > After several rounds of TC discussion, this time I updated in 2 minor
>> > places: (1)change the proposal name from "auto-play presentation file
>> > format" to "preferred view mode upon opening document" since the
> latter is
>> > more suitable for the proposal meaning as all TC members preferred the
>> > extended option;(2) rename one of preferred view modes from
> "slide-show" to
>> > "presentation-slide-show" according to Warren's suggestion.
>> >
>> > If no substantial comments for this proposal, I would like to vote on
> the
>> > next TC call. Thanks.
>
>
> ---------------------------------------------------------------------
> 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