[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

re: another nit

 >>Cords are not, strictly speaking, part of MCP 2.1, and compliant
 >>implementations are not required to support them. 
 > of course, they ARE a part of mcp 2.1, or they wouldn't be in the spec
 > and they wouldn't be called mcp-cord.  sure, they're an OPTIONAL part,
 > but they're still there.
 > any objections to this change?

fwiw, i don't object; i don't think this change would alter the
semantics of the spec.  what i was after with this statement _was_
simply that cords are an optional part of the spec.

on the other hand, it raises an interesting question about the use of
the mcp- prefix.  the spec says this:
 <LI>Package names beginning with the identifier <SAMP>mcp</SAMP> are
 reserved for packages required or recommended in this and future
 versions of the MCP specification.
does this mean we'll be updating the specification proper if we
recommend new packages?  i guess so.  just curious what the feeling on
this is.  i'm not _totally_ averse to adding new subsections to S3,
but we don't want to be adding stuff to a spec that's finalised.

should we have another name hierarchy reserved to the spec authors for
recommended packages not in the spec itself?