RE: [uf-discuss] Tutorial on AHAH (such a cool technology!)
is moved into the function itself, so that the content author just has to bring in the code and apply a rel attribute and a few id attributes. I don't see it. Can you give code examples? On a similar note, one a partner of mine is would on, how do you feel about scraping a document to find heading tags (H1..H3) so as to build a table of contents? I know what you're on about because Web Developer already has a View Document Outline http://chrispederick.com/work/webdeveloper/ Interesting. The biggest issue at hand is if this stuff is happening after the page finished loading, that the user received feedback on when these things have finished and the page is ready for use. When a page appears on the screen people expect to be able to use it immediately. If there is some 5 seconds of waiting required (without feedback of some kind) before everything is ready, that's where the trouble lies. 5 seconds is a lot! Maybe there are better techniques, like having the links be inactive and greyed-out until available? -- -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org http://atlanta-web.org - http://t.oolicio.us It never ceases to amaze how many people will proactively debate away attempts to improve the web... ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
OFFLIST: Re: [uf-discuss] Tutorial on AHAH (such a cool technology!)
Paul: OFFLIST I really enjoyed your discussion, and you seem to be very knowledgable about Javascript issues. I have started a project with a partner in the UK (I am in the USA) that we hope to see grow to be used by most websites and most webusers. One thing we think is missing are visible reasons for people to use semantic markup where they can see an immediate and obvious tangible benefit. That's why we decided to pursue this project. We've got pure intentions, and our goal is to be a catalyst to make the web better. The project is called Toolicious (http://t.oolicio.us) Minimally all I'm asking is for you to read the small amount of info on the website and then give me your feedback. Beyond that I'd hope you'd just the mailing list[1] and participate in the discussions. We want to ensure that there is no reason people wouldn't want to use it on their website, but I'll let the website try to finish explaining to you as it eventually needs to speak for itself. Thanks in advance for your consideration. -- -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org http://atlanta-web.org - http://t.oolicio.us It never ceases to amaze how many people will proactively debate away attempts to improve the web... [1] http://lists.t.oolicio.us/toolicious-discuss/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: OFFLIST: Re: [uf-discuss] Tutorial on AHAH (such a cool technology!)
Oops! Oh well, nothing said that I wasn't going to present to the Microformat community eventually! -Mike -Original Message- From: Mike Schinkel [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 06, 2007 4:43 AM To: 'Microformats Discuss' Subject: OFFLIST: Re: [uf-discuss] Tutorial on AHAH (such a cool technology!) Paul: OFFLIST I really enjoyed your discussion, and you seem to be very knowledgable about Javascript issues. I have started a project with a partner in the UK (I am in the USA) that we hope to see grow to be used by most websites and most webusers. One thing we think is missing are visible reasons for people to use semantic markup where they can see an immediate and obvious tangible benefit. That's why we decided to pursue this project. We've got pure intentions, and our goal is to be a catalyst to make the web better. The project is called Toolicious (http://t.oolicio.us) Minimally all I'm asking is for you to read the small amount of info on the website and then give me your feedback. Beyond that I'd hope you'd just the mailing list[1] and participate in the discussions. We want to ensure that there is no reason people wouldn't want to use it on their website, but I'll let the website try to finish explaining to you as it eventually needs to speak for itself. Thanks in advance for your consideration. -- -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org http://atlanta-web.org - http://t.oolicio.us It never ceases to amaze how many people will proactively debate away attempts to improve the web... [1] http://lists.t.oolicio.us/toolicious-discuss/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Scraping or parsing?
WITHIN the body IN ADDITION TO and as an alternate for using @profile in the head. -- -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org http://atlanta-web.org - http://t.oolicio.us It never ceases to amaze how many people will proactively debate away attempts to improve the web... ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Tutorial on AHAH (such a cool technology!)
Paul Wilkins wrote: Mike Schinkel wrote: Printable version please! Ane that doesn't take 12 pages to print... (He also grumbles about lack of back button in presentation but glad the presentation was not 96 pages...) The slideshow was built using S5, A Simple Standards-Based Slide Show System from Eric Meyer. http://meyerweb.com/eric/tools/s5/ Eric built S5 to scratch an itch, and now many others have taken to using it too. There are several ways to go back, arrow keys, page up, or mouse down to the info back and click on the arrows. Keyboard controls for it can be found at http://meyerweb.com/eric/tools/s5/features.html#controlcha t The keyboard controls aren't easily discoverable, especially for people viewing the slideshows and perhaps that's an improvement that can be suggested. Thanks for the link. I had seen various HTML slideshows used from evidently different sources, some with and some without visible controls, but didn't know Eric Meyer was the source of this one of them. I may be old school, but to me if there is no visible indicators of a control, or at least a link to a help file, they doesn't exist. As least not from a usability perspective. What's incredibly ironic is someone such as Eric Meyer who focuses on visual presentation would make such an error. Heck, his example presentation does not have visible controls; at least he could have included a help link to his keyboard shortcuts! You're right about the printing issue. a page per screen is too much. I wonder if there's a way to print on a virtual a5, and have two of those a5's appear on a single a4 page. BTW, it seems one can press T to toggle and get a printable view. If he added visible controls it would sure be the heck out of Powerpoint for the web! Another alternative that seems cleaner to me would be to code it like this and let your ahah.js annotate the link for you: a href=Waldorf-Astoria-Photo.html rel=ahahphoto/aOh course this last suggestion will probably run me afoul of the microformat police since rel=ahah hasn't even been officially proposed yet and I didn't bring it up on [uf-new]... ;-P Give it an id and the script can be robust while you're at it. I don't like the idea of javascript scraping the page for class names. Dustin Diaz covers this particular issue very well in Did I say class? No, I said rel ;-) Interestingly reading Diaz' article there were a lot of people with good points that disagreed with his suggestion. But whatever, I was more discussing an overall concept, not a specific implementation of Javascript or how to optimize it. Seems like I accidentially hit on one of your hotbuttons, though? :-) While it's convenient, it's slow, demanding, and at high risk of breaking. And microformats, as currently envisioned, are *not* at a high risk for breaking? As an aside, rel=ahah wouldn't be at a high risk of breaking because the author using the technique would author it so it didn't break (or can you see potentials where his authoring would break that are not abstract hypotheticals?) Also, how would Diaz' article apply if these AHAH links were littered throughout the document? His article addressed what seemed like typically a single widget, not multiple instances of the same widget scattered throughout a document. I think it would be a heavy burden to place on a content author to require them to write the Javascript code he talks about if they had to tag 10 different segments rather than just scan for a rel=ahah. I think these may well be two different use-cases that might deserve two different approaches. On a similar note, one a partner of mine is would on, how do you feel about scraping a document to find heading tags (H1..H3) so as to build a table of contents? How close would something like this get to cleaning things up? Anyway, I'm fundamentally not really a Javascript guy, I'm a URL guy. So my comments were focused on ensuring the URLs were treated right. If you are a Javascript guy that can optimize that stuff so it is still usable for the content author, it's all yours! -- -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org http://atlanta-web.org - http://t.oolicio.us It never ceases to amaze how many people will proactively debate away attempts to improve the web... If we're going to try to not use the class tag as an identifier for javascript functions, the trouble comes in making it easy for people to add the script to their page and use it. The following seems to do the trick. a href=Waldorf-Astoria-Photo.html rel=ahah id=waldorfphoto/a div class=ahah-waldorfnbsp;/div Then the script can get only what it needs, like the anchors, filter through them much more rapidly, perhaps with the wonderful forEach technique from http://dean.edwards.name/weblog/2006/07/enum/ and add the behavior to those elements with something like addEvent from http
RE: [uf-discuss] Scraping or parsing?
Danny Ayers wrote: Just as an aside (and I'm open to accusations of architecture astronautics here), if adding a profile attribute is hard for webmasters, the right answer is to make it easier rather than working around its absence. The head of a HTML document is an important part of the chain of authoritative metadata [1]. My pedantic side wants to yell Yea! Right on! but my pragmatic side tells me that taking such a position is completely impractical because of the proliferation of blogs, wikis, and cms that empower users to publish content with no access to the head. Access may be denyed because the content publisher is using software on servers they have no access to or because they can't change the source code of their web app as they are are not technical enough/don't have admin access to the servers/don't want to fork the source/have company policies that disallow mods/don't have the source/etc. You could say Well the answer then is to get all the developers of all those apps to provide the content publishers access to the head and then get all the existing apps in the field replaced with the new versions! However, I think you'll agree that requiring such an approach is impractical when it is possible to craft a workaround. Even if we could someone dicate the above, it would likely take a decade before most content publishers had access to head. After all, look how long it took to get the major browsers to add (some) support for certain standards, and they numbered far less then 10. There are hundreds of web apps for content publishing with tens of millions of server installations; I don't see them being 'fixed' any time soon. :-( FWIW. -- -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org http://atlanta-web.org - http://t.oolicio.us It never ceases to amaze how many people will proactively debate away attempts to improve the web... ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Tutorial on AHAH (such a cool technology!)
Costello, Roger L. wrote: Hi Folks,
I have created a tutorial on AHAH (Asynchronous HTML and
HTTP)
http://www.xfront.com/microformats/AHAH.html
Comments welcome.
Printable version please! Ane that doesn't take 12 pages to print... (He
also grumbles about lack of back button in presentation but glad the
presentation was not 96 pages...)
The purpose of AHAH is to enable an HTML document to
dynamically fetch HTML from other documents, thus
creating one document that is an assembly of information
from many HTML documents.
I assume you got AHAH from the efforts documented here[1]?
Provide a placeholder in your HTML document where you
want the fetched HTML data to be inserted. Identify that
placeholder using the id attribute, e.g.,/li
Shades of ASP.NET! Now we've got client-side placeholders too! ;-P
The target HTML document (the HTML that you are fetching)
must not be a whole HTML document; it must just be an HTML
fragment.
How does that work with content types? If it is a fragment then it is not a
valid text/html, right? Is there a content type of HTML Fragment? If
not, shouldn't there be and it be used instead of what you are using?
Alternately, shouldn't you include the full HTML head and body trimmings
but then extract the innerText from body before inserting? I think this
is actually something that could potentially even be discussed by W3C TAG
for a finding on best practices (i.e. inclusion of HTML fragments.)
Lastly, a
href=javascript:ahah('Waldorf-Astoria-Photo.html','Photo');photo/a
hides the content from search engines, which is not good.
Christian Heilmann wrote:
This example does that (except for the templating part):
http://beginningjavascript.com/Chapter8/exampleXHR.html
This approach is definitely better because it lets the search engines see
the link:
a href=perfect_day.txt onclick=return
simplexhr.doxhr('txtcontainer1',this.href)Perfect Day/a
Another alternative that seems cleaner to me would be to code it like this
and let your ahah.js annotate the link for you:
a href=Waldorf-Astoria-Photo.html rel=ahahphoto/a
Oh course this last suggestion will probably run me afoul of the microformat
police since rel=ahah hasn't even been officially proposed yet and I
didn't bring it up on [uf-new]... ;-P
--
-Mike Schinkel
http://www.mikeschinkel.com/blogs/
http://www.welldesignedurls.org
http://atlanta-web.org - http://t.oolicio.us
It never ceases to amaze how many people will proactively debate away
attempts to improve the web...
[1] http://en.wikipedia.org/wiki/AHAH
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Scraping or parsing?
Ryan Cannon wrote: Adding an @profile attribute to he headelement is far less technically demanding than, say, creating a tag space, which we also require. Especially as the addition also has no performance or usability impact. It may be less technically demanding, but the latter is needed. I also think that authoring microformats with the intent that they be usable to the CMS-using/WYSIWG masses is a pipe dream. Users should *not* be encouraged to publish HTML markup they cannot read. Robust microformatted content will always require either an understanding of how to hand-code HTML or a tool to help generate it--is it unreasonable to think that the meeting of either condition implies the ability to add an @profile as well for 80% of cases? I cannot overemphasis how strongly I disagree with that last paragraph from a philosophical standpoint, for two reasons: 1.) There are two schools of thinking, one of which I believe to be severely flawed: A.) Don't worry about the syntax or how it is implemented, the tools will take care of make it easy. B.) Don't even think about tools until it can be done and easily understood by a human. Only then should tools be created. Of course I strongly believe that A is the flaw perspective although I know there are many people in that camp, you (it appears) included. I plan to write a paper in the future on this issue after I've done enough research and gathered actual evidence but for now let's look at the technologies that have gained quick and *widespread* usage (a), and those that haven't (b): (a) HTML, RSS, CSS, XML, some microformats, shell scripts/batch files, languages using text for source, and so on. (b) XHTML, XML Namespaces, XSLT, RDF, other microformats, Visual programming languages, and so on. Yes, through some Herculean efforts some of the technologies in (b) have seen adoption, but not without tons of promotion by some entity with vested interests. The technologies that work are the ones that are designed for humans first, with humans with tools second. If it can't be done in Notepad or VIM, it's probably a bad idea. 2.) I also believe strongly that we should not dichotomize the population and split them into the haves and the have-nots; the party members and the proles, the Alphas and the Epsilons. Believing that there is or should be a difference between users and content authors is either simply ignorant or actively arrogant. The web with its recent social media component has empowered EVERYONE to become content authors, and I don't honestly see this abating. My expectation is that soon every kid from a first world country (and soon every kid in the world, if OLPC succeeds) will be as comfortable coding in HTML as today's office worker is comfortable using Microsoft Word. And if you'll forgive the tinge of melodrama, by you seeking to repress people's ability to richly author content you are in a small way working to put limits on users freedom of speech. I personally will fight anyone whose world view attempts to separate those who are anointed as being better and mere users where the better ones are the only ones who are going to get to publish rich content on the Internet, everyone else be damned. -- -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org http://atlanta-web.org - http://t.oolicio.us It never ceases to amaze how many people will proactively debate away attempts to improve the web... ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Scraping or parsing?
Karl Dubost wrote: There are two schools of thinking, one of which I believe to be severely flawed: IMHO, more than that. :) as there are nuances in between. True. A.) Don't worry about the syntax or how it is implemented, the tools will take care of make it easy. B.) Don't even think about tools until it can be done and easily understood by a human. Only then should tools be created. Of course I strongly believe that A is the flaw perspective although I know there are many people in that camp, you (it appears) included. still, it depends on the context. All is a question of context. I'll reserve my opinion for each context until its use-case is presented to me. :) The technologies that work are the ones that are designed for humans first, with humans with tools second. If it can't be done in Notepad or VIM, it's probably a bad idea. png, jpeg, gif, illustrator files, pdf, videos format? I'll give you those, but there is something fundamentally different about them, i.e. they are for visual presentation not logic and data encoding. And there is SVG. Still, I have to ponder why tools have worked there but not elsewhere. It could be simply because their level of complexity in text would be far beyond what a human could comprehend. But you might say that they are difficult formats, so what about email, usenet, chat messenging, irc. How many of us are editing the simple headers of emails by hand? :) Ah, but I would argue they were *first* a format that did not require tools for humans easily to understand, and later tools were added. I don't complain about tools, on the contrary I like them. I just think the underlying format should not be forgiven its complexity because of a faint hope that future tools that will make everything alright. It doesn't make your point invalid, it is just that it is not black and white :) heh. For someone who generally never sees anything but shades of grey, I certainly would be a hypocrite if I were to disagree with you there! :) It depends on the context and the way the technology has been developed, and its level of maturity. But wouldn't you agree, people tend to use the promise of a tool as a crutch when they should instead strive to make things in the raw grokable by humans first? -- -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org http://atlanta-web.org - http://t.oolicio.us It never ceases to amaze how many people will proactively debate away attempts to improve the web... ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Re: Well-known URLs
Angus McIntyre wrote: You could add: http://mysite.foo/siteinfo.xml although whether that's well-known is a matter of terminology, given that few people have actually heard of it. It seems that the SiteInfo 'standard' as proposed at: http://a9.com/-/company/help/siteinfo/ is quietly dying, and the A9 SiteInfo plug-in is no longer maintained. Which may or may not be regrettable: I quite like the idea, but it can be seen as just one more piece of clutter in your root directory. Thanks. Don't know why that didn't cross my mind. I just first read about it last week! -- -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org http://atlanta-web.org - http://t.oolicio.us It never ceases to amaze how many people will proactively debate away attempts to improve the web... ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] authoritative hCards, a simpler proposl
John Allsopp wrote: A number of somewhat overlapping suggestions seem to be floating around regarding this. There is definitely a strong use case, IMO, for somehow indicating that some hCard over there is a more detailed version of this one. For example, at the various conference sites I am involved wiht, we mark up all speakers using hCard. Ofen it's simply span class=vCarda href=http://johnfallsopp.com; class=url fnJohn Allsopp/a Now, if this could point at an hCard with more information about the speaker so marked up, to me that would be potentially very useful for something like Tails or Operator to pull in that additional information, or for aggregating references to the same person and on. As to definitiveness or authoriativeness, I think that's a tougher nut to crack. Thanks for the clarification. In reading the threads I didn't get the part about including a URL in an hCard to point to another hCard. That is helpful. OTOH I think (as you imply) this discussion might be attempting to use a pickaxe to resolve a problem that requires a bulldozer. Or said another way, trying to resolve a problem whose proper solution lies in a different domain. I've actually recently been thinking about a related question. i.e. what is a person's canonical URL? Google Roy T. Fielding, Bill Gates, Linus Torvalds, or even John Allsopp or Mike Schinkel and tell me which URL is the canonical URL? I've been planning to blog about this for weeks. Do you, or anyone, have a proposed solution to this dillema? Basically the problem is simplified as What URL identifies a person, and more importantly, how does someone who doesn't know that person or can't reach that person to ask be able to find it? And, being an advocate for Well Designed URLs, I do not think the right solution is to simply tag a random and undiscoverable and unmemorizable UID onto the end of a URL. But I'd have to understand the problem domain and use-cases to be better able to make an alternate proposal. -- -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org http://atlanta-web.org - http://t.oolicio.us It never ceases to amaze how many people will proactively debate away attempts to improve the web... ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Re: Well-known URLs
Andy Mabbett wrote:
http://exmaple.com/delorie.htm
(see
http://www.delorie.com/web/lynxview.cgi?url=http%3A%2F%2Fwww.
cheese.com)
I read the info about it I found while googling but I'm not sure I'm clear.
Is it saying that Opera will look for a page called /delorie.htm on the
current domain?
http://exmaple.com/opensearch.xml
Thanks. I knew about that one too. Not sure why I didn't think of it
earlier.
http://mysite.foo/
Please use http://example.com; for example URLs - it's
specifically reserved for that purpose.
I was not aware of [1], as evidenced by my proactive use of mysite.foo [2].
Still, one problem with using example.{tld} is it makes it confusing when
your example uses two sites, i.e. mysite.foo vs yoursite.foo is clearer than
example.com vs. example.net.
BTW, is http://exmaple.com also reserved too? ;-)
--
-Mike Schinkel
http://www.mikeschinkel.com/blogs/
http://www.welldesignedurls.org
http://atlanta-web.org - http://t.oolicio.us
It never ceases to amaze how many people will proactively debate away
attempts to improve the web...
[1] http://en.wikipedia.org/wiki/Example.com
[2]
http://blog.welldesignedurls.org/2007/03/01/urlquiz-2-url-equivalence-and-ca
chability/#footnotes-20070301
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Scraping or parsing?
Karl Dubost wrote: I'll give you those, but there is something fundamentally different about them, i.e. they are for visual presentation not logic and data encoding. And there is SVG. Still, I have to ponder why tools have worked there but not elsewhere. It could be simply because their level of complexity in text would be far beyond what a human could comprehend. and *pdf* (given in the list) I could have added, vcard, vcalendar, vectorial illustrator. All of those, I do NOT want edit by hands, even if I had the possibility ;) It's not about wanting to or not wanting to, it's about being able to. And just because some people want to use tools not all want to, so being able to is very important. vcard is easy to edit by hand, if need be. Same with vcalendar. What's more, both of those are generallyfgenerator or exported as opposed to authored. Also, being able to comprehend when reading and also being able to author by hand makes it is much easier for people to write code that generates the format. The easier that is, the more conforming implementations there will be. So I come back to my central thesis; design for humans first (even if those humans are programmers), build tools second. But wouldn't you agree, people tend to use the promise of a tool as a crutch when they should instead strive to make things in the raw grokable by humans first? That is a different issue :) Human is too broad to be meaningful. Is it a different issue? At least not closely interlinked? Human is too broad to be meaningful. I think Wikipedia does a pretty good job [1]. ;-) The goal is really to make a technology which is easy to use depending on the ecosystem. then using the argument that: 1. complexity of the technology is NOT important because there are/ will be tools.2. simplicity of the technology is a MUST because of hand authoring. are both flawed, IMHO. But you are twisting my words. I said: B.) Don't even think about tools until it can be done and easily understood by a human. Only then should tools be created. So I didn't say 'a MUST because of hand authoring'; I said it needs to be understandable by humans. :) Of course I did imply handauthoring be accessible, and stand behind that. But unless you are just picking nits, I don't think that is flawed. I'm really happy penballs exist even if I could use ink with a feather. I'm really happy to have light measurement on my camera, even if I could use my own lightmeter (which I do on a 6x6) Different domains. Apples and oranges. I'm talking in the domain where instructions for computer processing are given. I'm really I have not to teach HTML to my parents, and just give them a wysiwyg editor ;) Frankly, I'd rather teach a man to fish instead of having to fish for them all the time. I *did* teach my dad HTML so he'd quit asking me why the damn WYSIWYG editor kept screwing up his preferred layout and wouldn't let him fix it. But maybe that's just the former programming instructor in me... And 15 years later, I've yet to see an HTML editor that will allow me the same level of control of *output* (I'm not even talking control of markup) that I can get with a simple notepad (Even MS Word is infuriating in that respect albeit only someone ignorant of its excesses would use it to generate HTML for web publishing.) Yes, I'd rather have the WYSIWYG, but only if it comes w/o the frustrating limitations. Which is why I still do most of my editing on Notepad (well, Notepad2 that is.) but yes I think we agree. :) You do enjoy being pedantic, don't you? ;-) -- -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org http://atlanta-web.org - http://t.oolicio.us It never ceases to amaze how many people will proactively debate away attempts to improve the web... [1] http://en.wikipedia.org/wiki/Human ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] authoritative hCards, a simpler proposl
Scott Reynen wrote: I think you're still a bit confused about what was suggested. Indeed I was confused. I could have sworn I saw some kind of usage that tagged a GUID on the end of a URL, which is what confused me, but I can't seem to find that email in my folders so, not important. Thanks for the clarification. Many UIDs happen to be random strings of numbers and/or letters, but that's not at all a requirement for UIDs. And I hope, something that would be frowned on! So the proposal was just to add the UID class name to the URL class name, e.g. a class=url uid href=http:// theryanking.com/blog/contact/#vcardRyan King/a, not to add anything to the actual URL. Cool! -- -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org http://atlanta-web.org - http://t.oolicio.us It never ceases to amaze how many people will proactively debate away attempts to improve the web... ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] authoritative hCards, a simpler proposl
Ara Pehlivanian wrote: Maybe the problem is that we're trying to point to an authoratative hCard when in reality what we want to do is simply (like you just said) point to a more detailed hCard. snip The moment the ID is provided, it indicates that the link isn't just pointing to any old resource on the web, but that it is in fact pointing to a more detailed hCard. I think that makes a huge amount of sense. Determining authoritativeness is hard, leave it to another initiative and get almost everything else needed w/o it. Great suggestion. -- -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org http://atlanta-web.org - http://t.oolicio.us It never ceases to amaze how many people will proactively debate away attempts to improve the web... ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Re: Well-known URLs
Andy Mabbett wrote: http://exmaple.com/opensearch.xml I just researched this and it appears that Amazon/A9 are *not* using Well-Known Names but instead using autodiscovery on a link element[1]. -- -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org http://atlanta-web.org - http://t.oolicio.us It never ceases to amaze how many people will proactively debate away attempts to improve the web... [1] http://www.opensearch.org/Specifications/OpenSearch/1.1#Autodiscovery ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] authoritative hCards, a simpler proposl
Ryan King wrote: Catching up in the last few days, I find that there are some probelems with the authoritative hcards proposals. I' snip My proposal is that we use UID+URL to hint that there's an hCard on the other end of that URL which represents the same entity. Also, multiple hCards with the same UID may be considered as representing the same entity. In reviewing this I can't help but feel that I don't understand the use-case or the desired outcome. Will someone kindly explain? Is it that there could be hundreds of hCards on the web for Ryan King (the one for the guy who has the email address of [EMAIL PROTECTED]) but only one should be considered 'authoritative? Also, is the proposal is just throw some unique cruft onto the end of some URL for it to stake it's claim as the authoritative one? Sorry, but I've read the proposal and related emails several times and I'm still confused. -- -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org http://atlanta-web.org - http://t.oolicio.us It never ceases to amaze how many people will proactively debate away attempts to improve the web... ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Re: Well-known URLs
Edward O'Connor wrote: If the intent is simply to document the existing, legacy technologies that rely on such URLs (such as robots.txt), that seems reasonable to me. I'd be interested in documenting [1] them . Does anyone of any other initiatives to define Well Known Names besides these:? http://mysite.foo/robots.txt http://mysite.foo/favicon.ico http://mysite.foo/w3c/p3p.xml http://mysite.foo/sitemap.xml http://mysite.foo/crossdomain.xml http://mysite.foo/smbmeta.xml -- -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org http://atlanta-web.org - http://t.oolicio.us It never ceases to amaze how many people will proactively debate away attempts to improve the web... [1] http://wiki.welldesignedurls.org/Well-Known_Names ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Hidden elements considered harmful (Was: Inline styleconflict?)
Scott Reynen wrote: In general: hiding elements only hides them from humans, and leaves the content more accessible for machines than humans. Microformats are for humans first. For publishers: hidden elements are less likely to be kept up-to-date. Counterpoint: For data generated from a database where the data is visible elsewhere, this becomes a specious argument. Scott Reynen wrote: For parsers: hidden elements are more likely to contain spam. John Allsopp wrote: I think the fate of the meta element (unused by any search engine) pretty much demonstrates the difficult with invisible meta data Counterpoint: These are specious arguments in the context of metadata that is more tightly constrained and of the type that would provide spammers little or no benefit. For example, I am not aware of spammers using LINK elements yet LINK elements are invisible metadata that are used appropriately on the web today. It really makes more sense to look at the use-case rather than to issue a blanket edit of prohibition. FWIW. -- -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ It never ceases to amaze how many people will proactively debate away attempts to improve the web... ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Footnotes
Hi all: Lately I've been using a lot of footnotes on my blog, and footnotes seem to be the perfect type of thing for a microformat. I googled prior discussions but those discussions referenced several uses but didn't go anywhere. Some people pointed to cite but reviewing cite I wasn't able to find one example or reference to usage as a footnote, and also found cite to be overwhelmingly complex for my use-case. My use-case is while writing I often want to add some additional background to a point where the additional background is useful but tangential to the point of the blog post. That additional background might be an external link with comments but mostly it is just comments. What I've been using is this: pblah blah blaha class=footnote-ref href=#2006-12-31-slug[1]/a blah blah blaha class=footnote-ref href=#2006-12-31-slug[2]/a/p Then at the bottom of the blog post: ol class=footnotes id=2006-12-31-slug liBlah blah blah/li liBlah blah blah/li /ol Note I haven't been calling out each footnote individually because doing so is more work that I really have wanted to put into this level of semantic markup but if there were a well thought out microformat I might be willing to go to the extra effort. I don't have much bandwidth to devote lots of time to this issue (it's tactical for me, not strategic), so if others aren't interested and it doesn't require too much debate then I'd like to see what we can do. If not, I'll just do what works for me and not worry about it for now. -- -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Footnotes
Colin Barrett wrote: John Gruber's blog Daring Fireball[1] uses footnotes. [1]: http://daringfireball.com Andy Mabbett wrote: There are some footnotes here, with links to and from the referencing points: http://www.westmidlandbirdclub.com/blithfield/plants20060815.htm including an instance where a footnote is referenced form two different points in the text. Thanks. I guess what I'm asking is if there is interest from others to take footnotes through the official microformat process? -- -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Footnotes
Andy Mabbett wrote: I guess what I'm asking is if there is interest from others to take footnotes through the official microformat process? Possibly - what use-cases do you foresee? I can imagine a browser plug-in which, when the user clicks on or hovers over a reference to a footnote, brings it up in a floating window, for instance. Exactly. The only use-case I forsee is for blog footnotes. There may be others, but in the spirit of going with existing markup, using for a blog is what I'm currently[1] doing. -- -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ [1] http://www.mikeschinkel.com/blog/clarifyingmymicrosoftdeveloperdivisionrant ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] rel=nsfw
Scott Reynen wrote: Scott Reynen wrote: More valuable is all relative to likelihood to be published. I believe rel=nsfw was suggested on this list a while back, and this same vagueness issue was raised at the time. But I think in practice, almost no one is publishing ratings with links, and many people are publishing NSFW warnings.[1] Can you please provide some examples of real world publishing behavior? I would be happy to, except ... On Dec 29, 2006, at 9:21 AM, Frances Berriman wrote: The content-rating got listed under rejected-formats instead [1]. [1]http://microformats.org/wiki/rejected-formats#Content_Rating I don't have any real world examples that couldn't work with the rel- tag suggestion in that rejection. FWIW, that rel-tag suggestion was unclear to me. But my question was just to make sure you provided real world examples as it appeared you were advocating for a nsfw tag with providing examples. -- -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Canonical List of Link @rel attribute values?
Does anyone know if there is a canonical List of Link @rel attribute values? Are there any standards, conventions, etc. anywhere? Thanks in advance. -- -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] rel=pavatar
Jeena: [EMAIL PROTECTED] wrote: Is there no interrest in such a microformat like rel=pavatar? From the spec a few things are not clear to me. For example in 3a what URL is being called, by whom, and for what purpose? In 3b, what HTML page would contain the link and how does it relate to anything else? I could make assumptions, but I don't think it's good to require spec readers to make assumptions. Given that, I'm also trying to determine the potential use-case for a microformat for your pavatar. So are you envisioning that someone who would leave a comment on a blog along with their name, email, and website, for example, would have a personal avatar auto-discoverable at that website? And if so, are you then envisioning that the blog software would retrieve and cache the pavatar then display it using a microformat something like this?: img src=/pavatars/[EMAIL PROTECTED] height=80 width=80 class=pavatar / BTW, In looking at your spec it claims to be Candidate Recommendation and uses the same format as a W3C candidate recommendations. However, when I google for pavatar on w3.org, there are no results [1]. Has it actually been through the W3C process[2]? Also, it appears your spec uses a well-Known name[3] or /pavatar.png[4] for which at least certain people[5][6] in the W3C would have your head for, so something tells me you've not been through the W3C process? :-) I think I like the overall idea, but if it's not part of the W3C process you really should propose it and/or make it clear that it is your own proposal and not one that has been through the W3C's process. Also, I think it could really benefit by going through the process (but if it already has, I'm surprised given the ambiguities in the spec.) -- -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ [1] http://www.google.com/search?q=pavatar+site:w3.org [2] http://www.w3.org/Consortium/Process/Process-1999/tr.html#RecsCR [5] http://microformats.org/discuss/mail/microformats-discuss/2006-October/00646 9.html [4] http://blog.welldesignedurls.org/2006/12/20/conventions-not-constraining-req uirements/ [5] http://www.w3.org/People/karl/ [6] http://www.w3.org/People/Fielding/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] rel=nsfw
Scott Reynen wrote: More valuable is all relative to likelihood to be published. I believe rel=nsfw was suggested on this list a while back, and this same vagueness issue was raised at the time. But I think in practice, almost no one is publishing ratings with links, and many people are publishing NSFW warnings.[1] Can you please provide some examples of real world publishing behavior?[1] -- -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ [1] http://microformats.org/wiki/why-examples ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Canonical List of Link @rel attribute values?
Brian Suda wrote: Does anyone know if there is a canonical List of Link @rel attribute values? The HTML 4 spec has a list of terms: http://www.w3.org/TR/html4/types.html other than that the posibilities for the rel attribute are open. Thanks! You know after I saw this I was able to find this[1] too, which ironically is a different list! Are there any standards, conventions, etc. anywhere? There are several microformats which make use of the rel attribute - those could be considered conventions. Without drilling down into them all, my memory was that none of them used the Link element as it not visible; am I incorrect on that? -- -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ [1] http://www.iana.org/assignments/link-relations.html ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] rel=nsfw
Dougal Campbell I disagree. I think that the people who are likely to produce/consume a 'nsfw' tag have a moderately similar (though vague) notion of what is or isn't safe for most people's work places. In certain countries, a picture of a topless woman would be sfw whereas in others a picture of woman's uncovered face would be considered nsfw. It is rather myopic and (unconsciously) arrogant to presume other's culture are moderately similar to one's own. any more than the concepts of 'friend', 'acquaintence', or 'spouse' in XFN have to be defined. Those concepts are far more cross-cultural than that for offensive material. Alice might flag something as 'nsfw', whereas Bob might consider the same content 'sfw'. That doesn't invalidate Alice's personal opinion and her desire to warn others that the destination link might be questionable in some way. In fact, the designation might not even reflect whether or not the content is 'safe' in Alice's workplace, but merely that she recognizes that it might not be appropriate for *some* workplaces. You need to consider what Microformats are for. They are there to provide for automated processing. So yes while it is fine for Alice and Bob to write that things are nsfw or sfw, or send emails to friend with a link where they mention that it is nsfw, but I would argue that is not the same as using markup meant for machine processing. The former allows the human reader to evaluate the context, the latter has no intelligence with which to evaluate context. Consequently I would argue that microformats usage should be as objectively universal as possible. More simply said, it is fine for people to type NSFW next to a link they put on a web page, but to encode it for machine processing would be a mistake. Some metadata represents subjective opinions, not objective facts (e.g., hReview). Opinions vary. Ergo. Reviews are opinions by nature but that which defines something as a review is rather objective. Further, one need look at the use case with which the microformat would be applied. hReview allows aggregators to find reviews, nsfw would allow system to censor content. Those are two very different use-cases so even if there were some subjectively in what was considered a review and what wasn't, someone would get a longer list of reviews where many are not so good as opposed to content being sensored by nsfw. Now if the proposal is instead to include identifiers that are objective, I'd be far more supportive of that: img src=... class=nudity / img src=... class=violence / img src=... class=contains-the-f-word / img src=... class=sexual-acts-depicted / img src=... class=beastiality / img src=... class=christian-sacrilege / img src=... class=islamic-sacrilege / img src=... class=jewish-sacrilege / img src=... class=woman-sans-burka / Of course this could lead to a long list if we tried to cover all bases, but nudity and violence might be a start. Are there other classes you are concerned about? BTW, there is are a few others to specifically consider ;-) img src=... class=catholic-sacrilege / [1] img src=... class=swearing-in-using-the-koran / [2] img src=... class=pictures-of-mohammed / [3] img src=... class=goatse-related / [4] IMO, censorship is a very serious issue[5] and we should always err on the side of censoring less, not more. Of course if you are of the mind that censorship is a good thing, then my arguments may not be compelling for you. -- -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ [1] http://www.usatoday.com/tech/news/2002/07/10/italy-porn.htm [2] http://en.wikipedia.org/wiki/Quran_Oath_Controversy_of_the_110th_United_Stat es_Congress [3] http://en.wikipedia.org/wiki/Jyllands-Posten_Muhammad_cartoons_controversy [4] http://en.wikipedia.org/wiki/Goatse [5] http://progressives.typepad.com/broadview/images/justiceDouglas_0.gif ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Canonical List of Link @rel attribute values?
Brian Suda wrote: --- they are just defined for the rel attribute, so they can be used on both the link and the a, but for microformats we are only concerned with the visible data, and there for the rell attribute on a Thanks. At the moment I'm only interested in LINK, so I guess my question was off-topic, but I was pretty sure someone here would know and wasn't sure exactly where the question would have been more appropriate. -- -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] hCup
There they go again, using the name Microformats w/o permission... Time to beat them with a wet noodle! ;-) http://www.stuffandnonsense.co.uk/archives/hcup_microformat.html -- -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: Non-visible microformats was [uf-discuss] Principles ofMicroformats?
Benjamin West wrote: Without commenting on the rest, I'd just like to point out that the main reason for avoiding invisible meta data is because visible data is updated more often than invisible data. Spam is secondary to this principle. This is a usability phenomenon, not a spam prevention measure. That is only true when humans are doing the updating. It is not necessarily true if the pages are generated from a database and the database is what gets updated. It also does not consider non-visible metadata that is created by apps such as CMS, Wikis, Blogs, etc. -- -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: ecommerce was Re: [uf-discuss] Principles of Microformats?
Benjamin West wrote: I don't know if it's true either. Tantek suggests I'm being a bad scientist by allowing myself to look for patterns. Maybe that's why I'm a fish out of water here; discovering patterns is one of my strongest interests and one of my best skills. BTW, I didn't see this email until now because you only included my first name in the body, not my full name. My email software filters my emails from uf-discuss with my full name and leaves in my inbox, and the rest it moves to a folder for later review. Correct. The problem (as I've seen it) is the vision and process for microformats inhibits addressing those other issues. Again, this is just an observation, I am explicitly no longer advocating they change it. I respectfully disagree. I'd like to start investigating the use cases your business had trouble fulfilling, starting with: are the problems you described with vendor communication common? *Sigh* I've explained *one* of many different scenarious I am interested in. I've already been given dead-ends in many other areas. That's not to say I don't see benefit of Microformats in some contexts, but in the majority of contexts the Microformats process doesn't work for me. The Tantek and Ryan and others have told me as much. So why fight it? Mike, this is real good stuff. Can you continue elaborating? I can, for academic reasons, but this use case doesn't work with the microformats process. To address my former company's needs I would have needed to get a small group of vendors together, and they would not be interested in dealing with the uf-discuss list, only with a list specific to the use-case. BTW, Joe Andrieu recently suggested people on the list read Clay Shirky talking about how A Group Is Its Own Worst Enemy [1]. I read it yesterday and it was ABSOLUTELY BRILLIANT! Thanks Joe! It identifies clearly some of the issues with the microformat process. OTOH, it calls for ground rules, and Tantek, Ryan, et. al. have set them. So I am now going to quit fighting those rules and when I participate in microformat I'll accept the situation as it is, not as I want it to be. 1.) How many ecommerce sites have their inventory published on the web? - my guess is nearly all of them, although I suspect there are some confounding factors. 99% would be my guess. You can't sell things unless they are on your website. And if you are a call for more information kind of company, you are not an ecommerce company. :) BTW, I wrote a long message [2] about how to handle products generically back in november. Absolutely zero people responded to me. 2.) How many sellers have trouble getting product information from their vendors? - this one kind of surprises me, I thought everyone had at least a php script hooked up to their database to produce a CSV. It's not that they have trouble, it's that someone has to take the initiative. And that isn't always the highest priority for someone at a vendor, or at the reseller. Far better to have machines do it, but the process on all sides needs to be as simple and low friction as possible, hence why microformats is a good fit. Remember, we are talking many small companies, not Microsoft. (But it's also needed by resellers for dealing with Microsoft). Plus, what about the magazines that want to maintain a buyer's guide? And what about the how to select kind of websites that want to help people select products? What about the companies whose business models don't currently exist because we haven't thought of them? (But again, Microformats doesn't address that ;-) 3.) How many esellers use vendors to populate a part of their online offerings? 100% Resellers with any size product line can't afford to create all the product information. Vendors know their products far better in aggregate than the resellers ever can. Note I'm not talking about VARs who specialize in a handful of products. They have different issues and tracking product info is not really one of theirs. 4.) Would hlisting http://microformats.org/wiki/hlisting solve this particular use case? Like a car would solve the needs of a dump truck. Sure you could use it, but it would take orders of magnitude more time and get the car really, really dirty. :) Said another way. classified ads are optimized for the listing, ecommerce product information need to be optimized for the product information. Take a look at [2] for a better idea. -- -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ [1] http://www.shirky.com/writings/group_enemy.html [2] http://microformats.org/discuss/mail/microformats-discuss/2006-November/0072 87.html ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: Non-visible microformats was [uf-discuss] Principles of Microformats?
Angus McIntyre wrote: Google just doesn't - as far as I know - use either the keywords or the description in order to decide how to index the page, because of the problem of keyword stuffing. Some invisible metadata can be potentially abused by spammers, but not all. It depends on the nature of the metadata. -- -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: professional relations (was: XFN usage stats andRe:[uf-discuss]rel=muse implies romantic relationship?)
Siegfried Gipp wrote: Am Samstag, 16. Dezember 2006 08:31 schrieb Mike Schinkel: You are making an invalid assumption which is that I'm concerned about my markup. No, I'm not. I've concerned about the need for a standard to be created so that a body of knowledge and tools can be developed around that body of knowledge, and people will evangelize and a large number of people will implement. But that said, it's now clear to me that the microformat brand is not going to address my concern. No need to discuss any more; it's a dead issue. Are you sure? In any democracy a standard is a matter of adoption. And microformats do have the potential to be widely adopted. Although not for the majority of pages (at least not within the next ten years). But that's not a matter of microformats. It is simply that the majority of pages do not care for semantic markup at all, so why should they care for microformats? In an old-style page, marked up 100% vo visual effect, microformats is not even thought of. Nevertheless, and although microformats aren't perfect, it is still worth the efford. Thanks for the comment, but I wasn't able to figure out what point you were trying to make. Were you saying that Microformats will develop to be a standard? If that was your point, I don't debate it; I expect it. But w/o disambiguation and a way to scale of the process, I think it will create a mess. Or are you saying that there won't be a mess because you don't think many pages will use Microformats? Again, I'm rather confused on your point. -- -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Comments from IBM/Lotus rep about Microformats
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 expect publishers to behave differently with HTML symbols. We could require profile URIs, but that won't make anyone use them. OI think only a practical need for disambiguation will do that. The analogy is flawed. Humans have intelligences to compensate when presented with ambiguity. Machine (at least currently) do not. -- -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: URI profiles [was RE: [uf-discuss] Comments from IBM/Lotus rep aboutMicroformats]
Joe Andrieu wrote: Yea! I think profiles are great. So, why not formalize the requirement? However, without the profile requirement, authors have no reason to expect that parsers won't pick up their standards-compliant microformats. 100% compliant code should work with 100% compliant parsers. That seems self-evident. Does it make sense to allow compliant parsers to ignore compliant microformats? +1 -- -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: XFN: Proposing rel='respect' (was RE: professional relations andXFN usage stats and Re: [uf-discuss]rel=muse implies romanticrelationship?)
Benjamin West wrote: Aren't claims that you are respected by ___ kind of arrogant? That made me laugh! :) -- -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Principles of Microformats?
proposed changing I've been told that that was not the vision for microformats. 20.) Aims to avoid changing publishing behavior I'd say we aim to codify publishing behavior in a way that minimizes the need to change where possible. For example, IIRC, all semantic lists are valid XOXO. Quoting from Tantek ...microformats do not try to alter people's publishing behavior in an unnatural way... 22.) Constrained to enhancing known use-cases. I've recently come to believe that working without a use case is silly. Let me rephrase that. Constrained to enhancing use-cases currently published on the web (as opposed to use-cases for data planned to be published on the web.) -- -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: URI profiles [was RE: [uf-discuss] Comments from IBM/Lotusrepabout Microformats]
Without meaning to sound flippant, they should convince their tool providers to support microformats. It would take some effort, but blogs or CMSs or whatever can either provide access to the HEAD tag or some mechanism for specifying which microformats are in use and adding the required profiles into the HEAD tag itself. That position doesn't reflect reality; it's akin to Rumsfled saying the war was going well. It's what he wanted, but it wasn't true. The reality is that lots of CMS are open-source, and open-source does what they want to, when they want to. It's the nature of open source. What's more, hosting providers often install software based on customer request; customers can have any flavor they want as long as it's vanilla. (Try to get a web host to install ISAPI Rewrite on a Windows server, for example. Apples Oranges, but still.) No, the person who will be hurt by that position is the content author who can't get the CMS to change and/or doesn't have the skills to modify it themselves. Further, the web at large will be hurt because less content will be marked up semantically than could have been. When new technology is deployed, there is generally a transitional phase where it takes developers to make things work. Once the tools catch up, even non-techies can be a part of it. There's no real reason not to expect that transitional phase to be a part of microformats' adoption. My understanding is many of the tools out there are already working on some sort of microformats support, this is just another example of it. Then there is a need for a transitional solution. -- -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Principles of Microformats?
Siegfried Gipp wrote: Mike, interesting list. 1.) Includes visible-only Yeah, microformats only represent visible data. Sure? Think of: link rel=tag href=http://www.microformats.org/xfolk; title=xfolk/ When I've discussed proposing numerous non-visible Microformats, Tantek (and others) told me no (numerous times.) I can dig up some quotes if need be. So I was documenting and clarifying philosophy, not prior deviations from. Don't forget xhtml :) It was assumed. Unfortunately. Although microformats could be quite useful for other types of web resources, too. Agreed. -- -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: URI profiles [was RE: [uf-discuss] Comments from IBM/Lotus repabout Microformats]
Elias Torres wrote: Didn't somebody proposed here or at WHATWG to have profile added to any element in HTML? Would that solve the problem and limit the scope of the usage of a specific microformat? Yes, and it might have been me (or I saw it and realized I didn't need to propose it.) What's needed is agreement here so that many people here can go there to tell Ian that it's important, and why. Otherwise he'll say It's not clear to me that that is important and it won't happen. -- -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: ecommerce was Re: [uf-discuss] Principles of Microformats?
Benjamin West wrote: I'm only vaguely familiar with some e-commerce issues. You may find that the the early creators of microformats, because of a relatively common background, may simply not have enough exposure to this kind of thing. After all, they are only human (as am I.) I believe most of the earlier members of the community work for search companies or other large websites, or even makers of web browsers and web technology, and not many are familiar with ecommerce. As I wouldn't expect them to be either. I've also noticed that many of the more successful technologies I can think of first implemented use cases with user-centric data: people, places, things, times, and events. I don't know that to be true, but it certainly makes sense. That doesn't mean other use cases aren't of interest to the community. It simply means that time and energy are limited, and people tend to spend most of it on things they are good at. Correct. The problem (as I've seen it) is the vision and process for microformats inhibits addressing those other issues. Again, this is just an observation, I am explicitly no longer advocating they change it. Can you elaborate a bit more on these kinds of use cases? Are there some basic categorizations of ecommerce? What are the common things sites need to do? Where and how do they need to talk with other systems? High level answers are good. Let me give you a real world example. I used to run Xtras.Net (www.xtras.net) We sold products from companies like www.infragistics.com and www.componentone.com, but at certain points we dealt with well over 500 different vendors. Had we need able to manage the logistics, we could have dealt with well 2500 vendors and our sales would have increased significantly. Realize that most of these vendors were starving artists, i.e. one or two man shops making less than US$100k/year in revenue. They certainly were not going to be buying any ecommerce infrastructure, but they did update their websites whenever they had a new version. If an appropriate semantic markup could have been defined we might have been able to get most of those vendors to apply it and then we could have run crawlers to get a lot of our data. I actually had this vision in 1997 when I first heard of XML, but for many reasons was never able to make it a reality (many reasons=lack of capital to fund the development :) It would be that much easier with semantic markup with today scripting languages and other tools. But realize that Xtras.Net's business volume was a gnat on the back of a dog in a car on a ship crossing the Pacific ocean when compared to the world economy. So take all the other gnats, and dogs and cars and ships and have them all start creating their own industry specific semantic markup and BAM; you got some serious eff-ing chaos, and I declare that will be a Bad Thing(tm) for the web. But again, I'm no longer advocating Microformats change. I'm working on some other ideas. -- -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: the term microformat and encouraging people to play (wasRe:[uf-discuss] Comments from IBM/Lotus rep about Microformats)
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On S. Sriram wrote What you have is a 'classic branding problem' ... Excellent analysis. Al Ries is my hero. :) -- -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: professional relations (was: XFN usage stats and Re:[uf-discuss]rel=muse implies romantic relationship?)
Siegfried Gipp wrote: You don't need the custom: prefix. Anyone can define his/her own relationships. BTW, there are more relationships than between persons. Think of rel=prev, rel=next, rel=contents, ... So if you need your own relations for whatever, simply use them. It's just it is no microformat. You are making an invalid assumption which is that I'm concerned about my markup. No, I'm not. I've concerned about the need for a standard to be created so that a body of knowledge and tools can be developed around that body of knowledge, and people will evangelize and a large number of people will implement. But that said, it's now clear to me that the microformat brand is not going to address my concern. No need to discuss any more; it's a dead issue. -- -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Regarding Profile URIs and Disambiguation(wasComments from IBM/Lotus rep about Microformats)
Ciaran McNulty write: On 12/14/06, Mike Schinkel [EMAIL PROTECTED] wrote: Just curious, what did you mean by double entendre markup? It means 'double meaning'. Sigh A double entendre often refers to something with a negative meaning. I was basically asking if that's what he was implying without being defensive. -- -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
XFN: Proposing rel='respect' (was RE: professional relations and XFN usage stats and Re: [uf-discuss]rel=muse implies romantic relationship?)
I always find it interesting how on a mailing list someone can make a simple comment with a pretty small scope and then have the community run with it, misinterpretting the original comment or suggestion, expanding its scope, and then debating and often even criticizing the assuming original intent! I've had this happen twice regarding comments I've made in so many days. So please let me clarify that when I said: OTOH, I could use any of the following if attached to professional: Respect, admire, impressed by,awed, revere, worship, idolize, iconize. If would be nice if there was a way to extend professional respect and admiration. I was simply saying that I felt there was a strong need for ONE additional value to be used in the professional relationship category. When I blog I frequently refer to people to whom I would like to include some form of professional respect and admiration, but none of the words I thought of were quite right. This has the effect of my just having no motivation to use XFN. So in order to start the discussion about which ONE term to add, I listed all the ones of similar meaning I could think of in hopes to have people say I think '' would be best. And at the risk of rehashing, I'll try to state clearly why I don't think the current list is sufficient. While the people who defined XFN 1.1 intended muse to be used for what I find missing, I am completely uncomfortable denoting someone as my muse unless a.) they are of the opposite sex, b.) she is a celebrity of sorts, c.) and I don't know her personally. As the web is mostly a social phenomenon I would contend that although the use of muse makes perfect dictionary sense, the common use muse, especially when paired with romantic has implications I personally would not want anyone to infer if I linked to Steve Jobs, Bill Gates, or Linus Torvalds. Call me uptight, but I'm sure I'm not the only one. That said, I would like to propose that we add to XFN respect in the professional category, or some other similar term which the community decides is more appropriate, and increment the version to 1.2. -- -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: professional relations (was: XFN usage stats and Re: [uf-discuss]rel=muse implies romantic relationship?)
As an aside, at the risk of starting a firestorm, it would be nice if there were a way to let the user decide his one relationship, i.e. maybe a rel=custom: href=...John Smith/a Where is of course the person's one identifier. Basically this would allow people to create a folksonomy. It could even require one of the other predefined tags to ensure that aggregators can still get a rough idea. -Mike ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Microformats: working group vs. meme
Mark Murphy wrote: I think what Mr. Schinkel and Mr. Mabbett are running into is the apparent schism between microformats-as-working-group and microformats-as-meme. From my perspective, you are spot-on, if you ignore that I had additional concerns. From my extremely humble vantage point, I can see three main paths for microformats.org to choose from: -- Embrace microformats-as-meme. -- Limit microformats.org to only those things that follow the process. -- A hybrid: microformats.org helps orchestrate the forking of the meme. Great analysis. I plan to come back to your analysis in the near future. -- -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Question about Mailing List Software
Question about the list management software: Does anyone know if there is there any way that the URL into the list archive for an email message could be appended to that email message before it goes out? I'm constantly wanting to refer to an email across lists with a URL but that requires me to spend 5 minutes each time trying to track down that URL! -- -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: microformats vs. semantic XHTML (was Re: [uf-discuss] Commentsfrom IBM/Lotus rep about Microformats)
As with the rel=muse concern, my comments regarding uppercase/lowercase microformats were misunderstood and the subsequent related discussion was way out of scope since it was based on my comments. When I first used the term (lowercase) microformats, I was merely trying to communicate a concept. I didn't know of a universally understood term so I used a phrase whose meaning would I thought would be relatively easy to determine from context. I had no desire nor was it my intention to invent a meme, thus the subsequent debate on the topic was simply unnecessary. However, it does point out that there is confusion, and an authoritarian approach is unlikely to resolve both the ambiguity and the manner in which people apply the term in the wild. Frankly, it's not a huge issue to me because social dynamics will end up creating the commonly understood term even if some people aren't ok with what that term ends up being. Tantek Çelik wrote: semantic XHTML (OR semantic HTML) This is well-used well-adopted pre-existing term and there is no need to invent a new term to mean the same thing. Point of note, apparently not as well adopted as you believe. Ian Hickson referred on WHATWG to (lowercase) microformats/semantic HTML as keywords in HTML's extension attributes: Ian Hickson wrote[1]: A microformat isn't just anything that uses keywords in HTML's extension attributes; a microformat is a format that has gone through the very rigorous process of research, design, and public study that Microformats.org documents. So it seems that well-adopted terminology is still not common. FWIW. One final point: Tantek Çelik wrote: This is one of the reasons why I have avoided capitalizing the term microformats everywhere it is used. There is no capital variant. There is just microformats, as has been defined. And just as squares are quadrilaterals with additional constraints, microformats are semantic (X)HTML with additional constraints. In particular, the difference between the specific semantic XHTML technique that is using semantic class names, ids, rel/rev values and a microformat Is that *anyone* can make up semantic class names, id, rel/rev values, for any reason in any way, and in fact, modern web designers and information architects were doing so *long* before microformats was even coined as a term. Indeed, it was precisely this pre-existing behavior that inspired me to first even dare to propose microformats as a refinement thereof. 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] Is seems to me Tantek you are saying here and in other emails that, on one hand there is no distinction between official and unofficial microformats and on the other hand they are microformats if and only if they follow the principles and the process. Either all semantic class names are microformats or there is a difference between microformats that follow the rules and those that don't. You can't have it both ways. Now I don't care strongly enough about this to continue the debate, but I will say that I believe your positioning will paint you into an untenable corner if you don't rationalize it. Again, FWIW. -- -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ -- -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ [1] http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2006-December/00 8724.html ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Principles of Microformats?
I've sat down and tried to define a list of principles regarding microformats. I wanted to present this list here and get feedback to make sure that I am not misunderstanding them. Please comment on them by number so as to make clear any comments. Thanks in advance. 1.) Includes visible-only 2.) One flat namespace 3.) No solution for resolving ambiguities 4.) No Microformat registry 5.) No versioning capability 6.) Recognition is exclusive 7.) Requires community process and approval 8.) Envisions limited scope 9.) Process favors expedience 10.) Specifications allowed to evolved w/o explicit finalization 11.) Considers existing HTML usage 12.) Centralized control and approval authority 13.) One design discussion mailing list 14.) No delegation of decision authority 15.) Implementations not part of process 16.) No officially recognized implementations 17.) Inspired by needs of Bloggers and blog-related services 18.) Emphasizes general purpose needs 19.) Focuses on existing content publishing models 20.) Aims to avoid changing publishing behavior 21.) Envisions exposing existing content semantically 22.) Constrained to enhancing known use-cases. -- -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ P.S. I know is a different presentation of principles on the wiki and elsewhere, but I'm trying to clarify my understanding of the Microformats vision, principles, and process and as such my use-case needs to understand them in a list like I have provided above. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Regarding Profile URIs and Disambiguation (wasComments from IBM/Lotus rep about Microformats)
Scott Reynen wrote: But I also think it's both a rare and a bad practice to use one symbol to communicate two different ideas in a single context. It may be rare in the use-cases you've seen, but in content that I expect to be publishing soon it will be the norm, not just isolated special cases. here's what you can do to solve this problem whenever you encounter it: 1) add profiles for both vcard and region-data, e.g.: 2) add prefixes to all your region-data tags when you decide to add the conflicting hCard names, e.g.: 3) designate that prefix in a meta tag, e.g.: 4) convince developers of region-data parsers to look for prefixes That works in the context of a known microformat vs. semantic markup in the wild, but does not work between two semantic markups in the wild that are unknown to each other at the time of definition. Further, it imposes a burden on the semantic markup definer and the content author of needing to prefix all markup instead of just the markup that conflicts in a given HTML document (my proposal would make it a known standard that prefixes on sub-elements are only required for disambiguation.) And lastly it only works for those who have access to the HTML element; with the proliferation of hosted blogs, wikis, and forums, people are decreasingly able to annotate the HTML element. Nonetheless, in the interest of ending this discussion... At this point it's become clear to me that the Microformat community is not interested in addressing the issue. Although I wish that were not the case and I do believe it will do harm to the web, I will nonetheless relent and respect the decision. I am noodling an alternate way to solve the problem that might be more palatable, and once I get it clarified enough to write down I will propose it to the Microformat community. Now you can go crazy with your double entendre markup Just curious, what did you mean by double entendre markup? -- -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: URI profiles [was RE: [uf-discuss] Comments from IBM/Lotus repabout Microformats]
Scott Reynen [EMAIL PROTECTED] I agree it would help to make that more clear, but if you're suggesting we change that should to a must, I'd ask you what practical benefit you expect publishers would gain from such a change. We're trying to avoid solving hypothetical problems here, and I don't see a practical problem profile URIs solve yet, as I haven't noticed anyone using class=vcard to designate their Valentine's Day cards or anything else other than hCard. Assuming that the equivalent of Profile URIs were allowed on elements within a body tag for those who can't access the html element, it would provide at least two practical benefits: 1.) It would allow someone who is not immersed in the Microformats process to discover the specific microformat and learn more about it when viewing source of an HTML page. 2.) More importantly, it would allow a parser to positively identify the use of a specific microformat on a webpage and not have to infer the possibility that it had discovered a specific microformat. If you're interested in seeing wider adoption of profile URIs, I'd recommend work on filling in the XMDPs for every microformat, because it wouldn't make much sense to require publishers to point to profiles which don't exist. I do agree that (something like) this is needed. One of my pet peeves is specs that require a URI but don't require it to be a URL, i.e. resolvable to documention and ideally metadata. -- -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Regarding Profile URIs and Disambiguation (was Comments from IBM/Lotus rep about Microformats)
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 profile URI is used to disambiguate random styles with intended semantic values. Thanks for the reply. Someone previously mentioned to me on this list that Profile URIs were a solution. Yet when I asked about them I interpreted the answer that I got back to indicate they allowed a specific microformat to be identified, but not to have two or more to be explicitly disambiguated. Since I apparently misunderstood how Profile URIs work, can you please mark up my example, repeated below [1], to indicate how a Profile URI might be used to disambiguate my example? I would definitely appreciate it. So far this isn't a problem, and to save time and effort we are focusing on the more important things. I do appreciate the need to prioritize; I can really empathize with that. However, please understand that I am working on a project where disambiguation IS a problem (a major problem, actually.) microformats are not squatting on terms. Forgive me if I used a term that came across as distasteful; that was not my intention. Nonetheless microformats do make use of a scare resource, that being the HTML class attribute and a few other attributes. Hence there is an inherent likelihood of name clashes that can render an HTML content author unable to use two conflicting microformats in the same document unless of course Profile URI resolves those ambiguities. I do look forward to your clarification on Profile URIs. -- -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ [1] Looking at ADR, here is an example: div class=adr div class=street-address665 3rd St./div div class=extended-addressSuite 207/div span class=localitySan Francisco/span, span class=regionCA/span span class=postal-code94107/span div class=country-nameU.S.A./div /div Now let's say I want to use something called RegionData where Regions are heirarchical: div class=region-data div class=region street title=child-of-city665 3rd St.; Suite 207/div span class=region city title=child-of-stateSan Francisco/span, span class=region state title=child-of-countryCA/span span class=post-code94107/span div class=region country title=child-of-continentU.S.A./div /div Now, someone needs to use both: div class=region-data vcard div class=region street title=child-of-city div class=street-address665 3rd St./div div class=extended-addressSuite 207/div /div span class=region city locality title=child-of-stateSan Francisco/span, span class=region state region title=child-of-countryCA/span span class=post-code postal-code94107/span div class=region country country-name title=child-of-continentU.S.A./div /div How to disambiguate with Profile URI? (Please make the assumption that the developer of region-data knew nothing of vcard when region-data was published.) ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: XFN usage stats and Re: [uf-discuss] rel=muse implies romanticrelationship?
Sorry that I'm coming in a bit late on this, but in looking at rel=muse it's the only thing in the Microformat that is even close to applicable in a wide variety of cases yet I am completely uncomfortable using it except for in a few rare cases. OTOH, I could use any of the following if attached to professional: Respect, admire, impressed by,awed, revere, worship, idolize, iconize. If would be nice if there was a way to extend professional respect and admiration. -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: class=hack? Re: [uf-discuss] Comments from IBM/Lotus rep aboutMicroformats
Chris Messina wrote: The goal of this community is not to necessary act as a filter, but to adhere to a process for coming to some kind of consensus on a small number of formats that can be embedded in ordinary web pages. We look at widespread existing behavior and help massage that behavior in such a way so that we can help computers understand that data better. Chris, are you aware that Ian Hickson and Lachan Hunt on the WHATWG list are prescribing microformats as the generalized extension mechanism for HTML (whenever anyone asks for a more generic extension mechanism?) -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: class=hack? Re: [uf-discuss] Comments from IBM/Lotus repaboutMicroformats
Benjamin West wrote: Mike, this isn't quite true. What's being prescribed are the techniques. Techniques using mechanisms already available in HTML. These are the same techniques that Microformateers apply to well defined problems to create a microformat. But just because microformats are a notable use case for these techniques doesn't mean that anything using those techniques is a microformat. What has been confirmed on the WHATWG list are the techniques available to extend HTML. Why do these discussions have to be so circular?!? Okay, fine, I'll agree with your clarification because your point is really irrelevent to my concern. But I'll this time use your clarification to point out yet again that without a disambiguation process we'll have Balkanization of these techniques. I don't care what we call them: techniques or Microformats or anything else for that matter. All I care is that we get a simple disambiguation strategy included in the recommendation. -- -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Comments from IBM/Lotus rep about Microformats
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 http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Comments from IBM/Lotus rep about Microformats
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, I agree with you completely. But Ian Hickson has said that AFAHK that there was no cry for additional attributes on the uf-discuss list, And Ian also said he saw no need for them after I requested to get several attributes added to the list of attributes applicable to all elements, i.e. abbr, href, name, rel, rev, scope, size, src, type, and value. I hadn't had the chance to ask the uf-discuss list about this, so now is a perfect time. What about adding additional standard attributes to all elements. Would it be helpful? -- -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [admin] Declaring end of thread (was Re: [uf-discuss] Commentsfrom IBM/Lotus rep about Microformats)
Tantek Çelik wrote: 3. Prefixing (e.g. vcard-) has already been considered and rejected for microformats in general. There have been deliberate exceptions made for one microformat (hAtom). I'm not going to spend the time re-arguing this now - I have added an item to my to-do list on the wiki to better document this. First, I didn't see this until a just little earlier today when I cleaned out my Google spam box (6000+ spam messages and then all of your emails, for some reason.) Second and last, my comment to you based on your position RE:prefixes is that it is just begging to have the Microformat community splintered for lack of a viable solution to a real problem. Maybe prefixes aren't the answer, but I haven't heard an alternate presented. Respectfully, -- -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Comments from IBM/Lotus rep about 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 distinguish between official and unofficial in other areas in the past. Lots of people are already doing this, and don't need any official body to bless them. Agreed. I just see the need to give those people a way to disambiguate between themselves and Microformats. I've said the same here as well as on WHATWG. But I'm not gaining any success to date. People are saying it is a hypothetical problem while ignoring that I am saying it is an actual problem in my usage. Microformats (any casing) would be a subset of these products that are blessed by pervasive use across the web. I'm hesitant to pick out such a name, lest I choose badly (eg AJAX). I'm happy to let the market pick that name (eg I don't think anyone should deliberately pick it out.), but at the same time, I'm hesitant to let the term microformats be applied to general applications of general techniques. Does that reverberate at all with you, Mike, or anyone else? That's exactly what I see going on here and discuss on WHATWG, so yes. Ian Hickson called it Keywords in the HTML extension mechanism and I reverted to calling it semantic markup embedded in HTML. Maybe we could call it SemMarE? (yeah, I suck a making up names too. ;-) -- -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Disambiguation Conventions? (was Comments from IBM/Lotus rep about Microformats)
Ryan Cannon wrote: If the community is slow to develop a format that makes sense, we often encourage authors to develop their own systems, which then can inform how a format will function in the wild. This is where documentation and the oft-belabored process becomes powerful. Although it can be annoying for early-adopters and people who need solutions now, it creates strong formats once the issues are solidified. Arrgghhh! (he says, frustrated that people address the tangent to his issue, but don't/won't address his actual issue!) So I repeat: How then can we achieve a disambiguation conventions to keep official Microformats from conflicting with proto- Microformats? -- -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Comments from IBM/Lotus rep about Microformats
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 tell me if I misunderstand, but I think that clearly identifies the problem I've been trying to address: naming clashes on a scare resource. If what I think you said is correct, that would require someone to use one or the other, but not both. That approach to web architecture is clearly not acceptable, don't you agree? -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Comments from IBM/Lotus rep about Microformats
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 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 the same HTML document? -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: RE: [uf-discuss] Comments from IBM/Lotus rep about Microformats
--- 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 XMDP of hCard. Are you referring to this? http://www.w3.org/TR/html401/struct/global.html#profiles Is a Profile URI a well-known URI where I have to find semantics elsewhere or if not what format is returned by the URI? (just trying to understand) How can I disambiguate when two Microformats collide? Let me give a concrete example (one I will be working on in the future): Looking at ADR, here is an example: div class=adr div class=street-address665 3rd St./div div class=extended-addressSuite 207/div span class=localitySan Francisco/span, span class=regionCA/span span class=postal-code94107/span div class=country-nameU.S.A./div /div Now let's say I want to use something called RegionData where Regions are heirarchical: div class=region-data div class=region street title=child-of-city 665 3rd St.; Suite 207 /div span class=region city title=child-of-stateSan Francisco/span, span class=region state title=child-of-countryCA/span span class=post-code94107/span div class=region country title=child-of-continentU.S.A./div /div Now, someone needs to use both: div class=region-data vcard div class=region street title=child-of-city div class=street-address665 3rd St./div div class=extended-addressSuite 207/div /div span class=region city locality title=child-of-stateSan Francisco/span, span class=region state region title=child-of-countryCA/span span class=post-code postal-code94107/span div class=region country country-name title=child-of-continentU.S.A./div /div How do I disambiguate between region-data's region and vcard's region? Assume I created my RegionData with no knowledge that vcard existed, because unless there is a central clearing house to avoid name clashes, two different groups will end up creating conflicting microformats with clashing names. It is also only a hypothetical issue, so until this becomes a real issue, we're not going to worry too much about it, but we do have a system that solves this problem. So we aren't squatting on any values. Hypothetical issues sometimes have a way of biting people in the ass, using a phrase Mark Baker recently said on the REST-discuss forum on another topic. :) However, this is not a hypothetical issue. A project I'm working on that I'm not willing to go public with yet will make heavy use of microformats-like markup, and I've already seen a lot of potential for collision such as the one above, which is an example of a planned use. But maybe Profile URIs can solve this. Can you please explain how, using my example? -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Comments from IBM/Lotus rep about Microformats
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/ http://www.welldesignedurls.org/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: Re: RE: [uf-discuss] [citation] url field
Ironically, this sounds like another real-world (i.e. not hypothetical) example of the need to provide a way to differentiate microformats. -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael McCracken Sent: Thursday, December 07, 2006 6:05 PM To: Microformats Discuss Subject: Re: Re: RE: [uf-discuss] [citation] url field This seems to have been buried - so again, to anyone interested in hCite: I want to define a new field URL to denote an http URL that points to the location of a copy of the cited work. URIs that encode an identifier of the work can be combined with this field, but do not need to be. I understand that the name URL may overlap a bit with URI, and something like downloadlink, etc. might be more direct, but I argue that URL is the better choice because it is the most common name already in use in our examples from the web. Can we discuss this revised version of the proposal (or just vote on it?) Thanks, -mike ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Comments from IBM/Lotus rep about Microformats
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 write dedicate code for each new microformat will also present serious scalability problems. Finally, that there's no model at the heart of microformats with clear extension rules means that the vaunted social process here is a mess. It's all centralized, and people get frustrated when their pet property isn't included because they know what that means: the tools written for the blessed microformats won't see them. I agree with your comments. Whereas I think XML namespaces are too difficult for widespread adoption in HTML markup, I think the lack of any similar scope mechanism for Microformats and the resistance of some in the Microformat to prepare Microformats for scaling in usage and application mean that Microformats may end up being remembered as a good idea at the time but quite possibly not in use several years out. Scott Reynen wrote: I think it's just a limited goal of solving specific problems as simply as possible. If people want to solve general problems without the constraints of keeping it simple for publishers, I'd say they should do that somewhere else. I think you are creating a false dichotomy. I do agree that RDF is too difficult, but I don't think addressing the issues in another way would necessarily sacrifice ease of use. David Janes wrote: The best part about microformats (IMHO) is not the class and rel and abbr stuff, but the fact that it deliberately constrains itself to real problems that people are actually having. But only those real problems, as Bruce pointed out, that conform to some limited set of terms that only get agreed to through some tortuous process of which the vast majority of people couldn't be bothered. 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? 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 will go off and create their own and names start clashing, we'll just be left with one big mess. Most of the Microformat community seems to want to keep Microformats a tight knit club focused on a small number of use cases that reviews and approves everything, declining things they don't like, but I think there is really an obligation to the Internet at large to address how to scale the process because Microformats squat on a scare resource (names in classes.) With great power comes great responsibility; Microformats has a responsibility to the web at large to ensure Microformats can scale, but all I've seen is resistence to even consider that (which is one of the reason's I've been quiet lately.) -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ [1] http://microformats.org/wiki/Main_Page#Design_Patterns ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Comments from IBM/Lotus rep about Microformats
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 addressed? -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] [citation] url field
Andy Mabbett wrote: What about: a class= tag isbn href=http://www.example.com/wibble/71194301X; which could be a URL on the same site as the citation, or on a trusted bibliographic website. Agreed, but is there the latter? -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] [citation] url field
A couple points on this subject. I have recently been doing a *lot* of research in the area of URLs/URIs and having discussions with numerous people on REST-discuss and www-TAG lists so I feel I'm pretty well-versed on this subject now. Although it is possible to infer an ISBN or maybe even a DOI from a URL, it is considered Bad Practice unless the URI Authority (i.e. owner of the website) specifically documented the structure of the URL and gave a reasonably trustworthy guarantee that it will not change. References: 1.) Architecture of the World Wide Web, Volume One section 2.5 on URI Opacity [1]: Good practice: URI opacity Agents making use of URIs SHOULD NOT attempt to infer properties of the referenced resource. 2.) The use of Metadata in URIs section 2.1 on Reliability of URI metadata [2] Constraint: Web software MUST NOT depend on the correctness of metadata inferred from a URI, except when the encoding of such metadata is documented by applicable standards and specifications. 3.) The use of Metadata in URIs section 2.1 on Reliability of URI metadata [2] The principle conclusions of this finding are: * Assignment authorities may publish specifications detailing the structure and semantics of the URIs they assign. Other users of those URIs may use such specifications to infer information about resources identified by URI assigned by that authority. * People and software using URIs assigned outside of their own authority should make as few inferences as possible about a resource based on its URI. The more dependencies a piece of software has on particular constraints and inferences, the more fragile it becomes to change and the lower its generic utility. In the case of Jon Udel's LibraryLookup which as been referenced as an example: Data point: ISBNs are already being reliably extracted from URLs: http://weblog.infoworld.com/udell/stories/2002/12/11/librarylookup.html Jon's work has been derided by purists as doing something it shouldn't i.e. peeking into URLs when they should remain opaque. Personally, I don't see what Jon did as such a bad thing. Jon's script interfaces with a human only, and if Amazon ever changes their URLs his script just won't work and the user will figure that out. In the mean time by breaking the rules he's offering pretty useful functionality that he couldn't get otherwise. And even Amazon does changes their URLs and his script breaks, which is highly unlikely given their affiliate program, Jon can just update his script and then anyone who has a broken script can search for Jon's new version (unless Amazon eliminates the ISBN from the URL, which I would highly doubt.) However, advocating the use of non-document metadata in a URL for a Microformat citation is a completely different matter. Rather than one author (Jon Udell) using it for one app (LibraryLookup) where it's users can later get updates if required, advocating it for a Microformat where authors will markup untold HTML content, much of which will never get updated for future revisions requires a very high bar for immutability. IOW, we should ensure that we have a *guarantee* that the format of the URL will *never* or we shouldn't use it. Yes we *could* still parse the old format, but we'd have to continue adding parsers some of which might eventually fail for ambiguity. At the moment, the only immutable reference for an ISBN is a URN from RFC 3187[4]. For example: URN:ISBN:0-395-36341-1 This doesn't deference in a browser, if used in IE7 for example, but one day it might. But we can be sure it is definitely immutable. As for resolving DOIs, they are new to me and I've not done enough research to determine if there is an immutable resolvable source for DOIs. This article[5] and these websites ([6] [7]) might be helpful there. As an aside, please don't take this as me being unsupportive. On the contrary, I am a strong advocate to get website owners to put metadata in their URLs and to document that metadata. However, until we have solid sources of URLs with documented metadata, we should probably all play smartly by the rules as specified by the W3C, at least IMO. -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ [1] http://www.w3.org/TR/webarch/#uri-opacity [2] http://www.w3.org/2001/tag/doc/metaDataInURI-31-20061107.html [3] http://www.w3.org/2001/tag/doc/metaDataInURI-31-20061107.html#N1023D [4] http://www.ietf.org/rfc/rfc3187.txt [5] http://www.dlib.org/dlib/june98/06powell.html [6] http://www.handle.net/ [7] http://www.doi.org/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] [citation] url field
On Dec 1, 2006, at 3:55 PM, Bruce D'Arcus wrote: Scott Reynen If you mean why not call it URI?, Yeah, that's what I mean, and worried about collapsing the notion of URI as a name, and URL as a location. I'm skeptical we can rely on parsing a URL fo extracting a DOI/ISBN/etc. Have you looked at the ISSN URN (RFC 3044)? http://www.ietf.org/rfc/rfc3044.txt -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] RDFa vs microformats
Thanks for the article. -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andy Mabbett Sent: Saturday, November 25, 2006 10:39 AM To: Microformats Discuss Subject: [uf-discuss] RDFa vs microformats In case you missied my adding it to the 'wiki;', here's an article about RDFa vs microformats : http://evan.prodromou.name/RDFa_vs_microformats -- Andy Mabbett Say NO! to compulsory ID Cards: http://www.no2id.net/ Free Our Data: http://www.freeourdata.org.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Cite rev-reply
Hi all: I'm trying to figure out how best to use cite rev-reply in the case of replying to a commentor on a blog post. Using the example from http://microformats.org/wiki/cite-rel as a guide: In reply to cite class=rev-reply a href=http://Example.com/your-blog-annoys-me; this post/a/cite by a href=http://theRyanKing.com/; Ryan King /a. *INSERT FLAME HERE* I don't want to say that the blog post annoys me, I want to say that the commentors on the blog post annoys me. :-) Thoughts on that usage? -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ P.S. FWIW, here is the blog post: http://www.hawaiistreets.com/seoblog/?itemid=748catid=20 ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] hThing microformat ... or design pattern
=productAudi Q7 3.6 Premium/span span class=price$42,900/span (SRP: span class=srp$45,900/span ) div class=descriptionThe power, control, performance and design of the Audi Q7 3.6, enhanced with luxurious extras: a Bose Premium sound system and MMI Advanced with color screen are just the beginning./div /div /li li div class=saleable span class=productAudi Q7 4.2/span span class=price$45,900/span (SRP: span class=srp$49,900/span ) div class=descriptionA true milestone that combines unforgettable Audi performance, safety, design, and versatility with the best qualities of an SUV, including off-road capabilities, a high seating position, and interior spaciousness and flexibility. The Audi Q7 makes the impossible possible./div /div /li li div class=saleable span class=productAudi Q7 4.2 Premium/span span class=price$52,900/span (SRP: span class=srp$59,900/span ) div class=descriptionWith a host of innovative, standard extras including Rear View Camera with Acoustic Parking, Audi Side Assist, and Advanced Key, the Audi Q7/div /div /li /ul /div = From my experience of literally thousands of hours trying to taxonify product information in order to automate the business and improve the company's website, this is what I think is needed. Now I haven't tried to reconcile any of this to hlisting or anything else more than just a cursory glance. I look forward to everyone's thoughts and input. -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Aaron Gustafson Sent: Friday, November 17, 2006 7:38 PM To: Microformats-Discuss Subject: Re: [uf-discuss] hThing microformat ... or design pattern David Janes wrote: I'm not sure if I'm that excited :-) but I definitely think there's a gap that can be filled (i.e. that hReview/hListing identify people directly but only things indirectly). It's possible, but this is very speculative, that this could simplify the path for creating new microformats like hWine. I am just joining the discussion list, so forgive me if what I rehash older discussions. Craig Cook and I had been working on hProduct somewhat in isolation and thought we should post the information we've created to get our ideas and thoughts out there. I see some sililarities with what is up on hItem, though I agree hItem may be a little too broad (see the earlier 'what is an item?' comments). I'd definitely advocate for hItem including information about its creator, and optionally its producer and vendor. These of course could be hCard entries or links, and I think it would give us a flexible way to include much of the information that felt very wine specific such as Vintage (aka, producer and production date). It seems as though an hItem's production and creation could also be considered events, so reusing hEvent here seems to make a lot of sense. What do you think? Is this more complicated than it needs to be, or is the reuse of other microformats here a good thing? Let's go through the examples and see what's frequently used, somewhat used and rarely or sporadically used. That will point the right direction I think. And, as per usual, I encourage everyone to contribute to the examples because that's one of the hardest and least thanked parts. Hmm, I think we really need to boil this down to its essence. With products, unless you want to go the route niche microformats like hWine or hBook, it makes sense to stick to a few key, repeatable fields, for example: * name * description * image * msrp * uri * brand The rest could be handled by a generic property value construct which we've called 'p-v' (and may honestly have usefulness outside the hProduct/hItem concept). Also, is this ground already being covered by hListing (which seems to be looking to include some of this info), or would you simply have hListings of events (hEvent), people (hCard), and things (hItem)? The latter, but we're data mining hListing/hReview to maximize reuse. IMHO, there are a few places I think hListing (and hReview for that matter) are reaching a bit beyond what should be their scope. This is where
RE: [uf-discuss] Proposal: wine
Frances Berriman wrote: On 11/17/06, Mike Schinkel [EMAIL PROTECTED] wrote: Andy Mabbett wrote: c/f recent discussion about uF mailing lists, and my comment: For example, several academic and professional taxonomists have told me in e-mail that they would be interested in the species proposal, (and one astronomer, likewise, for mars/ luna), but do not have the time to follow a general mailing list; indeed, a couple asked me specifically if I would set up a separate mailing list for the subject. Funny how we get to have deja vi all over again, eh? ;-) Lets not (cross posting). Keep the discussion about mailing lists to the mailing list thread. What cross posting? Are you trying to say it's inappropropriate to bring up a prior discussion when it is relevant to the current discussion? -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Proposal: wine
Andy Mabbett wrote: c/f recent discussion about uF mailing lists, and my comment: For example, several academic and professional taxonomists have told me in e-mail that they would be interested in the species proposal, (and one astronomer, likewise, for mars/ luna), but do not have the time to follow a general mailing list; indeed, a couple asked me specifically if I would set up a separate mailing list for the subject. Funny how we get to have deja vi all over again, eh? ;-) -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Re: MicroFormat, Ltd.
suggest we all calm down Just for the record, I was never no calm about it. I only brought it up as something to be aware of and then several people responded that (in essense) my concerns were invalid, and I was simply replying that I disagreed and felt that it was a potential issue. I'm totally calm about it; I just felt them need to clarify things so as to be lucid about the situation. this list is *not* the place to begin throwing around legal concerns. That feels like a slap at me, so I'm going to slap back. You may feel that way, but there has been no related-guidance prior to this email. As sich I do not appreciate being chastized in a public forum for voilating your choice of how you would like things to be handled when your guidance on how to handle the situation was given in retrospect. Respectfully, -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rohit Khare Sent: Wednesday, November 08, 2006 12:08 PM To: microformats-discuss@microformats.org Subject: [uf-discuss] Re: MicroFormat, Ltd. The registered owner of the domain Umm, as the owner, I'd like to suggest we all calm down and let things lie. As the actual registrant of the domains microformats.org/com under the auspices of CommerceNet, LLC, I'm sure that any issues of our proper use of it would fall under the rubric of our continued informal support of the microformats community. (We're an independent think tank that grew out of a nonprofit membership consortium in the 90's - for more, check out our website ) But more prosaically, one of the achievements of the cooperative microformats effort is that it *has not* required a lot of 'process' -- and that, even so, this list is *not* the place to begin throwing around legal concerns. This is a public, archived forum, and without reference to the merits of anyone's points made today, this is one of the very few categories of things that I suggest should be addressed directly to me (or Tantek) before escalating to the community. Thanks, Dr. Rohit Khare Director, CommerceNet Labs (Consulting) --- Via BlackBerry ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Mailing list debate moved new proposal
You seem to assume that we want to scale. :D However, those solutions are against the grain of microformats. They'd no longer be simple, they'd no longer work together. There would be too many of them. Then I am getting more and more disenchanted with the whole MicroFormat concept. Microformats will be nowhere nearly as useful I as first assumed it to be. -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ryan King Sent: Monday, November 06, 2006 2:31 PM To: Microformats Discuss Subject: Re: [uf-discuss] Mailing list debate moved new proposal On Nov 2, 2006, at 5:37 AM, Mike Schinkel wrote: I'm going to reply to several responses at once. Why not create a new mailing list for each proposal, once it's reached a certain stage? Ryan King Because that's more administrative overhead for Ryan King admin's who're already overloaded. The problem is that the current Microformat process is not at all scalable. It is much like having you managing a file containing all domain names, and anytime someone wants a new domain name or subdomain, or make a change, they have to get your time and attention. I think we all know what a boon DNS was. We should look to benefit from prior knowledge and organize the Microformat inititive so it can scale. You seem to assume that we want to scale. :D The beauty of DNS is that you can divide up the process of minting domain names in a way that it's impossible for people to step on each other's toes. With microformats, we don't have such technology. We could use URI namespaces (which, ironically, leverage DNS), or we could do prefixing of property names or something else. However, those solutions are against the grain of microformats. They'd no longer be simple, they'd no longer work together. There would be too many of them. -ryan ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] MicroFormat Ltd
that would make it unlikely that they could sue anyone since Anybody can sue anyone for anything and hence eat up lots of lawyer bills. Whether they'd win is another subject. ;) Chris said that it is similar, and if MicroFormat Ltd's lawyer think it *might* confuse (and what lawyer's wouldn't think that when it is the most conservative option and they get to bill them to advise their client of such), they could send a cease and desist letter causing this group some pain. Anyway, either it will or will not happen; remains to be seen if it does. -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Charles Iliya Krempeaux Sent: Tuesday, November 07, 2006 12:57 PM To: Microformats Discuss Subject: Re: [uf-discuss] MicroFormat Ltd Hello, They are in an entirely different industries. From my understanding of Trademark law... that would make it unlikely that they could sue anyone since (from the law's point-of-view) there is little chance of confusion between the 2 names (since they are in different industries). (Oh yeah... IANAL. But unless trademarks law has radically changed. I think AL would say something to that effect too.) See ya On 11/7/06, Colin Barrett [EMAIL PROTECTED] wrote: Perhaps we could trademark µformat (greek-letter-mu format) and say that the term microformat is just an expansion / alternate name for it. I don't even know if that would work, IANAL. -Colin On Nov 6, 2006, at 3:36 PM, Mike Schinkel wrote: Ouch. Sounds like a trademark fight might occur, as commercial entities lawyer's tend to recommend that kind of thing... -Mike Schinkel President; Guides, Inc. http://www.guidesinc.com (404) 474-8948 (404) 276-1276 cell (404) 474-8949 fax skype: mike.schinkel [EMAIL PROTECTED] http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ http://www.linkedin.com/in/mikeschinkel -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Messina Sent: Sunday, November 05, 2006 1:01 AM To: Microformats Discuss Subject: [uf-discuss] MicroFormat Ltd Have you guys ever heard of MicroFormat Ltd? Microformat has a long and proud history of involvement in preservation microfilming, and I am wholly delighted that we have been entrusted with this most important and exacting project'. It seems fitting, for some reason, since they're into the preservation of data: http://microformat.co.uk Chris -- Chris Messina Citizen Provocateur Open Source Ambassador-at-Large Work: http://citizenagency.com Blog: http://factoryjoe.com/blog Cell: 412 225-1051 Skype: factoryjoe This email is: [ ] bloggable[X] ask first [ ] private -- Charles Iliya Krempeaux, B.Sc. charles @ reptile.ca supercanadian @ gmail.com developer weblog: http://ChangeLog.ca/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Re: MicroFormat Ltd
I highly doubt that it will cause real confusion; furthermore, who would be sued? No one owns the microformats name besides the community -- which is why it's a community mark. We really don't have any assets or formal structure, so it would be rather difficult to bring this to court. The registered owner of the domain. It would be a cease-and-desist suit, not necessarily a suit for damages. I wouldn’t contact them. -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Messina Sent: Tuesday, November 07, 2006 1:18 PM To: Microformats Discuss Subject: [uf-discuss] Re: MicroFormat Ltd I highly doubt that it will cause real confusion; furthermore, who would be sued? No one owns the microformats name besides the community -- which is why it's a community mark. We really don't have any assets or formal structure, so it would be rather difficult to bring this to court. But that's highly unlikely as it is, since their name is singular. I mean, we could do the right thing and contact them to let them know that we're not looking to encrouch and maybe we'll be rewarded with good karma... Or we could just fuggetaboutit. ;) Chris On 11/7/06, Mike Schinkel [EMAIL PROTECTED] wrote: that would make it unlikely that they could sue anyone since Anybody can sue anyone for anything and hence eat up lots of lawyer bills. Whether they'd win is another subject. ;) Chris said that it is similar, and if MicroFormat Ltd's lawyer think it *might* confuse (and what lawyer's wouldn't think that when it is the most conservative option and they get to bill them to advise their client of such), they could send a cease and desist letter causing this group some pain. Anyway, either it will or will not happen; remains to be seen if it does. -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Charles Iliya Krempeaux Sent: Tuesday, November 07, 2006 12:57 PM To: Microformats Discuss Subject: Re: [uf-discuss] MicroFormat Ltd Hello, They are in an entirely different industries. From my understanding of Trademark law... that would make it unlikely that they could sue anyone since (from the law's point-of-view) there is little chance of confusion between the 2 names (since they are in different industries). (Oh yeah... IANAL. But unless trademarks law has radically changed. I think AL would say something to that effect too.) See ya On 11/7/06, Colin Barrett [EMAIL PROTECTED] wrote: Perhaps we could trademark µformat (greek-letter-mu format) and say that the term microformat is just an expansion / alternate name for it. I don't even know if that would work, IANAL. -Colin On Nov 6, 2006, at 3:36 PM, Mike Schinkel wrote: Ouch. Sounds like a trademark fight might occur, as commercial entities lawyer's tend to recommend that kind of thing... -Mike Schinkel President; Guides, Inc. http://www.guidesinc.com (404) 474-8948 (404) 276-1276 cell (404) 474-8949 fax skype: mike.schinkel [EMAIL PROTECTED] http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ http://www.linkedin.com/in/mikeschinkel -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Messina Sent: Sunday, November 05, 2006 1:01 AM To: Microformats Discuss Subject: [uf-discuss] MicroFormat Ltd Have you guys ever heard of MicroFormat Ltd? Microformat has a long and proud history of involvement in preservation microfilming, and I am wholly delighted that we have been entrusted with this most important and exacting project'. It seems fitting, for some reason, since they're into the preservation of data: http://microformat.co.uk Chris -- Chris Messina Citizen Provocateur Open Source Ambassador-at-Large Work: http://citizenagency.com Blog: http://factoryjoe.com/blog Cell: 412 225-1051 Skype: factoryjoe This email is: [ ] bloggable[X] ask first [ ] private -- Charles Iliya Krempeaux, B.Sc. charles @ reptile.ca supercanadian @ gmail.com developer weblog: http://ChangeLog.ca/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss -- Chris Messina Citizen Provocateur Open Source Ambassador-at-Large Work: http://citizenagency.com Blog: http://factoryjoe.com/blog Cell: 412 225-1051 Skype: factoryjoe This email is: [ ] bloggable[X] ask first [ ] private ___ microformats-discuss mailing list microformats-discuss
RE: [uf-discuss] Mailing list debate moved new proposal
microformats have always been intended to simply solve common real-world problems in an 80/20 fashion. This limitation is quite deliberate, and is key to microformats being *actually* useful in the immediate/nearterm future, as opposed to *theoretically* useful in some ideal/imaginary world where boil the ocean (BTO) solutions have some how magically altered human culture and society as a whole to radically change behavior and adopt them wholesale. There is nothing in what I'm envisioning or proposing that would make them theoretical. I would just like to address more areas that it appears you want to address. -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tantek Ç elik Sent: Tuesday, November 07, 2006 1:22 PM To: microformats-discuss Subject: Re: [uf-discuss] Mailing list debate moved new proposal On 11/7/06 9:59 AM, Mike Schinkel [EMAIL PROTECTED] wrote: You seem to assume that we want to scale. :D However, those solutions are against the grain of microformats. They'd no longer be simple, they'd no longer work together. There would be too many of them. Then I am getting more and more disenchanted with the whole MicroFormat concept. Microformats will be nowhere nearly as useful I as first assumed it to be. To be clear Mike, microformats were never envisioned to solve all format problems, or metaformat problems etc. That ocean boiling is better left to many others who are pursuing those goals. microformats have always been intended to simply solve common real-world problems in an 80/20 fashion. This limitation is quite deliberate, and is key to microformats being *actually* useful in the immediate/nearterm future, as opposed to *theoretically* useful in some ideal/imaginary world where boil the ocean (BTO) solutions have some how magically altered human culture and society as a whole to radically change behavior and adopt them wholesale. http://microformats.org/wiki/microformats Thanks, Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] MicroFormat Ltd
Ouch. Sounds like a trademark fight might occur, as commercial entities lawyer's tend to recommend that kind of thing... -Mike Schinkel President; Guides, Inc. http://www.guidesinc.com (404) 474-8948 (404) 276-1276 cell (404) 474-8949 fax skype: mike.schinkel [EMAIL PROTECTED] http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ http://www.linkedin.com/in/mikeschinkel -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Messina Sent: Sunday, November 05, 2006 1:01 AM To: Microformats Discuss Subject: [uf-discuss] MicroFormat Ltd Have you guys ever heard of MicroFormat Ltd? Microformat has a long and proud history of involvement in preservation microfilming, and I am wholly delighted that we have been entrusted with this most important and exacting project'. It seems fitting, for some reason, since they're into the preservation of data: http://microformat.co.uk Chris -- Chris Messina Citizen Provocateur Open Source Ambassador-at-Large Work: http://citizenagency.com Blog: http://factoryjoe.com/blog Cell: 412 225-1051 Skype: factoryjoe This email is: [ ] bloggable[X] ask first [ ] private ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Best Practice for fn and n?
Maybe I'm missing something, but wouldn't you have to include white-space for a visible display anyway? i.e. span class=vcard span class=n fn span class=honorific-prefixMr./spannbsp; span class=given-nameJohn/spannbsp; abbr class=additional-name title=QuinlinQ./abbrnbsp; span class=family-namePublic/span,nbsp; span class=honorific-suffixM.D./span/ /span /span -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Costello, Roger L. Sent: Sunday, November 05, 2006 9:49 AM To: Microformats Discuss Subject: RE: [uf-discuss] Best Practice for fn and n? Thanks Brian. I intuitively figured there was something wrong with using an empty abbr element. In fact, my first attempt was to do just as you suggest. However, I realized that there is a problem with that. Namely, when all the values are concatenated together we get this value for fn: Mr.JohnQ.PublicM.D. That is, no space between the parts. One solution would be to add a space after each part: span class=vcard span class=n fn span class=honorific-prefixMr. /span span class=given-nameJohn /span abbr class=additional-name title=QuinlinQ. /abbr span class=family-namePublic /span, span class=honorific-suffixM.D./span/ /span /span Then the concatenation of the values will yield the desired fn: Mr. John Q. Public, M.D. However, I don't like that solution either, because now the given name is John , rather than John, and the family name is Public , rather than Public. This extra whitespace could be a killer for tools that do value-added hCard services. Any suggestions on how to solve this problem? /Roger -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brian Suda Sent: Sunday, November 05, 2006 9:13 AM To: Microformats Discuss Subject: Re: [uf-discuss] Best Practice for fn and n? Having empty elements is a bad idea. TIDY will outright remove empty abbr/ elements, plus it goes against Human-readablity. For all the same reasons META elements get state, empty inline elements will get state as well. Why not just use class=n fn, you are displaying all of the 'n' data inside your empty 'abbr', so why not just remove the 'abbr' and move the class='fn' to the same data as the class='n' span class=vcard span class=n fn span class=honorific-prefixMr./span span class=given-nameJohn/span abbr class=additional-name title=QuinlinQ./abbr span class=family-namePublic/span, span class=honorific-suffixM.D./span/ /span /span On 11/5/06, Costello, Roger L. [EMAIL PROTECTED] wrote: Hi Folks, Here is some HTML text that I want to markup using the hCard fn and n properties: Today's speaker is Mr. John Q. Public, M.D. I propose marking it up in this fashion: Today's speaker is span class=vcard abbr class=fn title=Mr. John Q. Public, M.D. / span class=n span class=honorific-prefixMr./span span class=given-nameJohn/span abbr class=additional-name title=QuinlinQ./abbr span class=family-namePublic/span, span class=honorific-suffixM.D./span/ /span /span Notice that I am using an empty abbr element to store the value for fn. Is this sensible? Is there a better way to markup the HTML text? Is this Best Practice? /Roger ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss -- brian suda http://suda.co.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Mailing list debate moved new proposal
I just don't want to be checking a mailing list, wiki AND a forum. On that point I've proposed integrating the mailing list AND the forum, to give people the option of which of the two to use. So you wouldn't have to check all three. -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Frances Berriman Sent: Friday, November 03, 2006 4:15 AM To: Microformats Discuss Subject: Re: [uf-discuss] Mailing list debate moved new proposal On 11/3/06, Benjamin West [EMAIL PROTECTED] wrote: If people want to filter things out, or draw particular attention to a thread being related to a specific proposal, using the [hCard] notation (for example) works quite well in the subject field. I concur. Filtering features are well supported on many of the mail clients I've seen, and a simple filter with the convention of tagging threads with square brackets would probably work fine. I like simple solutions. :) To be honest, I just don't want to be checking a mailing list, wiki AND a forum. Selfish, selfish of me. -- Frances Berriman http://fberriman.com ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Mailing list debate moved new proposal
Colin: I'm going to reply to you point for point because, frankly after reading your reply I felt like you were dredging up excuses, not reasons and I just feel compelled to challege your assertions. To the rest of you, please feel free it ignore the rest of my email if you would rather not be bothered with this issue. I'd love to see a forum but could live without one too. But I just couldn't help myself but go into pedantic mode given his arguments. ;) Perhaps you should try a different email client, then? So you are suggesting that I should change the application I spend 60% of my business day which meets many other needs besides just email so that I may accomodate your dislike for a forum? I wouldn't actually think you'd want to impose that on someone else, but it rather sounds that way. The only reason I say Often, is because the version of Safari I'm using allows you to resize text entry elements. I don't follow your reasoning. I use a vBulliten based forum every day and it's torture. I really dislike forums, but the people and issues I discuss on the forum outweigh my dislike of forums. To-may-to, To-mah-to. Er, I know that was meant as a joke, but calling someone you're trying to win to your side a luddite isn't the best way to do so. You mean there was more than a 0.1% chance I'd change your mind? Mailing list vs. forum is a religion just like Windows vs. Linux or Mac, REST vs SOAP, Java vs. .NET, Perl vs. Python. Conservative vs. Liberal. (US) Republican vs. Democrat. Christianity vs. Islam vs. Judiasm. And so on. There is rarely rational thought involved when discussing those kind of issues. So, I had zero expectation of converting you at all; I was making arguments for the rest of the list participants. Anywho, as has been said many times before; best not to take personal offense at what people say on the list because its far too easy to misinterpret. I've frequently had to count to 100 before typing, and I just joined recently. Can I *reply* from it? I'm pretty sure the answer is no, and the composing interface of my email client is much nicer. If you have an email client that accepts HTML mail and the admin configures the forum for that you can. Sure. User names. I hate them. Theyr'e tolerable on IRC, but in an area as permanent and public as a mailinglist/forum I'd rather have my full name associated with my (and others) posts, especially a technical discussion. It's a chore to keep track of remembering what crazy nick name corresponds to which person. I agree with you. That's why I have a policy on a forum I administer for my condo community that everyone uses real names. And I also have the same policy here: http://wiki.welldesignedurls.org/The_Rules There's nothing that says we couldn't (and shouldn't) have the same policy for a Microformats forum. Mailing lists also allow you to use an already established identity -- your email. On a forum, you have to create a completely new web presence and identity. I don't see why one would have to create a completely new identity. I almost always use MikeSchinkel or Mike Schinkel as applicable except in the rare cases I want to be anonymous. Not so helpful for John Smith, but for most of us it's not an issue. You can link it to your other ones with signatures and profiles, etc, but still, it's another login and another identity. Vs. another mailing list subscription to manage. To-may-to, To-mah-to. The above username/identity debacle a pretty huge one, and probably my number one complaint. Maybe we are getting some where; has my real name policy not addressed your concern? BBcode is a secondary one. It's awful. I hate having to deal with [quote] tags. Chevrons for quoting is so easier. Plain text email for the win. If you use the quote button instead of the reply button vBulletin quotes it for you. That said you can always use the same style quoting on a forum as you do in email if that your style. I find quoting in email much more or a PITA because I have to quote every line instead of just the begin and end of the quote. And if the person quoting is not careful (and who is?) the quotes will be too long and then you get an absolutely visual mess which is almost impossible to read. What's more, mailing list is plain text and makes it infinitely harder to present information in a understandable form than on a forum where you have lots of formatting options. And vBulletin has an optional WYSIWYG editor now so BBCode's not an issue. It also costs money. Who's going to pay for that? vB $85? Are you for real? $85 is pocket change for almost anyone with the technical skill to be active on this list. I'm currently unsure who my next client or revenue source will be (long story; after 12 years running Xtras.Net, I need a break and am being very selective), and *I'd* pay for the damn thing if that's what it took. is also not exactly slim in the markup it generates. Who would pay
RE: Re: [uf-discuss] Mailing list debate moved new proposal
Chris: I mean, once you're into personal preferences, Just a point of note, I brought my preferences up only to show that there were counter preferances and that one-sided preferences shouldn't be the driving factor. Which was a much more verbose way of saying what you just said. But rather than host it all here on the microformats-discuss list, there's no reason why folks can't go off and start their own efforts, as others have (see: Social Media Club). You are right, there is no reason people can't, but respectfully I think it's not a good idea for them or for the Microformats initiative. There would be a HUGE duplication of effort, and I don't mean related to technical work; I mean related to the branding and marketing and PR of the proposed new efforts. I think haven't splinter groups would also potentially confuse the web development public for which 99% have yet to learn of Microformats. Mindshare and attention are in finite supply and any similar initiatives would take away from the mindshare and atttention related to Microformats. For example, if we had two oor three other groups vying for media attention (or eventually 50+ other groups) then the Microformat message could easily get diluted, obscured, or become invisible. And for splinter groups we'd have no control how they position themselves and/or we'd have to pay lawyers to tell them to stop using the Microformat term if we didn't like how they were using it. And on and on and on. So I think it would be much much better to scale up the process so that lots of people can involved all under the marketing and PR of the Microformat brand. And frankly I don't think it would be that hard to manage. It would primarily take specifying a process by which these other groups get formed and what activity and quality they need to achieve and then maintain, and then som ongoing monitoring. Chris, don't get me wrong; I respect your opinion greatly. I can see how your idea seemed good at the time, but don't you now agree that it could be a minefield of unexploded IEDs? Hopefully you see my point now, and concur? -Mike P.S. BTW, I've been advocating vBulletin, but I also have a Community Server forum up and running RIGHT NOW that also (could) integrate with a mailing list (I'd have to buy the add-on first) and we could use it for those who like forums, everyone else would be unaffected assuming we all agree. The forum us located at http://www.MashupTalk.com and I plan to get it going in the near future. Having a section on Microformats would fit perfectly into it's mission. What do you think? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Messina Sent: Friday, November 03, 2006 4:44 AM To: Microformats Discuss Subject: Re: Re: [uf-discuss] Mailing list debate moved new proposal Wow. This thread spiraled into nowhere land quickly. I mean, once you're into personal preferences, you know that you're never going to win. Some prefer email, some forums, some RSS -- hell -- it's just the *display* of data. Thank g*d we separated those two a long time ago so that people can have their way! (Just for notes, Google Groups Beta is kind of the ideal merger of forums, email and RSS, if you haven't tried it yet). Anyway, let me throw out something controversial to steer this back. So there's been discussion about creating new lists for every new microformat that's proposed. Well, that sounds like a very fractious action, that could really undermine the authority of the group. Or not. But rather than host it all here on the microformats-discuss list, there's no reason why folks can't go off and start their own efforts, as others have (see: Social Media Club). I'm not advocating the splitting of the community, but I am advocating for folks to see to their own desires, interests and verticals and take the model, spirit and goals of microformats and strike out on your own and work to get your own microformats adopted. Because it's true, this form of dialogue doesn't scale well -- and the only way to advance is to farm out the work to distributed nodes in the system, let them focus hard and work hard, and then return back with their findings, implementations and/or adoptions. No one's stopping you. As far as I'm concerned, have at. Chris On 11/3/06, Frances Berriman [EMAIL PROTECTED] wrote: On 11/3/06, Benjamin West [EMAIL PROTECTED] wrote: If people want to filter things out, or draw particular attention to a thread being related to a specific proposal, using the [hCard] notation (for example) works quite well in the subject field. I concur. Filtering features are well supported on many of the mail clients I've seen, and a simple filter with the convention of tagging threads with square brackets would probably work fine. I like simple solutions. :) To be honest, I just don't want to be checking a mailing list, wiki AND a forum. Selfish, selfish of me. --
RE: [uf-discuss] Mailing list debate moved new proposal
list integration module (http://www.vbulletin.org/forum/showthread.php?t=65152) so we could have the best of both worlds. The envelope pushers could have their forum, and the lluddites could stick with email. ;-) Colin Barrett Plus, the UI in my email client is much nicer than that of most forums. vBulletin can be configured to send posts to your email, so you'll be able to still use your email client for reading if you like. Colin Barrett There are a host of other Colin Barrett disadvantages to using a forum. Can you detail those disadvantages for us to discuss/debate? Colin Barrett Granted, mailing lists aren't perfect, but we have one now and it works. A vBulletin forum can be set up in a two hours max. I'll run it if that's an option so it would only be my time. Colin Barrett Forums also require a bit more administration Colin Barrett than a mailing list, and our list administrators Colin Barrett are already over-worked, it seems. How does it take more admin? I administer a vBulletin forum right now and it takes almost no time at all. You don't have to worry about issues with POP3 and SMTP so it IMO is actually easier. -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Internet Explorer 8.0 will support microformats
I've got a question about this. To say IE8 will support Microsformats doesn't make sense to me, unless they means it will support the Microformats agreed to at the point IE8 is made feature complete. But what about those that come after? Or, is this saying that IE8 will have a capability to process Microformats abstractly so that new ones can be added after IE8 has shipped? And if that is possible, wouldn't it make sense for us as a group to go ahead and specify a standard way to define that abstraction? -Mike Schinkel http://www.mikeschinkel.com/blog http://www.welldesignedurls.org/ P.S. If this makes no sense it's because I haven't had enough sleep lately... :) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Messina Sent: Sunday, October 29, 2006 8:52 PM To: Microformats Discuss Subject: [uf-discuss] Internet Explorer 8.0 will support microformats FYI: http://factoryjoe.com/blog/2006/10/29/internet-explorer-80-will-support-micr oformats/ ;) Chris -- Chris Messina Citizen Provocateur Open Source Ambassador-at-Large Work: http://citizenagency.com Blog: http://factoryjoe.com/blog Cell: 412 225-1051 Skype: factoryjoe This email is: [X] bloggable[ ] ask first [ ] private ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] how do i submit something for consideration?
Charles, Funny, I've been planning to write a blog post entitled something like What's the one thing wrong with Open-Source? Forking! :) -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Charles Iliya Krempeaux Sent: Thursday, October 26, 2006 4:45 PM To: Microformats Discuss Subject: Re: [uf-discuss] how do i submit something for consideration? Hello Jonathan, (This does NOT have anything to do with the Microformats aspect of it, but) Just out of curiousity, why the No Derivative part for the license for the specification? (To be open wouldn't anybody need to be able to make derivatives, and not just one person or more group of people?) Here's a good article on openness and specifications... http://goland.org/buyingopenstandards (I'd probably go further than this article... but it's a good start.) See ya On 10/26/06, Jonathan Vanasco [EMAIL PROTECTED] wrote: Hi. I've recently soft-launched a distributed identity webapp that I've split out of another project, and released several aspects of that application as open standards ( Creative Commons Attribution-No Derivative Works 2.5 License ) I don't know how / where to submit it for potential consideration as a microformat , or even if they qualify ( one supports human readable , but is geared to be machine readable ; the other is more of an interchange format , but works well as semantic markup ) - so I came here. The summaries: findmeon design: essentially a subset of XML-DSIG with some FOAF / XFN semantics tossed in , and coerced to validate in XHTML strict designed for machine readability , but supports human readability (90% of content would usually be hidden though) unfortunately must support a non-standard 'compressed' url- encoding to let it clear as validated text on several social networks and forum software ( required because certain tags/attributes were often stripped ) usage: openly claim / verify / link multiple websites together via RSA 1024 public key pairings within a distributed self-sufficient framework hopefully will end proprietary 'i own this blog/whatever' codes designed so that resources do not need to know about one another or a central server in order to be linked/verified by a public key originated from: a need to map artist/label/venue/etc information on a music site to official sites / online profiles ; map users of a music site onto other sites for verifiability in trading concert tickets or making online requests / contest entries specification status: the current release works as it should, so any feedback/changes would be merged into a future release open_sn design: a dirty dirty hack standardizes the most common social network / dating site / online account profile fields that do not natively appear in existing specifications its really quite a bad 'standard' -- but it serves its purpose primarily designed as an interchange format, but works pretty well in terms of semantic markup usage: mostly an interchange format for migrating data between accounts specification status: very much open for immediate improvement / replacement. its a dirty dirty hack. The full text / description of both standards are available at http://findmeon.org I'd welcome any feedback. Thanks, // Jonathan Vanasco | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - | FindMeOn.com - The cure for Multiple Web Personality Disorder Web | Identity Management and 3D Social Networking | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - | RoadSound.com - Tools For Bands, Stuff For Fans Collaborative Online | Management And Syndication Tools | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -- Charles Iliya Krempeaux, B.Sc. charles @ reptile.ca supercanadian @ gmail.com developer weblog: http://ChangeLog.ca/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] include-pattern support for data outside of the current page? [Was: Visible Data...a Microformat requirement?]
Is it good for the interpretation of the data on one page to rely on data on another page? anyone has an opinion? My knee-jerk reaction is that it is very bad practice to have what would essentially be the legend to be on a separate page. Very, very bad. When I use to teach programming, one of the things I always pointed out was that proximity increases maintainability. This is kinda similar. (Of course I'm open to someone explaining a use-case and/or rationale for this situation that I had not previously considered.) -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Guillaume Lebleu Sent: Thursday, October 26, 2006 2:23 PM To: Microformats Discuss Subject: [uf-discuss] include-pattern support for data outside of the current page? [Was: Visible Data...a Microformat requirement?] The thread around invisble microformats reminded me of this example from the visible Web. Maybe relevant to this discussion, if not relevant to the include-pattern. An index page (http://www.eia.doe.gov/emeu/international/oilprice.html) contains currency information that applies to all pages it indexes. For instance, in this data page (http://quotes.ino.com/exchanges/?r=NYMEX_CL), there is no unit/currency defined, and we only know the numbers are U.S. Dollars per barrel b/c it was defined in the separate page we came from. Should my data page contains an include-pattern link to the currency definition from the other page? Is it good for the interpretation of the data on one page to rely on data on another page? anyone has an opinion? I'm asking since I haven't seen on the include-pattern page any clear direction on this. Guillaume ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Visible Data...a Microformat requirement?
Because it hasn't gone through the (fairly rigorous) demands of the uF process -- the process page on the wiki[1] outlines this. But what I'm hearing is that if it's not visible it cannot go through that process... -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Colin Barrett Sent: Thursday, October 26, 2006 1:38 PM To: Microformats Discuss Subject: Re: [uf-discuss] Visible Data...a Microformat requirement? On Oct 26, 2006, at 7:28 AM, Andy Mabbett wrote: In message [EMAIL PROTECTED], Dr. Ernie Prabhakar [EMAIL PROTECTED] writes As long as you don't call it a microformat, feel free to experiment. :-) Why shouldn't he call it a microformat? Because it hasn't gone through the (fairly rigorous) demands of the uF process -- the process page on the wiki[1] outlines this. -Colin [1] http://microformats.org/wiki/process ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Visible Data...a Microformat requirement?
Yes I was joking, but in the sense of Many a truth said in jest. In my 20+ years in the tech industry I don't think I've a group of people who can be more religious than those discussing technical matters, excepting fundamentalists in any real religion. :) And because religions tend to promote absolutes, they create lots of problems and impede the forward progress of pragmatists. Thus I was trying to make a point without being too pointed. ;) -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andy Mabbett Sent: Thursday, October 26, 2006 1:28 PM To: Microformats Discuss Subject: Re: [uf-discuss] Visible Data...a Microformat requirement? In message [EMAIL PROTECTED], Mike Schinkel [EMAIL PROTECTED] writes cardinal sin Is this a pragmatic group that I'm working with, or a bunch of religious zealots that I've managed to get entangle with? [assuming you're not joking] cardinal in this sense means: essential; of foremost importance; paramount and cardinal sin is a common idiom. See, for example: http://www.answers.com/cardinalr=67 -- Andy Mabbett Say NO! to compulsory ID Cards: http://www.no2id.net/ Free Our Data: http://www.freeourdata.org.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Visible Data...a Microformat requirement?
that is *only* for machine consumption Conversely, if he's unsure whether the metadata *has* to be invisible, then perhaps this is still a worthwhile discussion. For clarity, there is nothing that says that the metadata I was proposing and am additionally envisioning couldn't be visible. It might even become a best practice to make it visible. But in current practice today the data typically isn't visible (if it is there, which is unlikely) and some people might not want to make it visible (probably because they have a pre-Web 2.0 mentality, IMO.) However, if the end result is *outside* the scope of how we as a community understand microformats, don't expect to get a lot of official support Without support, it make little sense to do it, which IMO means creating a parallel initiative which is duplicated effort, will confuse the public, and is just not a good idea all round. But if I can't convince the group that it makes sense, I certainly can't berate the group into doing it. So if I get a consistent no then that's that (kinda funny how in the early days of the web everyone wanted to splinter. :) In particular, it would be confusing for him to call his proposal a microformat if it did not go through the documented microformat process Agreed. -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dr. Ernie Prabhakar Sent: Thursday, October 26, 2006 1:38 PM To: Microformats Discuss Subject: Re: [uf-discuss] Visible Data...a Microformat requirement? Hi Andy, On Oct 26, 2006, at 10:28 AM, Andy Mabbett wrote: In message [EMAIL PROTECTED], Dr. Ernie Prabhakar [EMAIL PROTECTED] writes As long as you don't call it a microformat, feel free to experiment. :-) Why shouldn't he call it a microformat? Sorry, I may have conflated too many issues. The point I wanted to make (which I communicated poorly) is: a) If he's committed to marking up *invisible* metadata that is *only* for machine consumption, then [IMHO] that's beyond the scope of what this group was constituted to do. b) Conversely, if he's unsure whether the metadata *has* to be invisible, then perhaps this is still a worthwhile discussion. c) Either way, he's welcome to experiment with microformat-derived ideas d) However, if the end result is *outside* the scope of how we as a community understand microformats, don't expect to get a lot of official support e) In particular, it would be confusing for him to call his proposal a microformat if it did not go through the documented microformat process http://microformats.org/wiki/process I apologize if that came across as needlessly confrontational. Best, -- Ernie P. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Visible Data...a Microformat requirement?
My suggestion to use invisible data formats was prefaced with the scenario that your data is invisible, based on the subject of this thread. The above criteria seem to contradict the subject of this thread. If that is the case, I apologize. I envision several different needs although not all of them are fleshed out yet. And these are not needs I just think people might have, they are needs that I've envision I will need in order to optimize some projects I have planned. Is the data published on the web today or not? If it is, you should start collecting it and analyzing to see if it's suitable for a microformat. It is possible. I'm doing tons of research right now (killing many trees printing off documents at the W3.org and elsewhere). But maybe not. If it's not published, we can't research the publishing, so we'd be creating a microformat based on assumptions. The example I gave is straightforward, and respectfully I don't think there would be a lot of assumptions. Let me give another example for this use-case (although I'm learning there may be existing things in HTML to resolve this one specific use case.) Consider these three URLs: http://www.foo.com/toyota/4runner/1999/ http://www.foo.com/toyota/1999/4runner/ http://www.foo.com/1999/toyota/4runner/ Assuming they point to the same basic content but have different breadcrumbs: Home Toyota 4Runner 1999 Home Toyota 1999 4Runner Home 1999 Toyota 4Runner However, there really are the same page and I'd like to be able to say that one of them is the primary or authoritative one (the website owner would decide which one) and in the two that are not primary or authoritative they would point to the one that is. It's possible that you could have the following visible on the page: This page is a duplicate of a href=http://www.foo.com/toyota/4runner/1999/; rel=primarywww.foo.com/toyota/4runner/1999//a. As I said, this is but one example of data that helps describe a page that I can envision I will need and that I believe could benefit the web in general if it exists. I wish I had fleshed out my other examples at this point but I haven't yet, and I certainly don't want to get the shot down because I present them prematurely prepared. -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Reynen Sent: Thursday, October 26, 2006 1:46 PM To: Microformats Discuss Subject: Re: [uf-discuss] Visible Data...a Microformat requirement? On Oct 26, 2006, at 3:07 AM, Mike Schinkel wrote: I'm still not convinced. I've only heard generalities and no specifics on anything I've heard regarding my use-case. RDF is far to complicated for the average person creating HTML; one reason why I don't think it will ever fly. I still know of nothing else besides Microformats that can fill this role; can you give me some specifics that: * Is very simple to add * Doesn't require access to head * Can be done today My suggestion to use invisible data formats was prefaced with the scenario that your data is invisible, based on the subject of this thread. The above criteria seem to contradict the subject of this thread. Is the data published on the web today or not? If it is, you should start collecting it and analyzing to see if it's suitable for a microformat. If it's not published, we can't research the publishing, so we'd be creating a microformat based on assumptions. Such an assumption-based process doesn't meet the standards we've been applying to the word microformat. We're not changing that standard because we, as a community, believe that basing formats on existing behavior is an important practice. There are other formats that are based on assumptions, and the complication you don't like is largely a result of that practice. Pick your poison. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Visible Data...a Microformat requirement?
Your always welcome to use HTML class name semantics or other microformat-inspired technologies in your private applications. However, that is a different thing that calling it a microformat and engaging this whole group in vetting and supporting it. If you think this could be a great solution to an existing problem, I encourage to just go ahead and implement it. As long as you don't call it a microformat, feel free to experiment. :-) Well, why I'd prefer not to go it alone is for the very fact of not having the whole group in vet and support it... -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dr. Ernie Prabhakar Sent: Wednesday, October 25, 2006 6:44 PM To: Microformats Discuss Subject: Re: [uf-discuss] Visible Data...a Microformat requirement? Hi Mike, Your always welcome to use HTML class name semantics or other microformat-inspired technologies in your private applications. However, that is a different thing that calling it a microformat and engaging this whole group in vetting and supporting it. If you think this could be a great solution to an existing problem, I encourage to just go ahead and implement it. As long as you don't call it a microformat, feel free to experiment. :-) - Ernie P. On Oct 25, 2006, at 3:15 PM, Mike Schinkel wrote: Thanks Charles. However I still have no idea why these things apply to specifying which page among of group of equivalent pages is authoritative and why Microformats do not. The latter seem a perfect fit to me, and what you listed either don't apply to general web pages, are years off and can't be used today, are not related, or don't provide the features needed. The microformat concept would work perfectly for this (and similar problems.) -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Charles Iliya Krempeaux Sent: Wednesday, October 25, 2006 5:58 PM To: Microformats Discuss Subject: Re: [uf-discuss] Visible Data...a Microformat requirement? Hello Mike, XML, Semantic HTML, and RDF are closely related to what is being done here. But there's alot of other technologies for specific areas. Like with multimedia type thigns we have SMIL, XSPF, etc etc. For databases like things we have CSV, TSV, HTML tables, etc etc. (Obviously I'm not going to try to enumerate every area and every technology... but hopefully this will give you an idea.) ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Visible Data...a Microformat requirement?
Scott: I'm still not convinced. I've only heard generalities and no specifics on anything I've heard regarding my use-case. RDF is far to complicated for the average person creating HTML; one reason why I don't think it will ever fly. I still know of nothing else besides Microformats that can fill this role; can you give me some specifics that: * Is very simple to add * Doesn't require access to head * Can be done today -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Reynen Sent: Wednesday, October 25, 2006 7:31 PM To: Microformats Discuss Subject: Re: [uf-discuss] Visible Data...a Microformat requirement? On Oct 25, 2006, at 5:15 PM, Mike Schinkel wrote: Thanks Charles. However I still have no idea why these things apply to specifying which page among of group of equivalent pages is authoritative and why Microformats do not. The latter seem a perfect fit to me, and what you listed either don't apply to general web pages, are years off and can't be used today, are not related, or don't provide the features needed. The microformat concept would work perfectly for this (and similar problems.) I think the key difference is the subject of this thread. Microformats are good for visible data. Other formats are good for invisible data. Most of what Charles listed is in wide use today. You just don't see it because it's not on the visible web. If the data you want to describe is also not on the visible web, it's probably more appropriate for one of these invisible data formats. Consider reuse of the data. Microformats have less invisible reuse potential because they don't fit a general schema like RDF or XSD. But microformats have more visible reuse potential because, well, the data is visible. If your data is invisible and you tried to format it with microformats, you'd be losing both invisible reuse potential and visible reuse potential. You can pound that nail with a screwdriver, but why would you? Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Mailing list debate moved new proposal
Andy Mabbett Why not create a new mailing list for each proposal, once it's reached a certain stage? I tend to really like this proposal. I've been thinking about if and how Microformats can evolve and grow. I can see Microformats being potentially much larger helping to create tags in many different areas vertical but the current process can't scale. For example, if someone might want to create microformats to identify auto parts but I'm sure there are thousands of other areas too. How can we keep up with them all? It seems that having a central registry for approving subject areas and then creating a list for that area could grow microformats exponentially. Of course then the question becomes, how to avoid conflicts. I would suggest that every microformat should have a unique name, and then within that Microformat the subclasses would be free of namespace collisions. And maybe having a well-known prefix like uf- so that general microformats could be referred to within other Microsformats: span class=auto-parts div class=sku12345/div div class=manufacturerMopar/div div class=descriptionExhaust System/div div class=uf-money abbr class=symbol title=USD$/abbr span class=amount199/span /div /span This was just off the top of my head, but I wanted to get the discussion started... I will close with a quote from Tantek[1] quoting and commenting on Weaving the Web by TBL: WTW Chapter 12 page 175 We could allow a set of working groups that can be shown to form a tight self-reliant cluster to secede and form a new peer clone consortium. ... anyone could start a consortium, when the conditions were right, by pushing a few buttons on the Web page of a virtual consortium factory This is a fascinating set of ideas. But why a peer consortium? The W3C did not start as a peer to those that came before it. I think if anything, we'll see the tiniest of efforts, that start quite small, and perhaps stay small, or perhaps slowly grow into something that could be said to be a peer. -Mike [1] (http://tantek.com/log/2003/0813t1158.html) ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Visible Data...a Microformat requirement?
Thanks Charles. However I still have no idea why these things apply to specifying which page among of group of equivalent pages is authoritative and why Microformats do not. The latter seem a perfect fit to me, and what you listed either don't apply to general web pages, are years off and can't be used today, are not related, or don't provide the features needed. The microformat concept would work perfectly for this (and similar problems.) -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Charles Iliya Krempeaux Sent: Wednesday, October 25, 2006 5:58 PM To: Microformats Discuss Subject: Re: [uf-discuss] Visible Data...a Microformat requirement? Hello Mike, XML, Semantic HTML, and RDF are closely related to what is being done here. But there's alot of other technologies for specific areas. Like with multimedia type thigns we have SMIL, XSPF, etc etc. For databases like things we have CSV, TSV, HTML tables, etc etc. (Obviously I'm not going to try to enumerate every area and every technology... but hopefully this will give you an idea.) ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Visible Data...a Microformat requirement?
Search engines make use of shingles to identify pages and their aliases. What's a shingle? As far as I can tell, this isn't in the same class of problems that microformats solve. Is there a clear and definitive objective statement that explains the class of problems that microformats are intended to solve? Further, if there is such a statement, is there a reason to limit Microformats to only be used to solve that class of problems when they otherwise can solve additional problems? This probably best resolved by agreeing what we mean by metadata, Because of judicious editing required by forum policy, I've lost the prior of the discussion so I'm not sure the context in which I mentioned metadata. -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Benjamin West Sent: Monday, October 23, 2006 2:01 PM To: Microformats Discuss Subject: Re: [uf-discuss] Visible Data...a Microformat requirement? So, what if your take on this problem and use-case? Search engines make use of shingles to identify pages and their aliases. Some search engines employ teams of editors and solicit feedback from the web community to ensure their aliasing techniques are correct. As far as I can tell, this isn't in the same class of problems that microformats solve. This probably best resolved by agreeing what we mean by metadata, as the scope of definition and contents of that term seem to be somewhat disputed and/or misunderstood as well as the scope of the problem space of microformats. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
