'all' formats implemented = ??

At 12:02 PM 2001-04-21 -0400, Ian Jacobs wrote:
>Al Gilman wrote:

[...]
>> >Issue 4: Conformance for some formats only must be clarified
>> >[Proposal]
>> >----------------------------------------------------------
>> >
>> >It is my understanding that our document allows conformance for a
>> >subset of all formats implemented by the user agent. For
>> >instance, the claimant might choose to claim conformance for HTML
>> >and PNG, but not for JPEG, even if it implements JPEG. Imagine a
>> >media player that implements 20 formats. A developer may not wish
>> >to claim conformance for all 20, and shouldn't be required to.
>> >
>> >Checkpoint 2.1 reads:
>> >
>> >   "For all format specifications that the user agent implements,
>> >   make content available through the rendering processes
>> >   described by those specifications."
>> >
>> >I think that "for all" needs to be restricted to "for all that
>> >are part of the conformance claim". 

AG2::  I agree that "all ... that the user agent implements" as used here is
intended to be scoped to the functions set out in the conformance claim.  I am
not so sure this requires, or is best clarified by, the changes here proposed
in the checkpoint language.

>I think the same change needs
>> >to be made for checkpoint 2.2 ("For all text formats..."),
>> >8.1 ("of all implemented specifications"), and 8.2.
>> >
>> >I'm not sure how to rewrite them (as I don't want to mention
>> >conformance in the checkpoints if I can avoid it). Something like
>> >this might be reasonable:
>> >
>> ><NEW 2.1>
>> >For the format specifications implemented to satisfy the
>> >requirements of this document, make content available through
>> >the rendering processes described by those specifications."
>> ></NEW 2.1>
>> >
>> >------------------
>> >
>> ><OLD 2.2>
>> >For all text formats that the user agent implements, provide
>> >a view of the text source.
>> ></OLD 2.2>
>> >
>> ><NEW 2.2>
>> >For text formats implemented to satisfy the requirements
>> >of this document, provide a view of the text source.
>> ></NEW 2.2>
>> >
>> 
>> AG:: I would like to have an example of hardship imposed by the simpler
rule
>> before considering this level of hair.  That is for 2.1 and 2.2, I don't
see
>> the problem.  8.1 is another matter.
>
>IJ: I don't think it's a question of hardship, just of conformance
>consistency. I have been talking to vendors and saying "the conformance
>model allows you to conform for certain formats only, so if you
>implement
>3 video formats, but only meet the requirements for two of them, you
>can still conform for those two." Therefore, statements such as
>"for all formats that you implement" seem inconsistent with the
>desired flexibility in the conformance model.
> 

AG2::  It may leave room for confusion.  On the other hand, so far I would
tilt
toward making this unambiguous by a more explicit statement in the conformance
section and possibly a footnote the first time the term 'implements' is
used in
this way.  Perhaps dropping the 'all' would help, as it doesn't really add
anything.

<newNew 2.1>
   "For format specifications that the user agent implements*,
   make content available through the rendering processes
   described by those specifications."
</newNew 2.1>

* The formats 'implemented,' for the purposes of assessing conformance, may be
limited by the particulars of a conformance claim, see [reference to
conformance section].

>> >------------------
>> >
>> ><OLD 8.1>
>> >Implement the accessibility features of all implemented
>> >specifications (etc.).
>> ></OLD 8.1>
>> >
>> ><NEW 8.1>
>> >Implement the accessibility features of all specifications
>> >implemented to satisfy the requirements of this document (etc.)
>> ></NEW 8.1>
>> >
>> >------------------
>> >
>> ><OLD 8.2>
>> >8.2 Use and conform to ...
>> ></OLD 8.2>
>> >
>> ><NEW 8.2>
>> >8.2 To satisfy the requirements of this document,
>> >    use and conform to ...
>> ></NEW 8.2>
>> >
>> 
>> AG:: This is a genuine problem.  The browser configuration item does not
>> decide
>> whether it implements Flash or not.  It just checks locally for a
compatible
>> handler for the medium.
>
>IJ: I'm not sure I understand. It's true that the browser doesn't
>decide, but the claimant does (by including the Flash plug-in in the
>claim).
> 
>> >----------------------------------------------------------
>> >Issue 5: Checkpoint 3.3 (blinking/animation) and streams
>> >[No proposal]
>> >----------------------------------------------------------
>> >
>> >What is the relationship between streaming and animated text?
>> >Animated text may be part of a text stream (so the text content
>> >is not all available at time "t"). How should the animated text
>> >be rendered as motionless text (per 3.3) in that case?
>> >
>> >I don't think that the user agent should have to wait for the
>> >entire text stream to render part of it as motionless text.
>> >
>> >I can imagine the "subtitles" technique, where a phrase of text
>> >is rendered for a few seconds, then another phrase, etc.  (I
>> >don't think that this should be considered an animation, since
>> >this is not a "visual movement effect" as mentioned in the
>> >glossary.) Furthermore, in this case, I don't think there's
>> >interaction between checkpoint 3.3 (animated text) and 2.6
>> >(respect synchronization cues).
>> >
>> 
>> AG::  Who is saying what, here?  I can't follow the boundaries of
'animation'
>> in any of the above.
>> 
>> Yes, there is interaction between 3.3 and 2.6 where timed text captions are
>> synchronized with a video, for example.  Stopping the text from changing
will
>> (depending on the SMIL synchronization details as discussed above)
sometimes
>> require that the video be stopped.
>
>IJ: I would distinguish animated text (by which I mean scrolling along
>the bottom of the screen) from changing text (e.g., as subtitles in
>a movie are replaced by new subtitles after a few seconds, and in
>synchrony with the video track). 
>
>There is an issue here: define "blinking". Do changing subtitles
>count as blinking text? (I hope not.) At what rate does blinking
>start?
> 
>> There may be a requirement buried in here for a pop-on presentation method
to
>> be an option for any timed-text stream, but we haven't studied it in
enought
>> detail to define a hard and fast requirement.
>> 
>> >----------------------------------------------------------
>> >Issue 6: Checkpoint 4.6: Captions positioning
>> >[Proposal]
>> >----------------------------------------------------------
>> >
>> >What happens when the author has laid out captions with some
>> >particular constraints (e.g., take up fifty percent of the
>> >parent's available horizontal width and be centered within that
>> >width)? Should the user be able to override that? What happens to
>> >the rest of the layout?
>> >
>> >Checkpoint 4.6 reads: "For graphical viewports, allow the user to
>> >position text transcripts, collated text transcripts, and
>> >captions in the viewport." However, I can imagine techniques
>> >(that might even address the previous question) where a solution
>> >would be to render the captions in a separate viewport (i.e., not
>> >in the same viewport, which is suggested by the end of 4.6). Did
>> >we mean to exclude the technique of rendering in a separate (and
>> >positionable) viewport?
>> >
>> >Proposed:
>> >
>> ><NEW 4.6>
>> >  "For graphical viewports, allow the user to position text
>> >  transcripts, collated text transcripts, and captions in the
>> >  same or another viewport."
>> ></NEW 4.6>
>> >
>> >For example, the user might be able to select captions and
>> >"extract them" from the presentation into a second viewport,
>> >leaving the layout otherwise intact.
>> >
>> 
>> AG:: I do not concur with this proposal.  In the earlier discussion, we
>> pointed
>> out that this positioning capability was so a low vision user could control
>> what portion of the video is adjacent to the captions and hence visible
within
>> the cropped effective viewport along with the captions when the user is
>> using a
>> high power of magnification.  Moving the captions into a separate window
>> prevents the user from having the juxtaposition capability they need.
>
>IJ: I'm not sure I agree. I was aware of this case when I made
>the proposal. It seems like an implementation detail to me whether
>the captions track is moved to a global x,y that happens to
>be in the same viewport, or whether it is put in a new viewport
>that is then moved to the same global x,y. One difference might be
>that the new viewport has chrome to it, and that chrome might get
>in the way of the video content behind it. But suppose it doesn't
>have a lot of chrome? Then it seems to me to provide the same
>functionality, but the ability to move the viewport is provided
>by the windowing system, not the user agent directly.
>
> 
>> Another viewport is sometimes desirable, but does not satisfy this
>> requirement.
>> 
>> What happens to the rest of the layout?  It is unaffected, as if grouped
into
>> wallpaper, for the purposes of positioning the caption display.
>
>IJ: Yes.
> 
> - Ian
>
>-- 
>Ian Jacobs (ij@w3.org)   <http://www.w3.org/>http://www.w3.org/People/Jacobs
>Tel:                     +1 831 457-2842
>Cell:                    +1 917 450-8783
>

Received on Saturday, 21 April 2001 13:42:34 UTC