W3C home > Mailing lists > Public > public-tt@w3.org > May 2009

RE: feature review

From: Sean Hayes <Sean.Hayes@microsoft.com>
Date: Sat, 16 May 2009 11:06:17 +0100
To: "Glenn A. Adams" <gadams@xfsi.com>, Public TTWG List <public-tt@w3.org>
Message-ID: <AB3FC8E280628440B366A29DABB6B6E8075D4F5512@EA-EXMSG-C334.europe.corp.microsoft.com>
[GA] what do you mean by "understand"?
That it is does not fail to transform any dfxp document because of syntax present in the document which is valid with respect to the normative definition of validity. And if it does transform a given feature it does so respecting the syntax of that feature as present in the document, regardless of what it transforms it to.

GA] what do you mean by "all of the timing"? are you including animation? regarding styling mechanics, are you saying that a PP (presentation processor) that does not support multiple regions must support region style inheritance?

Animation is called out in the set of optional timing features at the end, along with specific clock modes and so on. By "all of the timing" I meant the basic processing of time containment semantics using begin end and dur. Yes a PP that does not support multiple regions would still notionally support region inheritance for initial values of properties like backgroundColor, since these would be present on the default region. Even if this is effectively a no-op, it doesn't seem useful to call it out as a feature, since it would be required in all processors that do support multiple regions.

[GA] i prefer having the finer granularity definitions; if we want to have an aggregate feature, e.g., one that includes #structure, #content, etc., then we can define a new feature labeling that aggregate;

I don't mind having the finer distinctions if we think it is sensible for profiles to be differentiable on that feature; but in general I think we should try and limit the number of features as much as possible and only have them if they label useful distinctions. In this case I didn't think it is very useful to have a profile that only processes a document containing head matter. But perhaps it is.

[GA] i don't understand this proposal; are you proposing a new feature called "#attribute" that means all attribute vocabulary in specification? if so, then such a feature designation seems unuseful;

The idea with the attribute is to have a core feature required in all profiles that the syntax of attributes must be recognized for transformation, and value calculation respected for presentation. As you have it, this is specified within individual attribute, which I presume is exhaustive (however this is not immediately obvious), but more problematically is not separable from the presentation semantics and so cannot be required in all profiles.



Sean Hayes
Media Accessibility Strategist
Accessibility Business Unit
Microsoft

Office:  +44 118 909 5867,
Mobile: +44 7875 091385

From: Glenn A. Adams [mailto:gadams@xfsi.com]
Sent: 16 May 2009 4:39 AM
To: Sean Hayes; Public TTWG List
Subject: Re: feature review

inline (for a few preliminary comments)

On 5/15/09 8:05 PM, "Sean Hayes" <Sean.Hayes@microsoft.com> wrote:
I have been reviewing the features set, and while I mostly agree with Glenn's formulation, I have a few suggested changes. These are based on the principles that:

any transformation processor should be required to understand timed text completely at the syntactic level,

[GA] what do you mean by "understand"?

and that any presentation processor should be able to perform all of the timing, and all of the styling mechanics, (but not any specific styling properties) necessary in creating a synchronic XSL:FO document.

[GA] what do you mean by "all of the timing"? are you including animation? regarding styling mechanics, are you saying that a PP (presentation processor) that does not support multiple regions must support region style inheritance?

for clarity in the features themselves:

I propose #content be added to #structure, as well as the syntactic aspects of #layout and #styling and thus required in the transformation and presentation profile
[GA] i prefer having the finer granularity definitions; if we want to have an aggregate feature, e.g., one that includes #structure, #content, etc., then we can define a new feature labeling that aggregate;

I propose #nested-div and #nested-span also be required in transformation and presentation profile, (and actually considered part of #content)
I propose #styling-inheritance-region be required in the presentation profile (In fact I propose that all the styling mechanics be rolled up as indivisible #styling and required in presentation profile.)

I propose that #attribute be defined to generically replace all of the lines of the form:
     A TT AF transformation processor supports the #X feature if it recognizes and is capable of transforming all defined values of X attribute.

With wording:
A TT AF transformation processor supports the #attribute feature if it recognizes and is capable of transforming all attribute vocabulary of this specification.
A TT AF presentation processor supports the #attribute feature if it implements all semantic support for attribute value resolution for all attribute vocabulary of this specification.

[GA] i don't understand this proposal; are you proposing a new feature called "#attribute" that means all attribute vocabulary in specification? if so, then such a feature designation seems unuseful;

I propose we merge #time-clock into #time-offset and  #time-clock-with-frames into #time-offset-with-frames; these don't have an independent semantics based on SMIL2.1 (http://www.w3.org/TR/2005/REC-SMIL2-20051213/smil-timing.html#Timing-OffsetValueSyntax ), except when markerMode is specified in which case #markerMode is the option.

All specific style property features should be optional, with only# fontSize-isomorphic requiring special handling (it would be mandatory for visual  presentation, and optional for audible or tactile presentation).

I think there may need to be some consolidation in the #dynamicFlow features too, but I haven't analysed that yet.

At some point I think we need to develop a caption profile which builds on the minimal presentation profile but is actually useful for web captioning (this is work for post Rec.) In order to facilitate that discussion though, I'd like to separate out at this stage the feature tables into the following:

Core: (required in any profile (#)= to be eliminated by rolling into other buckets in this table)

  #attribute #content
  #core
  #metadata
  #nested-div (#)
  #nested-span (#)
  #profile
  #structure   The following are required by any presentation profile
  #layout #styling
  #styling-chained (#)
  #styling-inheritance-content (#)
  #styling-inheritance-region (#)
  #styling-inline (#)
  #styling-nested (#)
  #styling-referential( #)


Aspects of timing that can be independently selected
Timing - (PP)= should be mandatory in any presentation profile.


  #animation #clockMode
  #frameRate
  #frameRateMultiplier #markerMode
  #smpteMode
  #subFrameRate
  #tickRate
  #timeBase-clock
  #timeBase-media (PP)
  #timeBase-smpte
  #time-clock (PP)
  #time-clock-with-frames
  #timeContainer
  #time-offset (PP)
  #time-offset-with-frames
  #time-offset-with-ticks
  #timing (PP)

Style - all of these are optional except #fontSize-isomorphic which is required for visual presentation, but which may be ignored by aural or Braille display.


  #backgroundColor
  #backgroundColor-block
  #backgroundColor-inline
  #backgroundColor-region
  #bidi
  #cellResolution
  #color
  #direction
  #display
  #displayAlign
  #display-block
  #display-inline
  #display-region
  #dynamicFlow
  #dynamicFlow-block
  #dynamicFlow-character
  #dynamicFlow-glyph
  #dynamicFlow-in
  #dynamicFlow-inline
  #dynamicFlow-inter
  #dynamicFlow-intra
  #dynamicFlow-jump
  #dynamicFlow-line
  #dynamicFlow-out
  #dynamicFlow-smooth
  #dynamicFlow-teletext
  #dynamicFlow-word
  #extent
  #fontFamily
  #fontFamily-generic
  #fontFamily-non-generic
  #fontSize
  #fontSize-anisomorphic
  #fontSize-isomorphic
  #fontStyle
  #fontStyle-italic
  #fontWeight
  #fontWeight-bold
  #length
  #length-cell
  #length-em
  #length-integer
  #length-negative
  #length-percentage
  #length-pixel
  #length-positive
  #length-real
  #lineHeight
  #opacity
  #origin
  #overflow
  #overflow-dynamic
  #padding
  #padding-1
  #padding-2
  #padding-3
  #padding-4
  #pixelAspectRatio
  #rollup
  #showBackground
  #textAlign
  #textAlign-absolute
  #textAlign-relative
  #textDecoration
  #textDecoration-over
  #textDecoration-through
  #textDecoration-under
  #textOutline
  #textOutline-blur
  #unicodeBidi
  #visibility
  #visibility-block
  #visibility-inline
  #visibility-region
  #wrapOption
  #writingMode
  #writingMode-horizontal
  #writingMode-horizontal-lr
  #writingMode-horizontal-rl
  #writingMode-vertical
  #zIndex

Sean Hayes
Media Accessibility Strategist
Accessibility Business Unit
Microsoft

Office: +44 118 909 5867,
Mobile: +44 7875 091385
Received on Saturday, 16 May 2009 10:07:10 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 2 November 2009 22:41:42 GMT