RE: ISSUE-109 (inconsistent handling of profile conflicts): Proposal to unify handling of profile conflicts. [DFXP 1.0]

OK, that's a reasonable definition, but it's not what it currently says.

It's not union in a mathematical sense though; it's your combining operation. That operation could equally well apply to a profile defined by multiple ttp:features elements in a ttp:profile, or even by multiple ttp:feature elements in a ttp:features; however I still now think we should insist that ttp:profile should be internally consistent, or the profile is ignored.

Sean Hayes
Media Accessibility Strategist
Accessibility Business Unit
Microsoft

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

From: Glenn Adams [mailto:gadams@xfsi.com]
Sent: 28 May 2009 11:06 AM
To: Sean Hayes
Cc: Timed Text Working Group WG
Subject: Re: ISSUE-109 (inconsistent handling of profile conflicts): Proposal to unify handling of profile conflicts. [DFXP 1.0]

my concept of "the profile of a document instance" is "the union of all profiles that are specified that apply to the document"; our equipment for defining profile(s) is NOT intended to define the document profile as much as it is to define what is required in the processor; for example, there may be features used in a document instance that it does not specify as being required to support; similarly, there may be features that the specified profile(s) require of a processor that is not actually used by the document;
On Thu, May 28, 2009 at 5:58 PM, Sean Hayes <Sean.Hayes@microsoft.com<mailto:Sean.Hayes@microsoft.com>> wrote:
I don't think I agree with that as it stands. The language of 5.2 as currently drafted speaks of the profile of a document instance in the singular, and not in the plural; and I read that as creating a single document profile.

If a profile is internally inconsistent (as the transformation profile currently is in appendix G.2); then this is would be same thing as introducing an inconsistency into the document profile by combining multiple profiles.

To support your concept you need to reword 5.2 to allow the concept of a document satisfying multiple document profiles, rather than defining a document profile. I'm not sure we have a justification for that level of complexity, but it would at least make your construction acceptable.

I also on reflection think that it should be an error if a profile construct is internally inconsistent.

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> [mailto:public-tt-request@w3.org<mailto:public-tt-request@w3.org>] On Behalf Of Glenn A. Adams
Sent: 27 May 2009 2:40 AM
To: Timed Text Working Group WG
Subject: RE: ISSUE-109 (inconsistent handling of profile conflicts): Proposal to unify handling of profile conflicts. [DFXP 1.0]


actually, it is not inconsistent; it is intentionally different: it is
one thing to define an internally consistent definition of a profile, it
is another thing to logically express that more than one profile is
intended to be satisfied; the differences in the language reflect these
two distinct intents;

no change is required;

> -----Original Message-----
> From: public-tt-request@w3.org<mailto:public-tt-request@w3.org> [mailto:public-tt-request@w3.org<mailto:public-tt-request@w3.org>] On
Behalf Of Timed Text
> Working Group Issue Tracker
> Sent: Saturday, May 23, 2009 5:57 AM
> To: public-tt@w3.org<mailto:public-tt@w3.org>
> Subject: ISSUE-109 (inconsistent handling of profile conflicts):
Proposal to unify
> handling of profile conflicts. [DFXP 1.0]
>
>
> ISSUE-109 (inconsistent handling of profile conflicts): Proposal to
unify handling of
> profile conflicts. [DFXP 1.0]
>
> http://www.w3.org/AudioVideo/TT/tracker/issues/109
>
> Raised by: Sean Hayes
> On product: DFXP 1.0
>
> The following language appears in the definition of the profile
element:
>
> "If more than one ttp:profile element appears in a TT AF document
instance, then all
> specified profiles apply simultaneously. In such a case, if some
feature or some
> extension is specified by one profile to be required (mandatory) and
by another profile
> to be optional (voluntary), then that feature or extension must be
considered to be
> required (mandatory)."
>
> This is inconsistent (and for no obvious reason) with the case where
the same element is
> multiply defined within a single <profile> element; where the language
below applies.
> This requires two different types of handling in the processor where
one would suffice
> if the handling were unified.
>
> "for each ttp:feature and ttp:extension element descendant of the
ttp:profile element,
> using a post-order traversal, merge the specified feature or extension
with the features
> and extensions of the profile, where merging a feature or extension
entails replacing an
> existing feature or extension specification, if it already exists, or
adding a new
> feature or extension specification, if it does not yet exist in the
profile;"
>
> propose to replace the latter language with something to the effect
of:
>
> for each ttp:feature and ttp:extension element descendant of the
ttp:profile element,
> using a post-order traversal, merge the specified feature or extension
with the features
> and extensions of the profile, where merging a feature or extension
entails adding it if
> it does not yet exist in the profile; or where it does exist in the
profile and one
> designation denotes it required (mandatory) and the other optional
(voluntary), then
> that feature or extension must be made required (mandatory) in the
profile.
>
> (the alternate would be to treat the profile elements in document
order would also be
> acceptable)
>
>