3%: price in credits
3%: performance artist
3%: p2p-based purchase
3%: video sample
3%: web-based purchase link
3%: creators
-- manu
--
Manu Sporny
President/CEO
Digital Bazaar, Inc.
http://blog.digitalbazaar.com/
___
microformats-new mailing
:
http://microformats.org/wiki/media-info-examples#Video
-- manu
--
Manu Sporny
Digital Bazaar, Inc.
http://blog.digitalbazaar.com/
___
microformats-new mailing list
microformats-new@microformats.org
http://microformats.org/mailman/listinfo/microformats
one is the better solution for describing file formats?
-- manu
--
Manu Sporny
President/CEO
Digital Bazaar, Inc.
http://blog.digitalbazaar.com/
___
microformats-new mailing list
microformats-new@microformats.org
http://microformats.org/mailman/listinfo
Charles, Scott,
Does the fact that we are having a discussion on file format instead of
somebody being able to point to a Microformats wiki page and state It's
been discussed before, and here's the link indicate that we need a new
page for exploratory discussion?
If so, I can create one and we
Has the concept of implicit collections and uF inheritance come up on
this discussion list yet? Here is the problem that we will be grappling
with in the next week or two:
Grouping collections of audio together is a common practice. The most
prominent examples are: music podcasts and audio
We need feedback on the hAudio Microformat proposal.
http://microformats.org/wiki/audio-info-proposal
All examples, formats and brainstorming can be found here:
http://microformats.org/wiki/audio-info-examples
http://microformats.org/wiki/audio-info-formats
Frances Berriman wrote:
As a brief aside, if there's a general uneasiness about a proposed
solution (in this case, the groupings) I think it's a good point to
slow down a bit and rework the problem until a happy resolution can be
found, rather than rushing to a draft regardless. I think it
Martin McEvoy wrote:
Manu first I would like to say that I understand what you are trying to
do with the . my example would be class=collection the parent or
group, class=collection.Track_1 is my child or item,
class=collection.Track_2 is another child or item, It simpler and
works but I
Frances Berriman wrote:
I like this though. Again, looking at this newly - why isn't audio
being used as a subclass of media? The above example using
collections could just as easily be talking about a collection of
photographs, for example. I saw a quick flash of a mention about
media
Frances Berriman wrote:
Frances Berriman wrote:
This may have been done and if so, does this research exist on the
wiki at the moment? If it's been tried, and it doesn't work, I think
I and others would benefit from seeing the attempts.
We already discussed this a month ago:
Scott Reynen wrote:
Can this be solved by extending an existing format?
Maybe... but every attempt at doing so has been shot down to date. Read
the previous threads. Please propose a solution if you think differently.
The last message in those threads begins with hAtom as a transport for
Scott Reynen wrote:
As the analysis shows - we need a solution that can do both sparse and
non-sparse grouping. All of the non-name-space-based solutions proposed
thus far do not support sparse grouping.
Can you point out some actual examples of what you're calling sparse?
Definition of
David Janes wrote:
However, your characterization of hAtom as having a syndication
background / being some sort of syndication format is wrong
I'm sure I am being dense... but I thought Atom was all about
syndication? Perhaps we have different definitions of what syndication
means?
S: (n)
Ben Wiley Sittler wrote:
actually i think that should be one of:
abbr class=duration
title=P210S (210 seconds, 8601) or
Ben,
Your suggestion to use the ISO-8601 duration format has received
favorable feedback. We should provide a very simple markup at first,
providing only the bare essentials
The newest proposal of hAudio (v0.3) is available:
http://microformats.org/wiki/audio-info-proposal
Here are the changes based on input from the community:
-
title - work-title
Fixed a typo on the page. There has been one
Manu Sporny wrote:
- The use of 'fn' instead of 'work-title'.
It has been proposed that 'fn' or 'n' be used instead of 'work-title',
or 'title'. What follows is an argument against using 'fn' and 'n' for
hAudio.
Assumptions:
- It is important that we choose the generic names that span all
Brian Suda wrote:
None of this applies to hAudio - and we don't want Microformat
implementors confusing how to use 'fn' in hAudio and how to use 'fn' in
hCard.
--- these are two very different things. This is a non-issue. hCard
parsers do onething, and you can defined Media parsers to do
Tantek Çelik wrote:
On 5/8/07 8:36 AM, Manu Sporny [EMAIL PROTECTED] wrote:
fn is short for 'full-name'
Not quite. In short, fn is short for formatted name.
and is grounded in the VCARD/hCard format.
Yes, and per http://www.ietf.org/rfc/rfc2426.txt section 3.1.1:
the formatted text
Scott's argument was the final nail in the 'work-title' coffin. Work
title has been changed to 'fn' and is reflected on the wiki:
http://microformats.org/wiki/audio-info-proposal#Schema
http://microformats.org/wiki/audio-info-proposal#Formatted_Name
-- manu
Andy Mabbett wrote:
I can foresee problems.
Suppose a publisher links to a third-party site, offering an audio track
as a free sample (or vice versa). Later, that latter site decides to
start charging for the track - how would the publisher know that their
site is no longer correct?
Guy Fraser wrote:
Many microforamts state that they are likely to be released under a
royalty free patent - it's *really* vital to note that from a legal
standpoint there are some absolute show-stopper problems with this:
1. Intent does not guarantee what will happen - intent can change over
Scott Reynen wrote:
On May 10, 2007, at 6:57 PM, Martin McEvoy wrote:
It would be nice if someone could say they get what I am trying to do or
that it doesn't make sense so comments and criticism are welcome.
http://weborganics.co.uk/haudio
I agree with most of Scott's feedback. In
After collecting even more grouping examples and performing analysis on
those examples, it is quite evident that we need to support ordered,
unordered, sparse and non-sparse grouping. There are several options
that have been gathered over the past month, listed on the
grouping-brainstorming page:
Martin, to start off - thanks for updating your hAudio examples page...
even though you have issues with the proposal. Personally, I feel that
the XHTML is much cleaner now and accomplishes all of the goals listed
in the grouping-examples page. However, it would be foolish to press
ahead if there
Martin McEvoy wrote:
On Wed, 2007-05-16 at 14:00 -0400, Manu Sporny wrote:
using brief, descriptive class names
hset is a brief descriptive class name, isn't it?
Yes hSet is descriptive
my trouble lies in what comes after, you are asking users to invent
their own class after that ie
Martin McEvoy wrote:
I know there is more mark up but it does use simple class names that
every one can understand
I agree, it does do the same thing. I'd prefer doing something like what
you're suggesting. The only problem that would need to be solved is how
we support sparse grouping with
Chris Griego wrote:
Before you start on a full-blown proposal, can you create a sample
page?
Martin McEvoy already has one set up based on a real-world example:
http://weborganics.co.uk/haudio
There is also the brainstorming page, look at Option #3:
Chris Griego wrote:
With my proposal for hSet:
h1span id=internal-event class=hset vcalendarInternal/span
and span id=with-client-event class=hset
vcalendarWith-Client/span Events/h1
ol
li class=with-client-event veventspan class=summaryFOO Sales
Pitch/span [...]/li
li
Colin Barrett wrote:
On May 22, 2007, at 1:35 PM, Manu Sporny wrote:
using a character that is requires escaping when writing CSS
rules etc.)
Why would we write CSS rules for hset?
For many content authors, one of the main advantages of having data in a
microformat is to easily style
We need more feedback from the community regarding hset. A small poll
has been posted on the various issues surrounding hset. If you can,
please note your preference as to how we handle the hset problem:
1. Please go to the following URL: http://www.advancedsurvey.com/
2. Enter the Survey Number
Below are the current results related to the hSet survey. If you can,
please note your preference as to how we handle the hset problem:
1. Please go to the following URL: http://www.advancedsurvey.com/
2. Enter the Survey Number under the Enter Survey # field.
The number is: 52427
Here are
James Craig wrote:
Although I'm in favor or simple, hierarchical classnames, I don't think
the main opposition to this has to do with its complexity, and if so,
the argument certainly shouldn't be whittled down to a multiple-choice
question that is this simple. It's leading. Perhaps the same
Brian Suda wrote:
--- firstly, microformats are not a how should we do this it is more
of a how are things already being done?
Option #2 is how it is already being done. The options were more about
if we wanted to generalize the scope of the hAudio Microformat. It was
to see if anybody had a
Martin McEvoy wrote:
Your use of audio-album could cause problems later in the semantic
meaning, iTunes has many celebrity playlists, which are not actually
ALBUMS, but are a collection of related songs. The term podcast seems
very 2005, in 4 years will we still use 'podcats' maybe, maybe not?
Brian Suda wrote:
I just think there was either, no interest in
developing the format, or too many what if we add this happened and
it never moved forward.
It tends to be more of the latter when it comes to this list :) - lots
of good ideas... in fact, too many to see clearly, sometimes. That
Joe Andrieu wrote:
We need examples of playlists to support your playlist
argument... which we don't have.
Sure we do. There are a bunch on the examples page,
including the FIQL service I mentioned in my email.
Are we looking at the same examples page?
Martin McEvoy wrote:
div class=haudio
h1 class=vcard
span class=contributor orgThe Beatles/span -
span class=fnThe White Album/span/h1
div class=haudio vcard
h2 class=fnDisc: 1/h2
ol
li class=soundBack in the U.S.S.R. - span
Scott Reynen wrote:
The alternative to the above that I thought you were going for was
something like this:
halbum
playlist/XOXO
haudio
haudio
haudio
haudio
That makes sense to me.
Ah crap... I seem to have caused confusion with my ramblings.
Joe Andrieu wrote:
It seems that halbum means we no longer requires this
grouping abstraction.
That is correct - but this has only come about in the last couple of
days. I usually wait for some sort of concensus before updating the wiki.
What is your definition for a playlist? I think we
Martin McEvoy wrote:
hmm problem here, what if our album has multiple content types not all
albums are just playable music yes?
I think what both Scott and Joe are referring to are audio albums. We
aren't talking about video albums or multimedia albums. We should
concentrate on solving the
Colin Barrett wrote:
On Jun 5, 2007, at 2:20 PM, Scott Reynen wrote:
The label haudio appears to be describing two distinct concepts here
(1: album information, 2: individual track information), which I find
confusing. That these two concepts share some properties, but that
doesn't make
Scott Reynen wrote:
On Jun 5, 2007, at 4:00 PM, Colin Barrett wrote:
A classical recording is a good example -- unlike popular music, the
tracks on the album are often merely segments of a larger whole, f.e.
Beethoven's Fifth is comprised of four movements. All of the same
information that
Brian Suda wrote:
--- now we are spiraling back to ideas of what people WANT rather
than model what is being published.
I agree - we should keep our focus on solving demonstrated needs as
outlined by the audio-info-examples exploratory discussion. Right now,
we are talking about audio albums.
Joe Andrieu wrote:
Manu Sporny wrote:
Brian Suda wrote:
--- now we are spiraling back to ideas of what people WANT rather
than model what is being published.
I agree - we should keep our focus on solving demonstrated
needs as outlined by the audio-info-examples exploratory
discussion
Scott Reynen wrote:
halbum is the grouping Microformat for audio albums specifically - it
can aggregate a number of haudio recordings together.
halbum is the grouping of albums? I'm guessing this is a
miscommunication, as I've seen no previous discussion of groups of
albums. Please
Scott Reynen wrote:
Nobody seems to have raised any
issues related to existing elements in the haudio draft in several weeks.
I don't know how you can possibly think that. Multiple people have
suggested changing the wiki entry in just the last few days, and you've
said you don't think it
Joe Andrieu wrote:
There seemed to be partial agreement that hAudio
means the individual audio recording, that being
the simplest case to solve, although I agree with
the contradiction in the above problem statements.
The answer for multiple audio recordings on a page is to
have multiple
Derrick Lyndon Pallas wrote:
Actually, I can probably be of help here, having written the Alexa Image
Search indexer. While I can't divulge too much about what goes into
building the index, I'll see if I can find some time to take a look at
the usage of img/@alt inside hcard/fn some time this
Manu Sporny wrote:
As Scott has pointed out, the only way to know this is to start
gathering real data. I am in the process of writing an image crawler
(which will hopefully be done by tonight) to gather these statistics.
The first run of the img tag analysis has been completed, here
Andy Mabbett wrote:
In message [EMAIL PROTECTED], Manu Sporny
[EMAIL PROTECTED] writes
The percentages below are the percentages of img tags that contained
non-empty attributes:
src:99%
height: 66%
width: 66%
alt:41%
title: 5%
id: 4%
In general, only 41% of 'img
I'm starting a new thread as the *img alt content* discussion seems to
be getting unfocused. Please familiarize yourself with the following
thread, as this discussion is a more focused continuation of it:
http://microformats.org/discuss/mail/microformats-new/2007-July/000590.html
All of the
Regine Heidorn wrote:
Just a short thought, maybe it doesn't make sense.
What about using hReview for all kind of media with a subcategory hMedia
and a specification of the media like audio, movie, website etc.?
I mean: hAudio anyway is related to hReview, which is logical. So why
not
Storset, Leif wrote:
Manu Sporny wrote:
I'm assuming that Leif will take lead on this and post the first set
of examples (let me know if this is not the case, Leif).
I have now sent all my collected samples to Rob Manson for upload.
The receipt-examples collection process raises
Brian, you have made some very valid points, I'm not disputing most of
what you have said. I feel that this discussion is getting a bit off-track.
From your various e-mails, you seem to be making the following points
(I'm paraphrasing, there are nuances, but I'm attempting to summarize):
1. We
The hAudio issues page has been updated with the following:
* Redundant property issues
* Graphic buttons and 'rel-sample', 'rel-enclosure', and 'rel-payment
Please take a look at the page if you were involved in the discussions
on hAudio. Make additions to the page if you have any outstanding
The full issue description can be found on the audio-info-issues page:
http://microformats.org/wiki/audio-info-issues#image-summary_Property
hAudio ISSUE #1:
image-summary - This is a small graphic image that summarizes the audio
piece. There are several other formats that already use the PHOTO
Brian Suda wrote:
If you look at the wiki page which lists our classes,
http://microformats.org/wiki/classes
you will see that we have several ways of specifying a date
hCard uses REV, which is the REVISION date
hCalendar uses LAST-MODIFIED, the time the calendar was last changes
hAtom uses
Brian Suda wrote:
On 8/6/07, Manu Sporny [EMAIL PROTECTED] wrote:
The new pages can be found here... they are rough, but should outline
what we're planning on discussing. hAlbum borrows very heavily from hAudio:
--- with the exception of TRACKS an Album has all the identical
properties
Scott Reynen wrote:
If we can't deliver on that as a community - they won't have much
interest in implementing Microformats in Songbird.
We *can* deliver on that, but that doesn't mean we *should*. Support by
any specific tool should always be a lower priority than covering what
people are
Tantek Çelik wrote:
I agree it should use the ISO date-time pattern every other date
format is using.
So, we've got 3 votes for PUBLISHED using date-time pattern, none
opposed. I'd like some others to weigh in before we resolve this. A
simple AGREE/+1 would suffice, or DISAGREE with logical
Martin McEvoy wrote:
Am I correct in thinking that the proposed hAlbum track Property
http://microformats.org/wiki/audio-album-proposal#Track
Is redundant as hAudio is a track?
That's a question we've been wrestling with for some time, Martin.
Here's why I'm in support of TRACK:
- TRACK
Scott Reynen wrote:
On Aug 16, 2007, at 9:01 PM, Clay Newton wrote:
There is significant overlap in the data elements for each of these
records. It would seem to me that one microformat could support the
sum of these phases.
Thoughts?
Start simple.
I agree... we shouldn't try to merge
hAudio ISSUE #4: open issue!
http://microformats.org/wiki/audio-info-issues#Problem:_Display_properties_of_rel-patterns
The following markup summarizes this problem:
a rel=purchase href=/buy/song/3742827384
title=Buy The Song
img src=/images/buy_song.png alt=Buy Song Image /
/a
Introduction
Microformalyze speeds the Microformat examples collection and analysis
process.
One of the first steps of the Microformat creation process is example
gathering and website analysis. This step requires the Microformat
creators to analyze tens if not hundreds of websites.
Here's some weekend reading for those that are interested. :)
We've documented our experience with the Microformats community, the W3C
RDFa task force, the Microformat creation process, and the current
status of hAudio in a case study:
http://wiki.digitalbazaar.com/en/haudio-case-study
I'd be
Tantek Çelik wrote:
While I may not necessarily agree with all the issues/points you
raise, I want to thank you for your frank feedback, and I'm hoping
that open documentation and resolution of such issues itself addresses
at least some of your issues (if not most or all).
This is why we
Martin McEvoy wrote:
On Sat, 2007-09-08 at 16:20 -0400, Manu Sporny wrote:
Most of hAlbum's properties overlap with hAudio. In fact, the only two
properties that do not overlap with hAudio are 'album-title' and 'track'.
Does hAudio then describe a collection of hAudio's ?
If we make
Andy Mabbett wrote:
# If both 'album-title' and 'audio-title' is specified, then the
hAudio is a song that is part of an album.
I think those names are confusing; they should be:
albunm-title + track-title
or simply:
album + track
Of the two, I'd
The video-info exploratory discussion has been created on the wiki.
There are currently 22 examples that have been analyzed so far:
http://microformats.org/wiki/video-info-examples
Here are the property leaders with the current set of data:
# title: 95.65%
# comments: 86.96%
# image summary:
Mary Hodder wrote:
Is the video microformat use case one that is about video hosters or
about what users do, or both?
Both... we're going for general video metadata markup. :)
At Dabble, as we take in metadata from both sources, we see users and
hosters publishing titles, thumbnail (users
Frances Berriman wrote:
I imagine it will be valuable as a primer for those interested in
creating some type of microformat (or wondering if microformats are
indeed for them) and maybe how the process works.
Good, as that is one of the goals of the document :)
Talking of... I note that one
This is a partial continuation of the following thread:
http://microformats.org/discuss/mail/microformats-new/2007-September/000823.html
I wanted to make some clarifications about the video-info-examples page
before we go down a rabbit hole. Or rather... this is an attempt not to
go down a
Frances Berriman wrote:
On 12/09/2007, Manu Sporny [EMAIL PROTECTED] wrote:
I think we should call it what it is:
The Accepted Limitations of Microformats
Yeah, that would work.
I have created the wiki page, everyone please feel free to note issues
and add other sections on the page:
http
Michael Smethurst wrote:
Can I suggest release instead of album? It just captures albums, singles,
eps better...
Your idea has been noted on the wiki, Michael:
http://microformats.org/wiki/audio-info-issues#album-title_Property
I'm somewhat opposed to changing 'release' to 'album-title' at
Mary Hodder wrote:
Appreciate the clarifications. Very helpful. I will get one of my
engineers to run some queries, to see what percentages we have across 27
mil videos and then post them here and in the wiki.
Make sure to ask them to not duplicate data sources. Don't analyze 400
URLs from
Martin McEvoy wrote:
I vote we use something more generic and call audio-title, album-title
or in fact any media related title just media-title, you can re-use it
for albums, podcasts, toplists, downloads, charts, video, images.
Martin,
If we do that, we will lose the ability to differentiate
Scott Reynen wrote:
If we do that, we will lose the ability to differentiate between an
album, podcast, toplist, download, and chart.
Can you explain a bit more what exactly we gain with that ability, in
terms of practical capabilities?
Here is the premise:
It is important to be able to
Martin McEvoy wrote:
...listening to
div class=haudio
div class=item
span class=media-titleMay the Rain/span
/div
found on span class=haudio-titlePaper Tigers/span
/div
by...
*Item* works here as a root class on its own and is used as a semantic
finger pointing out the
Julian Stahnke wrote:
I’d like to point out that the currently proposed spec
(http://microformats.org/wiki/audio-info-proposal#Complete_Album_Examplet)
of nesting an haudio element in a track element to mark up albums is
incompatible with using tables for the track listings. In a table, you
Scott Reynen wrote:
The only reason I mention that order is important in the attribute list
is because we might have 'track hvideo' in the future for DVD chapters,
television episodes or other track-like items.
I'm not sure l understand that reason. If you're saying that a
class=track
Chris Newell wrote:
Note that I said or whatever is [the] standard for representing
square-metres.
I'm not sure there is a standard for representing the superscripts
used within SI units using plain text.
We may have to specify something.
These are all good discussions, but I'm afraid
Chris Newell wrote:
The Strawman includes the following new concepts:
- The proposal only uses abbr to avoid the but the parsers are going to
be so complicated! argument. Let's focus on what we can represent
using abbr - what we can support in span will naturally come out
of that
Martin McEvoy wrote:
On Fri, 2007-10-05 at 09:44 +0100, Julian Stahnke wrote:
So this simpler proposal makes perfect sense to me.
at least someone on the list Is starting to make sense.
Criticize the ideas, not the people, please. :)
I have been wrestling with the current proposal of
Julian Stahnke wrote:
If you want to push your proposal above, you will have to make the
following arguments:
1. Why Ambiguity is not an issue for TRACK.
2. Why we should introduce a new property called TRACK-TITLE.
3. Why we should require CONTRIBUTOR to be marked up via a VCARD.
About
Most of the day today was spent re-analyzing all of the music service
and podcast websites in audio-info-examples using Microformalyze. The
raw analysis data is available here:
http://microformats.org/wiki/audio-info-examples#Microformalyze_Data_Files
The analysis is available here:
There are several hAudio issues that seem to have been resolved in the
past several weeks that should be marked as Resolved.
PROPOSAL: We close the following issues as each problem seems to have
been addressed.
hAudio ISSUE #1: image-summary Property is redundant
- PHOTO has been used
Julian Stahnke wrote:
Martin McEvoy wrote:
I think the proposition should simply say
* hAudio MAY have zero or more tracks
* Track titles MAY be defined by using the class name
*audio-title* it is recommended that a hAudio track SHOULD have
an audio-title *
One of the last remaining (and most pedantic) issues for hAudio is the
naming of the audio-title and album-title properties. This includes the
following issues (we could close them all if we can finally decide on
these two names):
hAudio ISSUE #2: audio-title Property
Scott Reynen wrote:
On Oct 12, 2007, at 2:01 PM, Manu Sporny wrote:
If we were to use FN, it would be impossible to distinguish between an
album (an concept that can contain more than one hAudio) and a
song/speech (an individual hAudio).
I don't think that's true. hCard uses FN for two
Julian Stahnke wrote:
A container for another hAudio item. Used in conjunction with
album-title.
[snip]
* hAudio MAY have one or more tracks, but MUST have album-title
defined. If album-title is not defined, track cannot be defined.
Sorry to be jumping in late here, but I'm
The problem:
We need some sort of container to hold track/song information in an
hAudio album. The contents of this container will be another hAudio
chunk or text (which will be the FN of an hAudio object).
There are two proposals that are on the table right now. The end result
and semantics for
Justin Maxwell wrote:
and i thought i was helping define a microformat, not practicing my
skill in public debate. so, we're even. :)
You must be new here. This is the New Microformats Community. We don't
actually create Microformats, instead we endlessly debate the meaning of
words and their
Michael Smethurst wrote:
In these cases track would be plain wrong
Also nested items/haudios would allow you to mark up classical works/opera
(as opposed to perfomances/recordings). In the case of an opera:
Haudio - opera
haudio - act
haudio - scene
haudio - aria
Michael Smethurst wrote:
3 quick questions:
1. how would this work for a tracklist for a radio/tv programme. Like this?:
span class=haudio
span class=fnNagasaki Nightmare/span
span class=albumBest Before 1984/span
span class=contributorCrass/span
/span
span class=haudio
span
Ben Ward wrote:
On 15 Oct 2007, at 10:44, Julian Stahnke wrote:
album-title is NOT mandatory. It is only mandatory when you're listing
one or more TRACKs.
Tracks can be grouped by more than just albums. I'd say album-title
should
never be mandatory
Playlists or charts come to my mind, for
Scott Reynen wrote:
Not wanting to add to the confusion but would it not be possible to have
infinitely nested haudios with neither item or track and use mfo when the
markup enforces containment that you don't want to be reflected in the
model?
As much as I'd like to move forward a general
Scott Reynen wrote:
The complete representation of the expression for duration in the
alternative format is as follows:
Basic format: PMMDDThhmmss or PDDDThhmmss
Extended format: P-MM-DDThh:mm:ss or P-DDDThh:mm:ss
That section also includes several references to other
Martin McEvoy wrote:
The first thing I spotted was that someone seems to have spammed the
word track 100's of times all over our model examples and results,
making them as far as i can see unusable, Vandalized almost
Martin, I wish you had said something before going and doing all that
hard
Martin McEvoy wrote:
Im truthfully appaled that Our Model that we found all our debates on Is
wildly inaccurate?
It is not. :)
I stand by the examples, the analysis and the research performed to date
by myself and several others (including you, Martin). I also challenge
you to prove its wild
This e-mail is a proposed resolution to the hAudio ITEM/TRACK debate.
The list has seemed to have calmed down a bit, so I have gone back
through and attempted to address each post's concerns about using either
ITEM or TRACK. The proposed resolution is a mix of Martin, Scott, Andy,
Julian, Michael,
1 - 100 of 171 matches
Mail list logo
