On Feb 26, 2007, at 3:39 PM, James Craig wrote:
> Mike Kaply wrote:
>
>> I want a solution that involves the web page, NOT
the server.
>
> I agree, but my response here is not about rel-tag. It
uses rel-tag
> as an example in a larger issue regarding issue
rejection.
>
> In the month or so I've been on the discussion list,
the "rel-tag
> title" issue has been raised many times,
indicating a valid need
> for a less-than-ideal alternative. Many of the
stake-holders seem
> to have tagspace-enabled sites (Technorati, Flickr,
etc.) and,
> while that is the ideal situation, they also seem
defiant in their
> willingness to admit creating a tagspace is problematic
for many
> users. I tracked down what I believe to be the
documentation of the
> first time this issue was rejected.
>
> Quoted from: http://mi
croformats.org/wiki?title=rel-tag-
> issues&diff=4885&oldid=4881
>
> "Issue 3: It's not reasonable to restrict the
host's REST
> implementation according to this spec's rather limited
idea of a
> 'good' tag URL. The idea of tags as query parameters is
rejected
> without justification, for example. Query parameters
are a
> perfectly legitimate means of denoting state.'
REJECTED, IGNORES
> ESTABLISHED PRACTICE. Flickr and del.icio.us and other
tagging
> sites established the defacto standard of having the
tag term be
> denoted by the last segment in the URL and thus defined
what makes
> a 'good' tag URL. rel-tag has codified this good
practice."
>
> I was not on the list at the time, and therefore cannot
verify that
> this issue was not discussed openly, but I also cannot
find on the
> wiki the due process of issue rejection. Format
rejection is
> defined, but issue rejection seems arbitrary. The
closest thing I
> can find is "some issues are REJECTED for a number
of obvious
> reasons and others contain longer discussions" on
the Microformat
> Issues page. I am not implying the uf group step to the
> deliberation level of ISO or the W3C, but some issues
should not be
> noted as REJECTED by an individual, at least not
without fair
> consideration and voting. If this process exists, or if
there is a
> process for rejection APPEAL, it needs to be
documented. If it does
> not exist, it needs to be defined.
>
> For example, the previously noted rejection statement
seems
> opinionated to me. If for no other reason, the
frequency of this
> request demands that it receive more consideration and
deliberation.
Naturally we all have opinions, but I think we also share a
common
agreement to follow the microformats process, so if you want
to
pursue an issue either pre- or post-rejection, the process
is still
the best way to do this. In this case, the rejection
includes
examples of existing tag spaces which follow the established
standard
URL format. If someone wants to suggest that this standard
doesn't
reflect a clear (80/20) majority of real-world publishing,
collecting
counter-examples (sites that use tags with some other URL
format)
would do a lot to support that argument, and also provide a
good
basis for determining a solution if this is ever considered
a
legitimate issue. Make your case with real-world examples,
and I
think you'll find rejections come less readily.
But rejections will still come without a lot of
justification. More
generally, I think you might be missing a fundamental
principle of
microformats: they don't demand reasons for rejection as
other
processes often do. Much the opposite, microformats demand
reasons
for consideration. In the interest of stripping
microformats down to
the simplest semantic building blocks (largely the basis of
widespread adoption success), rejection is the default
response to
any additions. The process description even starts by
discouraging
more microformats:
http://microform
ats.org/wiki/process
I think everyone will agree that more documentation would be
good,
but I'd encourage you to better document *why* before asking
others
to better document *why not*. Again, bringing this back to
the rel-
tag example, anyone who thinks the de facto standard of tag
space
URLs is not reflected in the current rel-tag spec should
document
real-world examples to test that hypothesis.
Peace,
Scott
_______________________________________________
microformats-discuss mailing list
microformats-discuss microformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss
|
