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

Larry Masinter wrote:
> 
> 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.

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


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


> Larry

Thanks,

Warner.

--
Philips Research Labs. WY21 ++ New Media Systems & Applications
Prof. Holstlaan 4 ++ 5656 AA  Eindhoven ++ The Netherlands
Phone: +31 4027 44830
Fax:   +31 4027 44648    tenkate@natlab.research.philips.com

Received on Tuesday, 22 December 1998 05:14:52 UTC