[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Proper use of FPI name spaces

• From: "Rick Jelliffe" <ricko@a...>
• To: "Terry Allen" <tallen@s...>, <xml-dev@i...>
• Date: Tue, 2 Dec 1997 05:55:30 +1100

 
> From: Terry Allen <tallen@s...>

> Rick Jelliffe wrote:
> | 
> | You can make up your own FPIs *now* for all MIME types using the following 
> | pattern.
> | 
> | <!NOTATION video-mpeg 
> |      PUBLIC "+//IDN ds.internic.net/rfc/rfc2046.txt//NOTATION 
> |      Multipurpose Internet Mail Extensions::video/mpeg//EN">
> 
> Really, only the owners of the name space denoted by
> "IDN ds.internic.net" should be assigning such FPIs.  It will not do
> for just anybody to be assigning names in someone else's name space.
> 
> In your own name space you could name something belonging to someone
> else (unless legal issues prevent), but that's different.
 
In the general case, yes.  

But in this case, where internic have placed the information in a fixed
place specifically to provide a long-term repository for the public,
and where SGML (i.e. WebSGML) provides a clear way to express the owner,
I don't have any qualms about intruding. 

The FPI mechanism is supposed to stop identifier collisions, where two FPIs
mean the same thing.  In this case, if they use the same FPI what
else can they be meaning except the same thing?  If they decide to make
their own FPI, then everyone can switch to that (if it ever happens).


Rick Jelliffe




xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i...
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@i... the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@i... the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@i...)

• Prev by Date: RE: EMBED and validation
• Next by Date: Entity substition in non-validating parsers (was RE: EMBED and validation)
• Previous by thread: Proper use of FPI name spaces
• Next by thread: Entity substition in non-validating parsers (was RE: EMBED and validation)
• Index(es):
  • Date
  • Thread