On Oct 24, 2005, at 2:59 PM, A. Pagaltzis wrote:
* Antone Roundy <[EMAIL PROTECTED]> [2005-10-24 22:35]:
Interesting. Filling an attribute with a list of URIs doesn't
really appeal to me though. How about this:
<link rel="enclosure" type="audio/mpeg" href="http://example.com/
file.mp3" xml:id="x-file">
<altlink:mirror href="http://www2.example.com/file.mp3"; />
<altlink:mirror href="http://www3.example.com/file.mp3"; />
</link>
It’s a lot more verbose and you have to fiddle with nesting.
What do you get in return? “It looks more XMLish”?
1) Easier parsing, as James said, since your XML parsing library is
going to give you the data with the URI's already split apart.
2) You can break lines between elements, but you can't inside an
attribute, so it's better for display for humans.
I think XMLishness leans this direction for good reason.
Sounds good, but you may have noticed above that I used a
prefix not specific to enclosures--there's no reason to tie
this all to one particular type of link (nor to make it look
as if it were tied to one specific link type). So the other
link might, for example, be:
I don’t know if striving for generality in this fashion without
a practical need is worthwhile. It smells of architecture
astronautics for a reason I can’t particularly pinpoint. So maybe
my instinct is wrong.
The way I see it, striving for specificity without a practical need
isn't worthwhile. Unless generalizing risks leading to some sort of
problem, why do it? I see no potential problems.
What if someday somebody does come up with a non-enclosure use for
this (which hardly seems far-fetched to me--enclosures aren't the
only things that get mirrored or exist in multiple formats)? They'll
have to define a new mechanism for it which is either going to be
identical except for element names, or they're going to invent
another way to do the same thing. Either way, the pain of supporting
both is completely unnecessary unless there's potential for
generality causing problems.
