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:  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:  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:  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.

> 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 ...

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.

Received on Saturday, 6 December 2008 23:48:56 UTC