RE: Don't put descriptive info in a URI, only identifying info

> > Re "http://www.w3.org/TV/TVWeb/TVWeb-URI-Requirements-19981126.html"
> > 
> > (Minor note: RFC 2119 isn't really appropriate for use
> > in a requirements document; the MUST/MAY/SHOULD levels
> > apply to implementation compliance with a protocol
> > specification, not specification compliance with
> > protocol goals.)
> > 
> 
> Do you have a suggestion how to solve this ?
> 
> The first version of this requirements document loosely used
> the words "must" and "should" and we thought it appropriate 
> to make their meaning explicit.

I struggled with this in draft-ietf-fax-goals; I didn't like
using MUST/MAY/SHOULD for protocol goals and wound up with
some other way of characterizing it.

> - Is there some other document we could reference ?
> - Should we specify the meaning ourselves in the requirements 
>    document ? 
> - Keep as is, maybe adding a note reflecting your comment ?
> 
> I opt for the third approach, and will modify our draft accordingly


> > You identify a TV broadcast content model
> > (service, event, component, and fragment) but haven't
> > justified the need for a URL scheme to span them all.
> > 
> 
> Good point.
> (We actually excluded fragment, see requirement 2, but 
> that's not relevant to your comment).
> 
> Service, event, component and fragment are the entities 
> on which TV Broadcast systems are modeled. They are modeled
> in a hierarchy, as explained in the requirements document.
> As URIs support hierarchy, it seemed logical to look for 
> one URI scheme to span them all. But I agree, this is not 
> an a priori prerequisite.
> 
> We are collecting use cases to better grasp our needs.
> 
> 
> > TV channels and TV programs are different kinds of resources,
> > and might need entirely different schemes, since they have
> > very different kinds of access methods and specifications.
> > 
> 
> I am not sure I understand you, particularly your phrase 
> "they have very different kinds of access methods and specifications".
> Can you elaborate on that?

What are the operations that you might perform on the different
levels of "service, event, component, fragment"? You could
say "please record this event for me", or "this event is
repeated on another service at a different time". The 'methods'
you use to access a resource are 'what do you do with it'. Each
level of the hierarchy has different specifications, since an
'event' might be specified by a 'service' and a 'time' or by
some other identifier.

> > The TVWeb-URI-Requirements seem to be written presuming that
> > there's only one URL scheme.
> > 
> 
> Neither sure I understand you, probably a language problem.
> I assume you mean that we presume there exists a URL scheme 
> able to cover all our requirements.
> 
> It is certainly our aim to get at one URI scheme being able
> to identify all types of TV Broadcast resources. The above 
> use case excercise - catalyzed by your comment - may relax 
> that aim.
> 
> Do you have a suggestion how we should separate resource ?
> Should we take another view in modeling the broadcast content ?

You've made some good progress on establishing a model
(service, event, component, fragment), and now need to:

a) decide on the utility of specifying each of these with URLs
  and justify them (when would you use a URL for a service?
  When would you use a URL for an event, as separate from
  a URL for a component?)

b) elaborate the different kinds of information needed to
  specifying each kind of each of the levels
  (How do you specify a TV broadcast service? An IP multicast
   service? What kinds of information are needed? What are
   the different ways of identifying an event? (service + time,
   unique identifier, etc.)

c) decide on URL encodings for each of the kinds of specifications
   defined in (b). (Defining syntax and parsing rules).

Larry

Received on Monday, 28 December 1998 17:46:02 UTC