(In reply to Cyril Concolato from comment #0)
> "Content of the 'id' attribute in the AdaptationSet or ContentComponent
> element. Empty string if 'id' attribute is not present."
> 
> The AdaptationSet@id is not unique within an MPD, but within a Period. The
> Period@id is unique within an MPD, even after MPD updates. Similarly, the
> ContentComponent@id is unique only within the AdaptationSet. Additionally,
> it is not clear how representations are exposed.

HTML audio, video and text tracks should correspond to DASH AdaptationSet or ContentComponent. Different Representations within an AdaptionSet aren't different HTML tracks.

The DASH spec says this about Representation "By collecting different Representations in one Adaptation Set, the Media Presentation author expresses that the Representations represent perceptually equivalent content. Typically this means, that clients may switch dynamically from Representation to Representation within an Adaptation Set in order to adapt to network conditions or other factors."

The DASH spec also requires (section 5.3.3.1) that all Representations in an AdaptationSet have the same values for attributes that are used to set HTML track @kind, @language and @label.

The DASH access engine will select segments from different representations; it isn't a track selection function.

> 
> I'd suggest using the triplets (Period@id, AdaptationSet@id,
> Representation@id (or ContentComponent@id) to generate an id for the track.
> It may be useful to use the MPD fragment identifiers for that but I'm not
> sure we can address representations or sub-representations properly.

Seems like (Period@id, AdaptationSet@id [, ContentComponent@id]).

(In reply to Bob Lund from comment #1)
> (In reply to Cyril Concolato from comment #0)
> > "Content of the 'id' attribute in the AdaptationSet or ContentComponent
> > element. Empty string if 'id' attribute is not present."
> > 
> > The AdaptationSet@id is not unique within an MPD, but within a Period. The
> > Period@id is unique within an MPD, even after MPD updates. Similarly, the
> > ContentComponent@id is unique only within the AdaptationSet. Additionally,
> > it is not clear how representations are exposed.
> 
> HTML audio, video and text tracks should correspond to DASH AdaptationSet or
> ContentComponent. Different Representations within an AdaptionSet aren't
> different HTML tracks.
Why not? In GPAC we expose all representations in our UI, for instance to select a representation when Adaptive Bitrate Switching is off. 

> The DASH spec also requires (section 5.3.3.1) that all Representations in an
> AdaptationSet have the same values for attributes that are used to set HTML
> track @kind, @language and @label.
Not exactly. We define how the @kind, @language and @label are generated from the MPD. We could decide to add the bandwidth value in the label in that case, or in a separate attribute.

> > I'd suggest using the triplets (Period@id, AdaptationSet@id,
> > Representation@id (or ContentComponent@id) to generate an id for the track.
> > It may be useful to use the MPD fragment identifiers for that but I'm not
> > sure we can address representations or sub-representations properly.
> 
> Seems like (Period@id, AdaptationSet@id [, ContentComponent@id]).
In a first or minimal approach, yes. I agree.

(In reply to Cyril Concolato from comment #2)
> (In reply to Bob Lund from comment #1)
> > (In reply to Cyril Concolato from comment #0)
> > > "Content of the 'id' attribute in the AdaptationSet or ContentComponent
> > > element. Empty string if 'id' attribute is not present."
> > > 
> > > The AdaptationSet@id is not unique within an MPD, but within a Period. The
> > > Period@id is unique within an MPD, even after MPD updates. Similarly, the
> > > ContentComponent@id is unique only within the AdaptationSet. Additionally,
> > > it is not clear how representations are exposed.
> > 
> > HTML audio, video and text tracks should correspond to DASH AdaptationSet or
> > ContentComponent. Different Representations within an AdaptionSet aren't
> > different HTML tracks.
> Why not? In GPAC we expose all representations in our UI, for instance to
> select a representation when Adaptive Bitrate Switching is off.


In the case of MSE, there is no need for representations as tracks. The Web app already has access to all representations and can switch or not among representations in an AS.

There is no defined HTML API for the Web app to determine when ABR switching is off if the UA implements MPD processing and representation switching. Further, representation switching by enabling/disabling video tracks is not going to result in seamless switching.

> 
> > The DASH spec also requires (section 5.3.3.1) that all Representations in an
> > AdaptationSet have the same values for attributes that are used to set HTML
> > track @kind, @language and @label.
> Not exactly. We define how the @kind, @language and @label are generated
> from the MPD. We could decide to add the bandwidth value in the label in
> that case, or in a separate attribute.
> 
> > > I'd suggest using the triplets (Period@id, AdaptationSet@id,
> > > Representation@id (or ContentComponent@id) to generate an id for the track.
> > > It may be useful to use the MPD fragment identifiers for that but I'm not
> > > sure we can address representations or sub-representations properly.
> > 
> > Seems like (Period@id, AdaptationSet@id [, ContentComponent@id]).
> In a first or minimal approach, yes. I agree.

> In the case of MSE, there is no need for representations as tracks. The Web
> app already has access to all representations and can switch or not among
> representations in an AS.
> 
> There is no defined HTML API for the Web app to determine when ABR switching
> is off if the UA implements MPD processing and representation switching.
> Further, representation switching by enabling/disabling video tracks is not
> going to result in seamless switching.
This clarifies your model. Thank you. I think it would be worth having an introduction in the DASH section describing that model.
I've created a PR for that:
https://github.com/w3c/HTMLSourcingInbandTracks/pull/30

(In reply to Cyril Concolato from comment #4)
> > In the case of MSE, there is no need for representations as tracks. The Web
> > app already has access to all representations and can switch or not among
> > representations in an AS.
> > 
> > There is no defined HTML API for the Web app to determine when ABR switching
> > is off if the UA implements MPD processing and representation switching.
> > Further, representation switching by enabling/disabling video tracks is not
> > going to result in seamless switching.
> This clarifies your model. Thank you. I think it would be worth having an
> introduction in the DASH section describing that model.
> I've created a PR for that:
> https://github.com/w3c/HTMLSourcingInbandTracks/pull/30

This is a good introduction. The wording suggest that track objects are created differently in the two cases, however. The following  is a slight modification.

 [[MPEGDASH]] defines formats for a media manifest, called MPD (Media Presentation Description), which references media containers, called media segments based on [[MPEG2TS]] or [[ISOBMFF]]. The user agent or the Web application (using MSE [[MSE]]) may process the media manifests and fetch media segments. When the user agent processes the MPD and fetches media segments, it creates HTML track objects based on media segment and MPD data. When the Web application processes the MPD and fetches media segments, the user agent also creates HTML track objects using data in media segments  passed to it by the Web application. The Web application may set default track attributes from MPD data, using the trackDefaults object, that will be used by the user agent to set attributes not set from initialization segment data.

Please update the PR if this is agreeable.

(In reply to Bob Lund from comment #5)
> This is a good introduction. The wording suggest that track objects are
> created differently in the two cases, however. 
Well, they are not exactly created in the same way: in one case it's the UA that does it all by itself; in the other case, it's done by the UA using to MSE and with instructions from the Web Application. I've tried rewording it.

> The following  is a slight
> modification.
> 
>  [[MPEGDASH]] defines formats for a media manifest, called MPD (Media
> Presentation Description), which references media containers, called media
> segments based on [[MPEG2TS]] or [[ISOBMFF]]. 
In the initial text I meant to say that MPEG-DASH defines formats for some media segments not all. I've clarified that.

> The user agent 
Ok, I've changed "browser" to "user agent".

> or the Web
> application (using MSE [[MSE]]) may process the media manifests and fetch
> media segments. 
Strictly speaking, the Web application does not process the media manifests and fetch the segments using MSE. That's done using XML parsing and XHR.

> When the user agent processes the MPD and fetches media
> segments, it creates HTML track objects based on media segment and MPD data.
I think the hint about the adaptive handling by the UA is important as it indicates that representations as such won't be exposed.

> When the Web application processes the MPD and fetches media segments, the
> user agent also creates HTML track objects using data in media segments 
> passed to it by the Web application. The Web application may set default
> track attributes from MPD data, using the trackDefaults object, that will be
> used by the user agent to set attributes not set from initialization segment
> data.
> 
> Please update the PR if this is agreeable.
I've update the PR. Hope this is fine with you.

(In reply to Cyril Concolato from comment #6)
> (In reply to Bob Lund from comment #5)
> > This is a good introduction. The wording suggest that track objects are
> > created differently in the two cases, however. 
> Well, they are not exactly created in the same way: in one case it's the UA
> that does it all by itself; in the other case, it's done by the UA using to
> MSE and with instructions from the Web Application. I've tried rewording it.
> 
> > The following  is a slight
> > modification.
> > 
> >  [[MPEGDASH]] defines formats for a media manifest, called MPD (Media
> > Presentation Description), which references media containers, called media
> > segments based on [[MPEG2TS]] or [[ISOBMFF]]. 
> In the initial text I meant to say that MPEG-DASH defines formats for some
> media segments not all. I've clarified that.
> 
> > The user agent 
> Ok, I've changed "browser" to "user agent".
> 
> > or the Web
> > application (using MSE [[MSE]]) may process the media manifests and fetch
> > media segments. 
> Strictly speaking, the Web application does not process the media manifests
> and fetch the segments using MSE. That's done using XML parsing and XHR.
> 
> > When the user agent processes the MPD and fetches media
> > segments, it creates HTML track objects based on media segment and MPD data.
> I think the hint about the adaptive handling by the UA is important as it
> indicates that representations as such won't be exposed.
> 
> > When the Web application processes the MPD and fetches media segments, the
> > user agent also creates HTML track objects using data in media segments 
> > passed to it by the Web application. The Web application may set default
> > track attributes from MPD data, using the trackDefaults object, that will be
> > used by the user agent to set attributes not set from initialization segment
> > data.
> > 
> > Please update the PR if this is agreeable.
> I've update the PR. Hope this is fine with you.

PR has been merged.