Manu
I had a thought about collections I would like to share with you,
If we look at collections in the most basic way we can this may give us
an Idea of what is meant by collection?
So... I look at my pile of books and think that these books need
organizing in some way they are no good scattered
On Tue, 2007-05-01 at 20:57 -0500, Scott Reynen wrote:
On May 1, 2007, at 7:49 PM, Manu Sporny wrote:
acquire. optional. using rel-design-pattern with acquire as the
mf-rel-value.
--- there is aleady the 'enclosure' used for ATOM and Podcasts
Again, Martin is correct - enclosure is
On May 2, 2007, at 6:05 AM, David Janes wrote:
While (very) sympathetic to Andy's point about this, we're getting to
the danger point of semantically forking rel-tag. I suspect you will
get strong pushback on this one, because the current approach is to
use rel-tag for this, and if that needs
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
On 5/2/07, Manu Sporny [EMAIL PROTECTED] wrote:
I'm not opposed to using a different separator. Although, I don't think
the separator is what most are concerned about on the list. Most of the
concern is coming from the following two camps:
* Are sparse groups really a problem?! [1]
* Names
Frances Berriman wrote:
Martin McEvoy wrote:
li
span class=item
span class=work-title
a href=http://link-to-download/1;
rel=acquireTrack_1/a
/span
/span
/li
It'd be a bit lighter with the item on each li in this example,
eh? :)
What if you
In message
[EMAIL PROTECTED], David
Janes [EMAIL PROTECTED] writes
hAudio (haudio)
- title. required. text.
title is already taken to mean something else, so TITLE is not an
option. hCard uses TITLE for job-title. I would suggest FN instead.
We could use FN,
but 'work-title' is far
On 02/05/07, Brian Suda [EMAIL PROTECTED] wrote:
Can this problem be solved without inventing a new format?
Can this be solved by extending an existing format?
Can this be solved by creating small building block formats that can
be reused in other formats?
Can this be solved only be creating a
In message [EMAIL PROTECTED],
David Janes [EMAIL PROTECTED] writes
On 5/2/07, Andy Mabbett [EMAIL PROTECTED] wrote:
In message
[EMAIL PROTECTED], David
Janes [EMAIL PROTECTED] writes
If you mean what most people do by title, then FN is the correct
thing to use.
How does that square with
From: Manu Sporny [EMAIL PROTECTED]
Scott Reynen wrote:
If nothing else is changing here, I think rel values should be nouns,
not verbs. I think all of the existing rel values in microformats fit
this pattern, and it's good to be able to say this page and that page
have a relationship of
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
On May 2, 2007, at 5:14 PM, Manu Sporny wrote:
Note that the song should be grouped with the podcast AND the album.
That understanding is clear from viewing the page:
http://www.coverville.com/archives/2007/04/coverville_313.html
The podcast can already use hAtom. Here's how we could do
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
Manu Sporny wrote:
We need feedback on the hAudio Microformat proposal.
http://microformats.org/wiki/audio-info-proposal
As an accessibility note, the following links use the same link text
to different URLs. See the following quote noting, Link text should
be meaningful enough to make
On Tue, 2007-05-01 at 17:37 +, Brian Suda wrote:
On 5/1/07, Manu Sporny [EMAIL PROTECTED] wrote:
We need feedback on the hAudio Microformat proposal.
hAudio (haudio)
- title. required. text.
title is already taken to mean something else, so TITLE is not an
option. hCard uses
In message
[EMAIL PROTECTED], Brian
Suda [EMAIL PROTECTED] writes
hAudio (haudio)
- title. required. text.
title is already taken to mean something else, so TITLE is not an
option. hCard uses TITLE for job-title. I would suggest FN instead.
or something like audio-title; leaving room for
On 5/1/07, Andy Mabbett [EMAIL PROTECTED] wrote:
In message
[EMAIL PROTECTED], Brian
Suda [EMAIL PROTECTED] writes
[snip]
--- genre sounds alot like TAGS or CATEGORIES to me? we should recycle
terms in existing microformats
Not all publishers wish to mark up such labels as links.
you can
Manu Sporny wrote:
James Craig wrote:
Manu Sporny wrote:
We need feedback on the hAudio Microformat proposal.
http://microformats.org/wiki/audio-info-proposal
As an accessibility note, the following links use the same link
text to
different URLs.
That text was taken directly from the
19 matches
Mail list logo
