Am Donnerstag, 14. Dezember 2006 20:41 schrieb Andy Mabbett:
What if ...
many what if :)
Well, quite. And there's more than one.
Sure. And why not. And there are already publications out there which are
quite old, published long before the term microformats was invented, and
which
Scott Reynen wrote:
This mirrors how natural language works.
Until there is some need for clarification, we assume everyone knows
what we mean. Then there is a need for clarification, we clarify.
No one goes around defining every word before they use it,
and I don't think we can
In message [EMAIL PROTECTED],
Elias Torres [EMAIL PROTECTED] writes
2) Rather than having a profile for each uF (and, presumably,
near-duplicate profiles for nested uFs such as geo or adr in hCard?) why
not have one over-arching profile for all microformats?
Funny you say that since
In message [EMAIL PROTECTED], Siegfried Gipp
[EMAIL PROTECTED] writes
Take f.ex. one of my pages: http://www.rorkvell.de/tech/dc This is a
page which aims to combine the ideas of microformats with the Dublin
Core vocabulary. This is by definition _no_ microformat, since this did
not go through
On 12/14/06, Andy Mabbett [EMAIL PROTECTED] wrote:
In message
[EMAIL PROTECTED], Elias
Torres [EMAIL PROTECTED] writes
2) Rather than having a profile for each uF (and, presumably,
near-duplicate profiles for nested uFs such as geo or adr in hCard?) why
not have one over-arching profile for
Am Dienstag, 12. Dezember 2006 20:16 schrieb Tantek Çelik:
microformats is the specific brand (your term) of semantic (X)HTML that
follows the microformats principles and process.
You could say that RDFa is another brand of semantic (X)HTML that follows
its own principles.
Just to be
On Dec 13, 2006, at 1:40 AM, Joe Andrieu wrote:
Making people use them is not the same as clarifying in a spec what
should be done, must be done, and what is optional. If we are
specifying that parsers can ignore non-profiled semantic HTML that
looks
like microformats, we are essentially
In message [EMAIL PROTECTED], Joe Andrieu
[EMAIL PROTECTED] writes
Which means that URI profiles are /effectively/ required if you want to
be assured that standards-compliant parsers will pick them up your
microformats.
Yea! I think profiles are great. So, why not formalize the
requirement?
Mike Schinkel wrote:
If it is not a scarce resource, please tell me what would happen if I
decided to start marking up documents, as an example, using the class
directory and license, for purposes other than rel-directory and
re-license? How could my markup and those Microformats co-exist in
On 12/11/06 10:20 PM, Håkon Wium Lie [EMAIL PROTECTED] wrote:
Thanks for chiming in Håkon - your opinion is always appreciated.
Also sprach Mike Schinkel:
I'm not quite sure what you mean here. Is there a difference
between lowercase microformats and uppercase microformats?
lowercase
Mike, Ben, a gentle reminder, please update the subject line when the
subject changes :)
On 12/11/06 8:45 PM, Benjamin West [EMAIL PROTECTED] wrote:
On 12/11/06, Mike Schinkel [EMAIL PROTECTED] wrote:
Benjamin West wrote:
I'm not quite sure what you mean here. Is there a difference
between
On 12/12/06 10:40 AM, S. Sriram [EMAIL PROTECTED] wrote:
What ufs(.org) has done is bring about a new category i.e. microformats
into the collective mindspace, similar to Palm computers.
Without a brand name to go with the category microformats,
What will happen, is the Darwinian like
Am Dienstag, 12. Dezember 2006 17:17 schrieb Tantek Çelik:
lowercase microformats = unofficial semantic markup embedded in HTML
uppercase microformats = Official Microformat
There is no such thing as lowercase microformats. I think that came from the
socalled lowercase semantic web vs. the
In message [EMAIL PROTECTED], Tantek Çelik
[EMAIL PROTECTED] writes
A microformat is such because it is a use of semantic class names,
etc. that IN PARTICULAR:
1. Are designed according to microformat principles [1]
2. Follow the microformats process [2]
Of all the definitions of microformats
On Dec 12, 2006, at 1:38 PM, Joe Andrieu wrote:
brian suda wrote
It is possible for me to start creating a CSS style called
'vcard', but a parser would know that this is a style and not
semantics because of the lack of a profile URI. Eventually,
as microformats become more popular, the
Benjamin West wrote:
I'm not quite sure what you mean here. Is there a difference
between lowercase microformats and uppercase microformats?
lowercase microformats = unofficial semantic markup embedded in HTML
uppercase microformats = Official Microformat
--
-Mike Schinkel
Bruce D'Arcus wrote:
In a world in which one CAN consider adding alternative
attributes (HTML 5, etc.), it makes no sense to me one would
simply say no.
[I'm cross posting to uf-discuss and whatwg because Bruce's comment was made
on uf-discuss but I've made the same point on WHATWG.]
Bruce,
On 12/11/06, Mike Schinkel [EMAIL PROTECTED] wrote:
Benjamin West wrote:
I'm not quite sure what you mean here. Is there a difference
between lowercase microformats and uppercase microformats?
lowercase microformats = unofficial semantic markup embedded in HTML
uppercase microformats =
On Dec 11, 2006, at 11:43 PM, [EMAIL PROTECTED] wrote:
Brian Suda wrote:
Microformats are meant as building blocks and they should be
able to be using independantly and together...
If that is true, how can it be achieved without a disambiguation
conventions
to keep official Microformats
Benjamin West wrote:
That's the first I've heard of this usage. I think what I'm
hearing (and agree with) is a need for a term that describes
the product of semantic markup techniques in a general way.
It's my usage. It seemed natural as I've heard the term uppercase/lowercase
used to
Also sprach Mike Schinkel:
I'm not quite sure what you mean here. Is there a difference
between lowercase microformats and uppercase microformats?
lowercase microformats = unofficial semantic markup embedded in HTML
uppercase microformats = Official Microformat
This makes sense to
Forgive me if I have missed something, but could a parser not
understand multiple formats if the HTML used was also meaningful? For
example a blocklevel element (say a p) could contain some content
that was marked up with one microformat, and another blocklevel
element could contain content
In message
[EMAIL PROTECTED], Tim
Hodson [EMAIL PROTECTED] writes
A parser could easily identify child relationships within
the HTML and extrapolate.
Granted this wouldn't be so easy if two microformats were muddled
together on the same page.
AIUI the concerns are about using the same
On 09/12/06, Andy Mabbett [EMAIL PROTECTED] wrote:
div class=citation
span class=title
Running an ISP for Idiots
/span
div class=author
div class=vcard
span class=title
Internet Expert [1]
/span
In message
[EMAIL PROTECTED], David
Janes [EMAIL PROTECTED] writes
My recent thinking has been that the following rules may work:
An outer microformat should
- never look for attributes inside nested microformats (particularly
hCard, hCalendar, hAtom and xFolk)
You immediately hit problems with
On 12/9/06, David Janes [EMAIL PROTECTED] wrote:
My recent thinking has been that the following rules may work:
An outer microformat should
- never look for attributes inside nested microformats (particularly
hCard, hCalendar, hAtom and xFolk)
--- i would also disagree with this because then
On 12/9/06, Brian Suda [EMAIL PROTECTED] wrote:
On 12/9/06, David Janes [EMAIL PROTECTED] wrote:
My recent thinking has been that the following rules may work:
An outer microformat should
- never look for attributes inside nested microformats (particularly
hCard, hCalendar, hAtom and xFolk)
On 12/9/06, David Janes [EMAIL PROTECTED] wrote:
How would someone marking up a hCalendar with a hCard make the
location empty under those rules? The hCard is part of the hCalendar,
both as part of the spec [1] and implicitly because it's there.
You wrote earlier:
An outer microformat should
-
- never look for attributes inside BLOCKQUOTE or Q
Why not?
Because their definitions in the HTML spec [1] say that these are for
pulling in data from elsewhere. From this one concludes that it's
likely that this data is not necessarily going to be marked up in a
way consistent with the
On 12/9/06, Brian Suda [EMAIL PROTECTED] wrote:
i still think/feel that excluding embeded microformats inside other
microformats is a bad idea. The whole point of NOT having namespaces
is that the property values that we put into class/rel/rev have the
same consistent meaning across all formats
On 12/9/06, David Janes [EMAIL PROTECTED] wrote:
On 12/9/06, Brian Suda [EMAIL PROTECTED] wrote:
[snip]
We're not talking about the same thing but I think the case you're
making here is pretty strong.
The issue that I've been trying to solve in my mind (and I'm sure
we're all on the same
Thanks Elias for weighing in, i was getting abit worried that people
might have been putting words in your mouth, it is glad to know you
are on the list to clear-up any potential confusions.
-brian
On 12/9/06, Elias Torres [EMAIL PROTECTED] wrote:
On 12/9/06, David Janes [EMAIL PROTECTED]
On Dec 9, 2006, at 10:45 AM, Elias Torres wrote:
However, more importantly, I need to find an
important enough instance of the so-called problem that needs us to
resolve the general microformat(s) case instead of hoping that if we
build it, they will come.
Exactly. That's my primary concern
In message [EMAIL PROTECTED], Tantek Çelik
[EMAIL PROTECTED] writes
I am ending this thread of 50 messages now
That's interesting - with what authority do you declare end of thread.
Isn't this supposed to be a community, and isn't that or the community
to do?
If there is an autocracy (or some
On 12/9/06 12:11 PM, Andy Mabbett [EMAIL PROTECTED] wrote:
In message [EMAIL PROTECTED], Tantek Çelik
[EMAIL PROTECTED] writes
I am ending this thread of 50 messages now
That's interesting - with what authority do you declare end of thread.
Isn't this supposed to be a community, and
In message [EMAIL PROTECTED], Tantek Çelik
[EMAIL PROTECTED] writes
I am ending this thread of 50 messages now
That's interesting - with what authority do you declare end of thread.
Isn't this supposed to be a community, and isn't that or the community
to do?
If there is an autocracy (or
In message [EMAIL PROTECTED], Tantek Çelik
[EMAIL PROTECTED] writes
1. Parsing is OFF-TOPIC for microformats-discuss.
Furthermore, your assertion is not supported by:
http://microformats.org/wiki/mailing-lists
A mailing list for general discussion of microformats
nor:
On 12/7/06, Ryan King [EMAIL PROTECTED] wrote:
...
Also, I'm not sure how 'people not getting their pet properties' is a
problem specific to microformats.
True. It doesn't mean it has to repeat the same mistake though. I
would certainly hope the HTML 5 effort would be open minded about
On Dec 8, 2006, at 4:04 AM, Bruce D'Arcus wrote:
Let's review:
Microformts are a clever set of conventions to reuse existing HTML
attributes to encode some sort of structured meaning.
However, using title to encode machine-readable content is pretty
much a hack. Title, after all, is really for
On 12/8/06, Dr. Ernie Prabhakar [EMAIL PROTECTED] wrote:
On Dec 8, 2006, at 4:04 AM, Bruce D'Arcus wrote:
Likewise, using class to indicate both properties and, um, class, is
also a hack.
I think that's probably where we part company. I suspect most of us
here consider the use of HTML
Hi Bruce,
My point, Ernie, is there's no obvious way to map it onto a model. I
Um, maybe I'm not quite understanding what you mean by model. Are
you saying that there's no way to create a generic parser that
transforms the microformatted data into a normalized form?
What you may not
Ryan King wrote:
How can I disambiguate when two Microformats collide?
Let me give a concrete example (one I will be working
on in the future):
First profile wins. This had previously been clarified in
HTML5, until Hixie decided to remove the profile attribute
from HTML5.
Please
Mike Schinkel wrote:
The core problem is no strategies have been adopted to avoid naming
collisions, and to avoid having the whole concept self destruct from
it's
own weight of complexity. People who want to contribute but can't
because
the centralized Microformat community is not interested
On Dec 6, 2006, at 5:45 AM, Bruce D'Arcus wrote:
On 12/5/06, Scott Reynen [EMAIL PROTECTED] wrote:
...
In HTML or JSON, new formats need new parsers, which must be written
by someone.
Exactly. The point is if you have a generic model you have a
generic parser.
Elias is coming from an
S. Sriram wrote:
This is not a scarce resource, people can
(and are) naming classes as they choose.
Any constraint happens at the parsing stage,
since microformat-aware parsers look for
specific class names etc. (see below)
If it is not a scarce resource, please tell me what would happen
On 12/7/06, Ryan King [EMAIL PROTECTED] wrote:
...
The RDF dream of having a generic parser and model has yet to win on
the open web. I'm more than happy to let the market decide whether
it's more value to have formats that are easy to publish, or those
that are easy to parse (I'm sure you can
On Dec 7, 2006, at 12:29 PM, Bruce D'Arcus wrote:
On 12/7/06, Ryan King [EMAIL PROTECTED] wrote:
...
The RDF dream of having a generic parser and model has yet to win on
the open web. I'm more than happy to let the market decide whether
it's more value to have formats that are easy to
From: Ryan King [EMAIL PROTECTED]
On Dec 5, 2006, at 8:48 AM, S. Sriram wrote:
From: Mike Schinkel [EMAIL PROTECTED]
http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2006-
December/00
8462.html
I wonder if his issues can be addressed?
How about a distributed parser-discovery
From: Mike Schinkel [EMAIL PROTECTED]
S. Sriram wrote:
This is not a scarce resource, people can
(and are) naming classes as they choose.
Any constraint happens at the parsing stage,
since microformat-aware parsers look for
specific class names etc. (see below)
If it is not a scarce resource,
On Dec 7, 2006, at 2:28 PM, Mike Schinkel wrote:
If it is not a scarce resource, please tell me what would happen if I
decided to start marking up documents, as an example, using the class
directory and license, for purposes other than rel-directory and
re-license?
The classes wouldn't cause
--- these values are not reserved across all of HTML. We
have a mechanism to prevent this, it is called Profile URIs,
if a parser comes across class=vcard then the best way to
determine if this is a random CSS Style or a semantic value
is to see if there is a Profile URI that matched the
S. Sriram wrote:
They would simply co-exist. Period
My only response to your comments is that I strongly disagree with you, but
as you appears you have a similar conviction it would be a waste of time to
debate it further.
-Mike Schinkel
http://www.mikeschinkel.com/blogs/
On 12/5/06, Scott Reynen [EMAIL PROTECTED] wrote:
...
In HTML or JSON, new formats need new parsers, which must be written
by someone.
Exactly. The point is if you have a generic model you have a generic parser.
Elias is coming from an RDF background, and microformats
simply aren't RDF,
From: Bruce D'Arcus [EMAIL PROTECTED]
The issue isn't really microformats vs. RDF (except as RDF provides a
model), but microformats vs. RDFa.
[snip]
So while it might be comforting to dismiss RDFa and it's not our
problem, I don't think it's good strategy.
I agree..
Parsing
Per [1] RDFa
On Dec 6, 2006, at 7:45 AM, Bruce D'Arcus wrote:
On 12/5/06, Scott Reynen [EMAIL PROTECTED] wrote:
In HTML or JSON, new formats need new parsers, which must be written
by someone.
Exactly. The point is if you have a generic model you have a
generic parser.
Right. HTML doesn't have a
From: Scott Reynen [EMAIL PROTECTED]
So while it might be comforting to dismiss RDFa and it's not our
problem, I don't think it's good strategy.
A good strategy toward what end? I think Elias has a problem that
microformats are not intended to solve. What he wants to do is have a
generic
Why should RDFa get to mooch of the reputation that microformats has
developed over the last 24 months? That reputation was developed by a
lot of hard work by a lot of people (and really hard work by a few).
What has RDFa brought to the table?
Like microformats, RDFa wants to carry inline
Some clarification:
Isn't microformats more than one microformat? And what is a
microformat? I thought a microformat was a specific collection of
defined names and structure defined by a rigorous process of market
research intended to consider pervasive use of semantic html in order
to
Bruce D'Arcus wrote:
RDFa includes namespacing, the lack of which is already a problem in
microformats (witness hCite and the serious awkwardness that title will be
indicate using fn), and which will grow over time as more and more people
want to mark up their content.
Moreover, the need to
Benjamin West wrote:
Talk of general microformats doesn't make sense. Talk of microformats as
technique also does not make sense.
If that is true, then having Microformat Design Patterns[1] doesn't make
sense. Which is it?
I'm not sure what you mean. A design pattern is a technique, which
On 12/5/06, Mike Schinkel [EMAIL PROTECTED] wrote:
For those on this list who are not following [whatwg], here is an
interesting thread about inability to use Microformats:
http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2006-December/00
8462.html
I wonder if his issues can be
On 5 Dec 2006, at 11:30, Mike Schinkel wrote:
For those on this list who are not following [whatwg], here is an
interesting thread about inability to use Microformats:
http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2006-
December/00
8462.html
I wonder if his issues can be
From: Mike Schinkel [EMAIL PROTECTED]
http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2006-December/00
8462.html
I wonder if his issues can be addressed?
How about a distributed parser-discovery service
More specifically a YADIS discovered JSON returning uf-specific parser:
On Dec 5, 2006, at 10:48 AM, S. Sriram wrote:
From: Mike Schinkel [EMAIL PROTECTED]
http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2006-
December/00
8462.html
I wonder if his issues can be addressed?
Ian said:
class, rel, and profile are the extension mechanism for HTML
From: Scott Reynen [EMAIL PROTECTED]
2. Place a yadiservices discovery pointer to where parser(s)
What you've described above is a process for converting all microformats
to JSON, but that doesn't really solve the problem Elias described. It
just changes the format. Each individual
65 matches
Mail list logo
