RE: TTWG minutes 12/05/08

Inline:

Sean Hayes
Media Accessibility Strategist
Accessibility Business Unit
Microsoft

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


-----Original Message-----
From: public-tt-request@w3.org [mailto:public-tt-request@w3.org] On Behalf Of Glenn A. Adams
Sent: 06 December 2008 23:48
To: Public TTWG List
Subject: Re: TTWG minutes 12/05/08



My (post-dated) regrets on this telecon. But I have a couple of questions as
follow-on below.

G.

On 12/6/08 1:57 AM, "Geoff Freed" <geoff_freed@wgbh.org> wrote:

> PH:  7.1.4. says only p is necessary.  Should say that we allow divs as
> described in XML description.

I'm no sure what is meant by "p is necessary" here. 7.1.4 paragraph 4 says
"zero or more p elements" and the XML representation says Block.class*. So
no p element is required in a div.

SH:{
What he means is, alter the note to read:

When rendered on a continuous (non-paged) visual presentation medium, a div element is expected to generate a single block area that contains zero or more child block areas generated by the div element's child div or p elements.

And the normative statement below to read:
The div element accepts as its children zero or more elements in the Metadata.class element group, followed by zero or more elements in the Animation.class element group, followed by zero or more div or p elements.
}

> SH:  Add to list-- should we be basing ourselves on XML 1.0 or 1.1?
>
> PH:  Mistake in DFXP regarding this.

What mistake is being referred to here? The intent adopted in prior meetings
was to go with 1.1.

SH:{
The issue was raised that XML 1.1 has some implementation problems, and the W3C seem less than committed to it, not that it was a mistake when we decided to do that, but that it might be now.
The W3C has issues XML1.0 5th edition which appears to fix the majority of the problems, so it was mooted that we use that as our reference.
}


> SH:  But we do need certain things from XML, like charset and language tags,
> so the info set isn't enough.

Charset is not relevant in info-set, since character items are coding
independent; i.e., by that time they are considered to be 'abstract'
characters drawn from the Unicode character reperetoire independent of their
particular bit encoding.

Language tags are already represented in info set as attribute items. So not
sure what issue is here.
SH:{
The issue would be that if we ONLY referenced the info set, then it would not be clear what language tags we allow (as you point out they are referenced in XML S 2.12).
Actually XML1.0(5th) refers to an updated rfc which supercedes rfc3066, so we do need to make a decision.
}

> SH:  Maybe, but we need to point at a specific version of XML to give meaning
> to xml:lang and others not covered by infoset.  They have values we need to
> reference.  Could cut out XML and go directly to RFC ourselves.  All the
> things we inherit from XML we'd have to refer specifically.

As presently defined, the meaning of the value(s) of xml:lang are obtained
from XML 1.1 Section 2.12, which states:

"The values of the attribute are language identifiers as defined by [IETF
RFC 3066], Tags for the Identification of Languages, or its successor; in
addition, the empty string may be specified."

and

"The intent declared with xml:lang is considered to apply to all attributes
and content of the element where it is specified, unless overridden with an
instance of xml:lang on another element within that content."

I don't see any reason to add anything to this, at least normatively. We can
add an informative note if any elaboration is needed. And I'm not convinced
there is a need.
SH: { There is no need to add anything, the point is we need a reference to at least some version of the XML spec to pick up this language, we cannot just rely on an infoset reference.
}

> DK:  We're keeping with xml:id.  We've made a decision.
>
> ALL:  Yay!

Good decision. I concur.

> SH:  ...  xml:lang used to identify new language only ...
SH : {
I think this is a misquote or a mistake, I did not intend to say new.
}
Actually, this is not necessarily the case. The document language may be
specified as xml:lang="", which is quite legitimate. In that case, the
default language inherited by descendant elements is <unspecified>. So in
such a case, it would be quite legitimate for top level divs to specify
their own, possibly distinct language.

However, it is true that no switch semantics are defined by DFXP, so that,
other than time based selection (which are defined), such all divs would be
simultaneously in scope for presentation (in whatever regions they map to).

> SH:  No; DFXP should allow alteration of the document before or during
> processing.  That would allow us more flexibility.  <switch> would force us to
> think of all possible cases now, too much work now.

Agreed.

> JB:  If we allow the concept of multiple languages, we need to say so.  We do
> need to differentiate between documents where everything is to be displayed,
> and docs where only portions are to be displayed.

I disagree. I don't think we need to differentiate. We merely need to define
consistent expectations about the semantics of transformation and
presentation. Transformation processors may rewrite any DFXP document into
another DFXP document, excluding, adding, or mutating content. Presentation
processors must present what is in the received document, modulo possible
user specified defaults (and perhaps overrides).

A hybrid processor, which perhaps we should also define, might be
characterized as a combination of a transformation pre-processor followed by
presentation processor. I believe this is what ccPlayer presently
implements.

> JB:  All I want is to embed is a marker in the doc that tells the processor to
> apply a specific logic.
>
> SH:  Apply XSL, for example?
>
> JB:  To indicate that the content is an *alternative.*
>
> SH:  Is more complicated than that.  Unless you can identify a vocabulary of
> things that are generic, we need to identify all attribute values.
>
> JB:  Not suggesting that.
>
> SH:  Some kind of vocabulary.  Will be more complex.
>
> PH:  Seems we don't want to follow this practice, true?
>
> JB:  Concerned that the MXF/DFXP discussion may be following the same path as
> ccPlayer, which is worrisome.

Like SH, I am opposed to adding a switch element or any explicit alternative
selection mechanism. Such transformations are and should be processed
earlier in the processing pipeline prior to presentation processing. There
are many existing technologies, such as XSLT that can handle this quite
adequately. How the information is expressed inside a DFXP document to
facilitate such transformations should follow a separate development and
standardization path, and could define new vocabulary, perhaps even in the
TT Metadata Extensions or some non-TT namespace.

> PH:  Is okay.  Send an example of using <region>?
>
> SH:  Sent this morning.

I need to comment on some problems in that example, so see my (upcoming)
follow on to that message.


> SH:  May create an XSL style sheet which would find these things and change
> the attributes on them.  Pretty complicated.
>
> PH:  Player shouldn't be using XSL.

I assume that XSLT is meant here rather than XSL. In any case, I agree we
should not define presentation processing semantics in a way that requires
support from some preliminary transformation processing technology. However,
I am not convinced we need to define anything at this stage, other than
perhaps define the general notion of a hybrid processing pipeline without
being more specific.

SH:
{
Agreed. XSLT was being used as an example here; and not being proposed as any kind of requirement. The idea is to have the spec allow for non specific preprocessing; and define a hybrid processor as one where the output of that pre-processing could be expressed as valid timed text, and thus the presentation semantics also apply.

I believe there is some merit however in Johns argument that a document be able to record the expectation of such processing; and some timed text metadata to that effect may be warranted.
}

Received on Sunday, 7 December 2008 11:04:58 UTC