OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [office] auto-play presentation file format like PPS


2008/4/20 Ming Fei Jia <jiamingf@cn.ibm.com>:
>  Change "play" to "auto-play" since I think that "auto-play" is more
>  indicative of what's going on.
>  <jmf>
>  Originally I also used "auto-play", later I was aware that "auto" means
> something is triggered by some events, and in the scenario of opening
> presentation document, this event might just be "double-click" or
> "select/enter". But since we all agreed to remove the description of
> "shortcut launch the application from OS" because it is implementation
> specific, "auto" is not necessary to keep again, and what we emphasize is
> the preferred "view" mode. From this aspect, "auto-play" has the meaning of
> "event"+"mode", and "play" is a pure mode. On the other hand, from general
> understanding, "play" expresses what we want(preferred view mode) and will
> not bring confusion either. So I would like to keep "play" instead of
> "auto-play".

The word "auto" part of "auto-play" has nothing to do with double
clicking or selecting a file via a shortcut (in Windows or any other
OS). It has to do with the fact that the author wishes that the
document start playing automatically (rather than manually) upon open.
"Play" just doesn't indicate that by itself. Really, it doesn't need
to be so generic. Since this mode is only designed for presentations,
it might be better to call it something like "presentation-auto-play".

>  BTW, I have to clarify what the actual meaning of removing the description
> about "shortcut launch the applicaiton from OS". Actually, it means the
> author of the document prefer some view mode whatever user open the document
> from OS shell directly by double-click the document or open the document by
> application explict entry (e.g. file->open). MS Powerpoint differs the above
> 2 scenarios, but MS Excel only has one universal scenario. I also think
> keeping one scenario is more reasonable although it is a little from my
> initial idea.
>  </jmf>

I hope that the shortcut information was removed because it is
irrelevant to interpreting the author's preference.

>  Rather than saying, "The default is 'edit'", I would say that the
>  default should be application specific. The "edit" default makes a lot
>  of sense for OO.o or Koffice, but logically speaking an ODF ebook
>  reader like app would default to read-only. I think that it's clearly
>  app specific. Having said that, there's no reason that we cannot
>  recommend certain defaults for certain types of apps.
>  <jmf>
>  I understand the purpose of default value is that when there is no explict
> definition for an attribute in the document, what value the application
> would adopt. Since mose of ODF based products, e.g. OO.o, KOffice, Symphony
> have no definition for the "preferred-view-mode" till now, and apparently
> they open the existed documents by "edit" mode currently, so in order to
> make sure backward compatibility with those old ODF documents which have no
> "preferred-view-mode", we have to set the default value as "edit" mode.
> "recommend certain defaults for certain types of apps" may be a good idea,we
> can discuss it in another proposal if possible.
>  </jmf>

This is not entirely true. What did Okular (a viewer for ODF, PDF, and
other document formats) default to? I would say that it defaults to
"view" mode. This scenario seems to indicate that there is no
reasonable default for this preference. Therefore, I think it makes
most sense to allow the case of preferred-view-mode not existing to be
implementation defined, not defaulting to "edit".

>  You only have 3 modes defined. It should be those 3 modes or anything
>  else. We should provide prose descriptions of those 3 modes that we
>  define while allowing anyone else to come up with modes that might be
>  useful to them. In future versions of the standard, we should look to
>  see if we need to add other modes.
>
>  Speaking of "Internet media type", we need to decide whether we are
>  going to use that terminology in the rest of the document. The
>  "Internet media type" is the modernized name for a MIME type.
>  <jmf>
>  To consider the document consistence, I changed "Internet media type" to
> "MIME type" again. If you are right that "Internet media type" is more
> appropriate name than "MIME type", we can give another proposal to replace
> all the occurrances of "MIME type" with "Internet media type". Here we have
> to keep "MIME type" to be wording consistent.
>  BTW, I found the URL "
> http://www.isi.edu/in-notes/iana/assignments/media-types/media-types"; in the
> ODF 1.1 may have extraneous "/media-types" since I can open that link only
> remove the second "media-types".
>  </jmf>

I agree with changing to "MIME type" for consistency.

>  In light of the previous comments, please make the following schema
> changes:
>  * take out the defaultvalue for the preferred-view-mode attribute
>  * add the ability to put arbitrary text in addition to the modes that
>  we define in the standard
>  <jmf>
>  I agree with you to give a means to put a placeholder there in order to
> extend the view mode in the future. But it seems Relax-NG has no such
> expressions. Also I think if there is some preferred view mode in the
> further, we can just add it to the choice values and give the corresponding
> description. That'll be OK.
>  </jmf>

I think we need to figure this out because we really should have a
schema that someone could use to validate an ODF document. If the
schema doesn't represent an actual document spec, then what is the
point?

wt


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]