Dan Brickley wrote: > >> * If you're going to store a language, use something like >> info:lang/en/US. >> * If you're going to store a Java class, use something like >> info:lang/com/example/package#Class. > > There is a java: URI scheme. This is used for example in ARQ for > dynamic code loading. I don't see a case for using info: instead. OK, I'm on Dan's side, now. As I pointed out in my earlier, email, there actually is *no* official java: URI scheme, even though some people are using it as if it were. That's why I proposed to the OCLC the info namespaces info:java/, info:lang/, and info:media/ . But I just received a message from the OCLC stating that it doesn't want to approve the "java" identifier because it's a service mark; that I'll have to talk to the Library of Congress to find out how they want to identify languages in URIs; and that I'll have to talk to IANA if I want to represent a MIME type in a URI. That's all about as much trouble as simply proposing top-level URI schemes to begin with. And everyone here knows how long this will take. (Maybe before XHTML 2.0 becomes a recommendation? I'm not holding my breath.) So I'm switching sides. "Official" standards be damned. I'm going to use URI schemes of java:, lang: and media:. That gives me: java:/com/example/package#Class lang:/en/US media:/text/plain > > It's good to agree on ways of doing these things, but your choices > seem a little arbitrary, Do they seem a little less arbitrary now? ;) > and not yet widely used. Looks like I'll be the first. :) GarretReceived on Friday, 12 October 2007 18:38:01 UTC
This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 08:45:03 UTC