Given the "tag:" uri as new information, and that it's very
close to being approved perhaps this changes things a bit.
This "tag:" URI has the form tag:yaml.org,2002:whatever and
thus is quite close to what we have already, only that we
don't do dates. Dates may be a good idea anyway...
If we used this instead, we could have the following mappings:
Thus, the only thing we'd be doing is using "tag:yaml.org,2002:"
in most places instead of "http://" as our prefix. And most of
the examples would change over to use "tag:" instead of "http:"
Since most of the comments apply to the proposal above...
| - I think ',' is rather ugly. Given the precendence set by the urn scheme, I
| think ':' is a better choice.
Well, we can use / as we did origonally, using : as the lang/type
separator would prevent us from using a URI directly. Now that we
have a more flexible URI (HTTP is more restrictive) we can also
use the semi-colon. java;com.clarkevans.Time
| - Presumably, people will be "strongly encouraged" to use this URI scheme,
| but we'd still allow them to use any URI they like. Correct?
Yes. We'd allow any old URI, but strongly encourage use of the "tag:" scheme
| - Since such a scheme is universally useful for anyone wanting to name data
| types (YAML, XML, and in fact any cross-language data transfer mechanism),
| why not go for broke and name it something like 'type:'? A bit presumptuos,
| perhaps, but hey - it drives the point home.
If we go with "tag" now, it gives us much more character flexibility
than "http", so what ever we come up with could migrate into a "type"
scheme later, no? I think "tag" is probably close-enough for now,
especially that it just made it past the last turn and is headed
for the finish line
| - It is a pity this can't be done as urn sub-scheme. It makes so much sense
| to say urn:type:java:... or maybe even urn:java:... - that's what URN's are
| *for*. Perhaps the URN RFC is over-restrictive if it forbids such a usage. I
| agree with your reasoning, however - there's no chance we can relax the URN
| rules to our needs.
The primary technical problem with "urn:" scheme is that its character
set is quite restricitve; that said we could use urn:tag:.. as the
tag proposal also includes a "urn:tag:" namespace, but the problem is that
half of Brian's characters arn't allowed with the "urn:*:" scheme. That
said, "tag:" is a URN with all of the allowable URI characters.
| Still, perhaps the IETF should be made aware how having too strict rules
| forces people to seek alternative solutions... and an unused scheme is much
| less useful than a scheme that's a bit less restrictive. At any rate...
| - Combining the above, we get "type:*:yaml.org/str". This is much better
| than "yaml:yaml,str". The former says exactly what it is - a data type,
| universal for all languages, defined under yaml.org.
| - And I'm *still* not 100% certain that a strong recommendation to place a
| human-readable document at the "end of the rainbow" - making a duck be a
| duck - isn't the simplest way all around. Much less headache all around and
| a nice convenience besides. Plus no changes to the spec :-)
A URI can be further classified as a locator, a name, or both. The
term "Uniform Resource Locator" (URL) refers to the subset of URI
that identify resources via a representation of their primary access
mechanism (e.g., their network "location"), rather than identifying
the resource by name or by some other attribute(s) of that resource.
To quote Joshua Allen (it hurts me to quote someone from Microsoft,
but I happen to think he has a good explanation):
What's important here is that HTTP is clearly a URL, and as such
It had better be about the same resource as the resource identified when
somebody else uses the same URI. The only time it doesn't matter is
when you have only HTTP, because HTTP never actually depends on the
resource -- HTTP only interacts with "representation proxies".
I don't believe that an http: URL identifies a "bag of bits". It
identifies an active agent which returns hypermedia representations
in a synchronous fashion.
The semantic distinction between "http:" and "tag:" is very important
and I think something like "tag:" is what the doctor ordered. The "tag:"
mechanism is a URN:
A URN differs from a URL in that it's primary purpose is persistent
labeling of a resource with an identifier. That identifier is drawn
from one of a set of defined namespaces, each of which has its own
set name structure and assignment procedures.
Where a URL defines an "agent" which you use a "protocol" to access,
a URN is just a name and doesn't imply access. When defining a data
type, people should be using a URN (like tag:) and not URLs (like http:)
beacuse you are identifying the type, not a server that will return to
you information about the type through the http protocol...
| Brian, you have been silent throughout this discussion - do you
| have an opinion here? Other people, thoughts?
Clark C. Evans Axista, Inc.
XCOLLA Collaborative Project Management Software