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>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] 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] On
> Behalf Of Timed Text
> > Working Group Issue Tracker
> > Sent: Saturday, May 23, 2009 5:57 AM
> > To: 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)
> >
> >
>
>
>
>