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

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

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

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

Warren Turkal

to:

Ming Fei Jia

2008-04-24 03:42

Cc:

office

---

On Wed, Apr 23, 2008 at 5:24 AM, Ming Fei Jia <jiamingf@cn.ibm.com> wrote:
>  On Tue, Apr 22, 2008 at 12:06 AM, Ming Fei Jia <jiamingf@cn.ibm.com> wrote:
>  > Re: [office] auto-play presentation file format like PPS
>  >  <jmf>
>  >  I understand the "auto" you mean is different from mine. My "auto"
>  > emphasizes the launching application by a shortcut way. Your "auto" means
>  > play the slides automatically upon open. But you should know the behavior
> of
>  > MS PPS file, when open the PPS file via a shortcut way, it just enters
>  > "play" status, you need to play the slides by press the enter or some
> other
>  > triggered ways, not "automatically" as you described.
>
>  >What are the differences between this "triggered" play mode and the
>  >readonly mode?
>  Readonly mode is like those ODF viewer,PDF viewer showing,and users can not
> modify contents. Play mode is a kind of screen show, in which user can
> present slides(for meta file,might be each drawing segment) according to
> some triggered event. I think "play" itself already contains the meaning of
> "automatically" you described.

>In my view, the only thing that the play/auto-play/whatever name value
>would indicate is that the presentation would start upon opening the
>document instead of waiting to be run by the user. Maybe
>"presentation-auto-start" would be a better name.
What we want is a view mode, in my understanding a view mode should be a kind of screen show with some characteristics. For instance, "edit" mode is a screen show with allowing the contents modified, "readonly" mode is a screen show with not-allowing the contents modified, and "play" mode is a screen show with presenting contents step by step accoding to some triggered event(whatever the user action or the program controled action). I don't think "the only thing that the play/auto-play/whatever name value would indicate is that the presentation would start upon opening the document instead of waiting to be run by the user", I think what we are talking about is a screen show mode and what characteristic that screen show mode has. So "presentation-auto-start" does not make sense for me. I still prefer "play" unless you can convince me.

>  > What we want is the
>  > "play" status like PPS. As to how the slide is played, "automatically" or
>  > "manually" should not be what we are talking about. We want to define a
>  > preferred view mode.
>
>  >If I am interpreting this statement correctly. You are asking for
>  >details about how a slide is presented during play. For instance, you
>  >want the ability to express something like "goto slide 1, play some
>  >sound, wait 30 sec, goto slide 2, wait 30 sec, etc." Is that correct?
>  >If that is what you are wanting, the preferred view mode shouldn't
>  >have anything to do with that problem.
>  You interpretation is correct. I also think "the preferred view mode" has
> nothing to do with how a slide is presented. See "should not be" in my
> prevous comments. So we should have no disagreement for this point.

>Since my interpretation is correct, I think it is important to note
>that OO.o already implements the timings for slides and effects in the
>presentation. I also just confirmed that the support is in the
>standard. This indicates that this proposal should have nothing to do
>with slide or effect timings.
It's a good thing that OO.o already implements the timings for slides and effects in the presentation. I also don't take care of the details of how the slides are played. But I want to confirm that "play" mode just has those characteristics of presenting slides timingly or with some other effects. For such presenting slide mode, we call it "play". Repeat it again, this is my understanding of "play","play" is a kind of screen show with presenting contents step by step according to some triggerred event (by the user action or the program controled action). I want to know what your understanding of "play" is and why it does not make sense for you.

>  > Right...and a
>  > Also something like "presentation-auto-play" was
>  > already defined as one attribute of presentation in the original
> proposal,
>  > but you know, after discussion, we all agreed to move that out of
>  > presentation layer to more generic layer.

>Actually, I never understood our discussion to say that we should
>introduce the play view functionality to other types of documents. The
>only things I got from the discussion were:
>1) There is a need for "preferred-view-mode"s at the manifest level
>2) Certain types of documents may use  "preferred-view-mode"s that
>don't exist in other types of documents
This is why we say "play" might be only meaningful for presentation application. But that does not mean in the future maybe "play" will be meaningful for other applications. This is why I do not consent to add "presentation" in the mode name, i.e. "presentation-auto-play" does not make sense for me.
>3) A "readonly" mode makes sense for something like an ebook reader.
>4) We could use MIME type args to make the "preferred-view-mode"
>easily accessible.

>Everyone, if I missed something, please let me know.

>  > In this generic layer, it is
> not
>  > reasonable to mark "presentation" tag on the view mode name although we
> know
>  > it might be only meaningful for presentation now.

>The value namespace of "preferred-view-modes" should not be polluted
>with global looking modes when they only apply to one document type.
>There is not reason that we couldn't define a "auto-play" in a future
>revision if we find that it makes sense for more than presentations.
Since you think it is OK to define "auto-play/play" in a future revision if we find that it makes sense for more than presentations, why can not we define it now? Seems we have no disagreement at this point. Just confirm that we agree to define the name as "auto-play" or "play", instead of "presentation-auto-play". Between "auto-play" and "play", I prefer "play" since the reason in my prevous comments.

>  >I don't remember agreeing that the auto-play mode would be defined for
>  >anything but presentations. There has clearly been a breakdown in
>  >communications (possibly only on my side), and I think we might need
>  >to address that before we can productively move on.
>  History is past:) What we are mattering is to get consensus for current
> point. We say "play" might be only meaningful for presentation, not say
> definitely it is. Maybe "play" a meta file,or "play" something other
> documents that are generated by other than presentation applications. "play"
> here is kind of screen show, in which user can present contents step by step
> according to some triggered events. It should not be limited to
> presentation.

>I will not consent to adding slide timings (and other presentation
>specific) info at the manifest level. Again the standard already
>includes the information for slide and effect timings.
I never said to add slide timings and the presentation details at the manifest level. I just explain what my understanding of "play" is.  Need to repeat it again (sorry if this bring you trivial feeling), as my understanding, "play" is a screen show with characteristics of presenting contents step by step according to some triggered event (by whatever user action or program controled action). So I think "play" is just the preferred view mode that we want.

>I will also not consent to adding poorly defined "play" mode.
Not just say which is better or poorly. We need reason. Can you give your understanding of "play"?

>  > Cannot we say "play" a
>  > meta file? What's more, if we think "readonly" might be only for word
>  > processor, can we say the attribute name as "word-processor-readonly"?
>  >  </jmf>
>
>  >I never claimed that readonly was only for the word processor. I think
>  >it is sufficiently generic to apply to all document types. So far only
>  >"readonly" and "edit" are the only preferred-view-modes that are
>  >sufficiently generic to apply to all docs..
>  I did not say you claimed "readonly was only for the word processor", I
> said "if" that, just a metaphor. Anyway, that's not the point. I of course
> agree "readonly" and "edit" are sufficiently generic to apply to all
> docs,

>I didn't realize that your were making a hypothetical. However, if it
>could be said that some mode applied _only_ to word processing docs,
>then it should be identified as such in the mode name. I don't think
>that's unreasonable.
Ok, let's succeed the discussion with the hypothetical of "readonly mode only apply to word processor now". If now we define the name as "wordProcessor-readonly", and in the future when there are some other applications called "XXX1","XXX2",..., which also make sense for "readonly", then at that time we shall have to define the new view modes as "XXX1-readonly","XXX2-readonly",etc. Do you think that will make sense for you? Why do not we just define "readonly" there now? As the same situation, why do not we just define "play" there now?

> here I want to say "play" should also be enough generic although now we
> can see limited user scenarios, e.g play presentation doc.

>I am totally confused by this bit of your message.
Actually the anwser is the same with the above. In another word, I hope "play" applies to presentation now, and in the future, maybe it can apply to more than presentation applications. From this meaning, it should be "generic".

>  >  <jmf>
>  >  As my understanding of "auto", it is relevant to interpreting the
> author's
>  > preference. As your understanding, it is irrelevant.
>
>  >I think its pretty clear that the OS launcher can use the information
>  >to launch the doc in some special way. I don't think we need to
>  >describe that in the standard at all. That's why it's not relevant. We
>  >aren't defining UI.
>  I agree we do not need to describe something like OS launcher in the
> standard. In previous comments, I already accepted your suggestion to remove
> that description in the proposal. I think there is no disagreement for this
> point. My previous comment is just an explanation for different
> understanding of "auto", which maybe bring you some misunderstanding. Sorry
> for that.

>  > But it does not matter,
>  > it is OK since we know what the actual is.
>  >  </jmf>
>
>  >I don't know what you are trying to say here. Please clarify.
>  It is the successive of previous explanation for different understanding of
> "auto", no disagreement here. "what the actual is" just means your "auto" is
> ..., and my "auto" is ... Sorry again if this still bring some
> misunderstanding.
>
>  >  <jmf>
>  >  This surely is a problem. Maybe any specification will meet such
> problem,
>  > generally we can not have bias to prefer specific products. But we have
> to
>  > prefer the existed users and the existed documents. This may be why ISO
>  > approved OOXML as a standard although many people opposed. BTW, Okular
>  > should be a viewer that mainly supports PDF.
>  >  </jmf>
>
>  >I wasn't attempting to start a discussion of which formats Okular
>  >prefers, which really doesn't matter. The point is to show that there
>  >is no reasonable default for a preferred-view-mode. I don't think
>  >there's anything wrong with the spec saying that the lack of a
>  >preferred-view-mode should be interpreted in an application specific
>  >manner. For an OS launcher, this probably means falling back to a
>  >default for the mimetype or extension, which is just fine. You just
>  >have to remember the following: if there is no preferred-view-mode in
>  >a document, we cannot just make up whatever we want for that value.
>  >It's simply data we don't have. Further, it's ok not to have that
>  >data.
>  Seems reasonable, you convince me. If there is no preferred view mode in a
> document, different applications can have their own interpretations, that
> should be OK since we can not cover so many applications. I also agree to
> add some words in the spec saying the lack of a preferred-view-mode should
> be interpreted in an application specific. Could you add the wording in the
> next comments? Thanks.

Sure.

What do you think of this wording?

>The manifest:preferred-view-mode attribute (should this be "tag") is
>meant to provide a preference on how the author of the document would
>like the document to be presented. There is no default. View modes are
>not necessarily generally applicable to all MIME types. The way in
>which an application responds when no "preferred-view-mode" attribute
>is specified is undefined.
The above paragraph very makes sense for me, great, thanks.

>The following modes are defined by this standard:
remove "by this standard", extraneous
>"edit", "readonly",
>and "presentation-auto-start". 
>The "edit" and "readonly" values can be
>applied to any MIME type. The "presentation-auto-start" value can be
>applied only to presentations.
"presentation-auto-start" does not make sense for me, the reason is in the first comment of this reply. Also, I suggest it is not necessary to state like "some value can be applied only to some applications" again. Remove the sentence.

>Applications are also free to create their own custom views. Custom
>views MUST start with "x-". It is RECOMMENDED that views that don't
>applied to all MIME types identify the type of document they can be
>applied to in their name (e.g. "presentation-auto-play").
It does not make sense for me to add application name in the mode name. The reason is in my previous comments. This paragraph is extraneous.

>TODO: We will also need to define the intents of the defined views.
It will be a good thing if you want. But spec should keep concise, if something is obvious, no need to state it detailedly.

>  >  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?
>  >  <jmf>
>  >  How about we just put "view" value there as a placeholder besides the
>  > definite view mode,"edit","play" and "readonly"?
>  >  </jmf>
>
>  >I don't think this does anything to address my concern.
>  Can you explain what your concern really is? If we have no appropriate
> schema to represent "any" view mode, currently we can choose: (1)do not
> define it at all, just add some words to explain that;(2) put "view" value
> there as a placeholder. Can you give a better solution? If not, why does
> neither of the above 2 options work for you? Thanks.

>I will see if I can figure out the right schema to use.
Great, looking forward to your result.

>BTW, here is a summary of the situation, as I understand it.

>Issues with consensus:
>1) the tag should be called "preferred-view-mode"
>2) "edit" is a possible value for the tag
>3) "readonly" is a possible value of the tag
>4) the value of "preferred-view-mode" should be able to be defined by the app
Do you mean the "any" view mode and you will figure out the schema? If that, it makes sense.
>5) the "preferred-view-mode" will have no default

>Unresolved issues:
>1) other standard defined values of the "preferred-view-mode" tag
mainly means "play" mode definition,current options: "play","auto-play","presentation-auto-play","presentation-auto-start". From them, choose one. I prefer "play" with the reason in the above comments. You seem to prefer "presentation-auto-start" from this reply. Welcome everyone here speak out your standpoints

>2) how applications represent custom values for "preferred-view-mode"
depends on your schema, thanks

>Everyone again, if I have forgotten something, please chime in.

>I have made a suggestion in the wording above for the representation
>of custom views (item #2).
not make sense for me. reason is not repeated again.

>I have also suggested "presentation-auto-start" in the above text as a
>replacement for "presentation-auto-play" or "play" (part of item #1).
not make sense for me. reason is not repeated again.

>Also, I still think that "readonly" mode really should be "read-only",
>but I am willing to concede on that point.
To be consistent with other parts of the spec, I suggest we do not discuss this again.


BTW, since the previous mail comments are mixed many times, it becomes a little unreadable. So I suggest in the next mail comment, we just copy the unresolved issues out, and ignore those issues with consensus. And finally I will go through the mail history and correct all the consensus issues together to the proposal.

wt

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php