On 11/25/06, coveloper <jon@...> wrote:
> I've been taking a rather small mental ice pick to the large iceberg
> that is xipf.

Hey Jon, thanks for posting here. This is a great metaphor to
describe the problem. Almost everything you do in this space opens up
a ton of questions.

> At first I was thinking this would be an XML format similar to xspf,
> or even rss. And in that mode of thinking, I sketched up something
> like this:
>
> http://www.covelop.org/xipf/xml_transport_layer/index.xipf.txt
>
> The idea is that something similar to this would serve as a Package
> Description Format, including all the valuable and commonly used
> information you see on Album/Song packaging.
>
> What's described here is only Album level. I had thought that maybe
> xspf could be used as a child node to describe Song data, since it has
> an order and is already a standard. BUT, xspf as far as I can tell,
> does not have enough song level data to satisfy common song production
> credits, like writer, publisher, recorded_by, mixed_by, etc. xipf
> will need a very descriptive set of song level tags.

True!

The problem is that definining metadata fields is a project all on its
own. For example, let's say you have a field for listing out
instrumentalists on a song, and you have a trombone player -- how do
you write "trombone"? Do you use the English longhand? The English
shorthand (tbn)? This isn't an impossible job, but it's not a trivial
one either.

Now, one approach you could take is to say that the instrument name is
a display decision better left up to the package creator, so you'd
have a construct like:

<instrumentalist instrument="'bone" player="Jack Teagarden" />

...but even that opens up enough of a can of worms with regard to
translations, so you shouldn't just take the first option that comes
to mind.

I don't mean to say that this is impossible; I'm explaining why we
didn't take it on with XSPF.

Speaking of the parts of the iceberg that are under water: the issue
of liner note ontologies is one of the major pieces of work to do. I
could easily imagine spending three months making a high-quality
extensible translatable scalable list of instrument names for use in
digital packaging.

> Lucas has mentioned the idea of a .zip package, allowing for folders
> and a basic application structure. I think I now understand why the
> .zip format is so appealing.
>
> An XML description alone can not be xipf, because it has no layout
> or aesthetic display logic built in. The integrity of any package
> requires an expected result by the author, when opened by the client.
> We can't just let the client app render artwork without author
> specified guidelines.

Well, I think that it's more productive to view this as an issue of
empowering packaging creators to do a good job. The client is going
to do whatever it's going to do, and that is often going to suck, but
it doesn't matter.

> xipf would be a self-contained application, possibly with included
> libraries for rendering client side. AJAX/JSON could play a huge part
> in making this a beautiful application, and call out to remote servers
> for updated content, like artist tour dates, chart positions, news,
> user comments/reviews, etc.

Sorry -- do you mean that packages are .exe's? Not sure that I get it.

> I see now that an XML description would be handy, especially as a
> template that the artist/label just fills in. That keeps node names
> consistent, and provides an ecosystem for GUI apps.

Yes, yes, absolutely. This frees the labels from have to create
technology, which is the wrong role for them. On the other hand, I
could see labels like Rhino excelling at packaging once they have the
template to fill in.

> I still haven't wrapped my head around how the actual audio file
> would/should be tied [or not] to the packaging, but maybe that's a
> solution for someone else more skilled with media to consider.
>
> Lucas' idea of audio files embedded in HTML is interesting,
> however I just can't get used to the idea of HTML as a media format.

Me neither. It's pretty bizarre. :)

The only thing it has going for it is that it doesn't require a new
client. Maybe.

> This seems like where RSS style enclosures would come in handy in the
> XML transport layer. You download the package, and it then downloads
> audio files [possibly authenticated or licensed] RSS style to your
> package. A package could contain a unique athorized key file,
> allowing a download server to fill your package with the audio files.

Ok, so the package is freely available, but the media file itself is
restricted? If I have that right, a thing I like about it is that the
security model is the same as it is now, meaning that there won't be a
struggle over DRM on the packages. When we have talked to label
people about XIPF, this has always come up.

Anyway, thanks for weighing in, and looking forward to seeing what you
come up with.

-Lucas