[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: PaceRecommendIdScheme
On Fri, 30 Jul 2004 14:30:24 +0900, Martin Duerst <duerst@xxxxxx> wrote:
My guess is that if we just recomment a scheme, then we will
just get something hard-coded, with some assumptions that easily
may break the properties we need.
I'm not saying recommending a scheme is enough. Please read
PaceRecommendIdScheme if you haven't, because that pace does a lot more
than just recommending a scheme. It still doesn't do enough to prevent bad
ID's, though, so any language on how to improve it is appreciated.
We really have to get the message out there that it's not the
scheme that counts, it's how the ids are created and maintained
properly.
Definately. Though, recommending a scheme other than HTTP will make people
stop thinking that the URI is dereferencable, and thus make it a lot less
transient. It has been said that the problem with HTTP URI's is not that
they're HTTP URI's, but the way people think about HTTP URI's. It's this
line of thought we need to fight and prevent, and the most effective way
to do it, is to recommend another scheme.
How long do you think it might take the IPTC to 'perhaps study if
NewsML URN are of interest for a broad range of users'? Do you
want to wait that long for the Atom spec to finish? I don't.
If we agree that it's a good idea to recommend a scheme, it's just to
begin pushing on LSID and 'tag' to finish, and IPTC to widen NewsML URN's
application space. If either of this is done by the time Atom goes 1.0, we
will have to reconsider recommending a scheme, but if one or more of them
are, there's no problem.
Nobody is telling anybody that we should refrain from using it.
But if we make it the only scheme, or the 'recommended' scheme,
we are bound to put additional requirements and pressure on that
scheme, which may not work out well in the long range.
Maybe, maybe not. I'm not all that worried about the impact Atom's
recommended URI scheme will have on the picked scheme, though.
As a (theoretical) example, assume that currently newsml:
would be allowed to point to anything, but for certain
reasons, the IPTC wanted to change the definition so that
new ids created would only refer to NewsML items.
Maybe, and just maybe, this is a good point and example. I'd like to note,
though, that it's perfectly fine for Atom to specify its own URI scheme.
It's also no problem changing the recommended scheme whenever this happens.
With the language above, there is a risk some blogging tools hard-code
newsml into their code. That would be bad.
Although I don't necessarily think that it's a very good idea; why would
that be bad, exactly?
Because some people may want to use different ids, or may want to use
different ids because their content comes from somewhere else and
already has an id.
I'd say that most existing ID's don't conform to atom:id's requirements
anyway, so that's not something I'm concerned about. atom:id is probably
the most important facet of Atom publishers needs to conform to, and I
don't think any tool conforms to it today.
--
Asbjørn Ulsberg -=|=- asbjornu@xxxxxxxxxxx
«He's a loathsome offensive brute, yet I can't look away»