Timestamps are in UTC.
[[hatom]] M http://microformats.org/wiki?title=hatom&diff=0&oldid=3632 * RobertBachmann * (+128) Implementations -
hober is Edward O'Connor and works for EVDB on http://eventful.com/
Atamido is Paul Bryson, http://orangeman.commo.de/
fuzzyBSc is Benjamin Carlyle, http://soundadvice.id.au/blog/
There is no way to move a technorati-registered blog from one url to another, is there?
hober is Edward O'Connor and works for EVDB on http://eventful.com/
[[xoxo]] M http://microformats.org/wiki?title=xoxo&diff=0&oldid=3633 * Tantek * (+70) Discussions -
[[xoxo]] M http://microformats.org/wiki?title=xoxo&diff=0&oldid=3634 * Tantek * (+0) Discussions -
Hello
RobertBachmann is in Austria
RobertBachmann is in Austria
?forgetme
I have expunged RobertBachmann from my mind
fuzzyBSc is Benjamin Carlyle, http://soundadvice.id.au/blog/
Happy New Year, folks.
Happy New Year!
though I've still have 7 hours and 44 minutes of 2005 ;-)
:)
It is already 1:23am, here.
I'll be interested to see what comes out of the mfo discussions. It's unclear if anyone is ready to make a decision about namespace clashes yet, or if they care enough... I think hAtom needs to clear this issue quickly though. I will not be able to put as much into it after this coming week. I'll be back from holiday and working on SCADA systems.
Robert: Have you heard from Luke, lately?
Is there anything on your radar that needs getting done?
I have thought about attacking the rel-tag implementation to make it conform. I would have been adding test cases for more disabiguation requirements, except I have had some discussions with David via email that suggest some may be removed.
No, I haven't heard form Luke, seems like he's offline for whatever reason.
I'm currently working on xml:base, will test it within the next 15 minutes.
The next features I'd like to add:
- $source-uri (this isn't very problematic from the XSLT side, but I need to figure out how to pass XSLT params to MSXML and System.Xml)
- $feed-id ... selects a feed by its HTML id attribute
rel-tag handling improvment sounds good.
What disambiguation rules might be removed?
btw. do you like to have commit access to my svn repository?
Robert: I'll have a play with things and see how I go. I haven't used svn before and will see what works best...
Robert: Currently we only implement title disabiguation as per spec. Disambiguation rules also exist for permalink, published, and updated. David said this was because he had seen these elements repeated, but I suggested that only one need be tagged with the hAtom class.
I'll write it up on -issues to make sure it doesn't get lost in the noise.
regarding svn, read access is available for anybody (via http and https) For commit access (via https) you need a user and password. I'll create one.
[[hatom-issues]] http://microformats.org/wiki?title=hatom-issues&diff=0&oldid=3635 * FuzzyBSc * (+719) Add excess disambiguation rules
Ok, Robert.
do you have a PGP key or shall I email the password as plain-text?
Robert: I don't have a publicised key. I could generate one if you would like some extra security.
Maybe I should start getting into that :)
yes, I think it's time for 'apt-get install gpg' ;-)
Hrrm.. that's right. I put it onto my usbdisk at some point. It isn't there now. I guess I'll really have to generate a new one...
RobertBachmann: it's always time for apt-get install gnupg
Frederic: sure
Ok. Talking, now :)
Robert: I have mailed you what I hope is my public key ;)
ok, I've sent you the password
[[hatom-issues]] http://microformats.org/wiki?title=hatom-issues&diff=0&oldid=3636 * FuzzyBSc * (+961) Content and summary opaqueness
[[hatom-issues]] M http://microformats.org/wiki?title=hatom-issues&diff=0&oldid=3637 * FuzzyBSc * (+37) Make previous update understandable by native english speakers...
Thanks, Robert.
My xml:base code passes the test. The only exception is .net's System.Xml which has the urge to add xp_0:xmlns="http://www.w3.org/XML/1998/namespace" into the result tree.
Robert: So I <code>svn co http://rbach.priv.at/repos/hatom/hatom2atom.xsl/trunk/ .</code>
Then I make my changes... do an svn merge before finally doing a svn ci?
hober is Edward O'Connor and works for EVDB on http://eventful.com/
I've never used svn with other people just.
s/just./just alone./
ok :)
I'm looking at having a play with bzr for my next project. Revision control fun all around.
Unfortunately most of my recent experience has been with proprietary CM systems.
I've never used any SCM until the last month ;-)
[[blog-post-formats]] M http://microformats.org/wiki?title=blog-post-formats&diff=0&oldid=3638 * Tantek * (+17) RSS 2.0 -
Wow :)
I was actually started out a build manager at the employer I am with now. Luckily I proved my worth about six to twelve months in and have been developing software proper since then.
It is sort of a ritual of fire, unfortunately. You sort have have the job until you can find someone to replace you ;)
actually we did some sort of revision control in my former school. We named the files like this FILENAME-REVISION.SUFFIX ;-)
[[blog-post-formats]] M http://microformats.org/wiki?title=blog-post-formats&diff=0&oldid=3639 * Tantek * (+403) Syndication Feed Formats -
[[blog-post-formats]] M http://microformats.org/wiki?title=blog-post-formats&diff=0&oldid=3640 * Tantek * (+142) Journal Formats -
[[blog-post-formats]] M http://microformats.org/wiki?title=blog-post-formats&diff=0&oldid=3641 * Tantek * (+0) Discussion Participants -
:)
Coordination between different individuals and different groups is always the challenge.
Robert: I'm going to try doing a commit of the changes to rel-tag support.
Hrrm...
svn: CHECKOUT of '/repos/hatom/!svn/ver/11/hatom2atom.xsl/trunk/hAtom2Atom.xsl': 403 Forbidden (http://rbach.priv.at)
I supplied both username and the password you sent me.
MacDome is a WebKit engineer who hacks on XML, XHTML, XSLT and SVG
try again please.
Robert: I get the same message.
Am I checked out against the right place? It is trunk I should be using, isn't it?
Hmm. Work and commit are very similar to svn, so far so good.
greetings
Morning, Tantek :)
fuzzyBSc: you must use https for write access
Robert: Bingo.
I had to check out again and reapply my changes against the https url.
I'll write up my rel-tag experience in hAtom-issues
Ok. I did a svn update and will have a look at your changes
[[hatom-issues]] http://microformats.org/wiki?title=hatom-issues&diff=0&oldid=3642 * FuzzyBSc * (+881) Update rel-tag issue with current hAtom2Atom.xsl findings
I've commited the code for handling xml:base
I think we need some additional test cases for xml:base and xml:lang
Robert: I have been trying to do test-driven development, i.e. first fill out the additional test cases that will be required for a unit of work, then make the hAtom2Atom.xsl changes required.
I'll try to put a test case together now.
fuzzyBSc: regarding test-driven development. That's a very cool attitude. I'll do that too. I've already added a little test for xml:base to tests/supportedElements.html, however since wrong xml:bases could cause a lot of trouble I'll look into producing some test more test cases especially for xml:base handling.
I meant: I'll look into producing some more test cases ;-)
Robert, fuzzy, did either of you get my latest emails to the discuss list? (sent this morning)
Tantek: I read them about half an hour ago.
So you're saying that the one definition rule still applies, correspondance to atom terminology is not relevant, and more research needs to be done which will ideally locate non-clashing terminology in rss or other predecessor technology...
Tantek: Read them 15 minutes ago.
I think there are still only two examples of hAtom terms that are defined separately in other microformats. I am not knowledgeable in a wide range of them, so there may be more I am not aware of.
The title<->summary confusion is likely to be the hardest for atom-inclined publishers to figure out. If "summary" exists in hAtom but means "atom:title", and we need another term to cover atom:summary it could be confusing.
I have not looked too much into rss, but my understanding is that it did not have separate summary and content concepts. I don't know if digging there will yield better results.
I haven't looked into VJOURNAL at all.
To speak freely: I don't think the hCard definition of title is the most widely-understood meaning for title in the publication world. I think it will be a thorn in the side of every microformat from here until kingdom come :) Part of me is still hoping for a reprieve ;)
_fil_ is co-author of SPIP (www.spip.net) and works on implementing microformats in it
fuzzy, the title<->summary confusion is actually not likely to occur in practice on the *web*
do you know of any examples of websites which publish both summaries and full content on the same page?
BBC does: http://news.bbc.co.uk/2/hi/europe/4568012.stm
re: emails. Hmm.. it seems I am not receiving the emails since this morning.
Tantek: Well, yes that is documented (although I haven't looked up the examples). Apparently it is reasonably common to just javascript to do a "read more..." link. summary and content would actually overlap there, I would have thought.
... but what I was referring to is someone who is familiar with atom and wants to write hAtom. They would no doubt find it confusing that "summary" meant "title" and something else meant summary. That is all.
Robert: I have committed a combined test case for the xml:base and xml:lang features, and updated hAtom2Atom.xsl to meet the new pass criteria.
What is your intention for the titles test case. I notice you have a large portion of it commented out.
fuzzy, there are fewer people familiar with atom than other formats
Tantek: So what do you see as the path forward to an official microformat? Do we attempt to resolve the naming issues and integration with existing microformats first, or do we attempt to clear the other hAtom issues and come back to this one?
we should work to resolve all issues in parallel
as much as possible
fuzzyBSc: I need to comment out this parts because multiple root elements are prohibited by XML and therefor cause troubles with xmldiff.
the naming issues are certainly important
Tantek: Hrrm.. this is true. Despite the hype both before and since its launch atom is still relatively underimplemented.
yet more important are resolving the holes I pointed out
holes in research are a bigger problem
fuzzy, right
hence the need to do thorough background documentation of RSS, VJOURNAL and any other older standards
yes
one thing to keep in mind re: atom vs. hAtom authors, once we have solidified hAtom, it is quite likely that hAtom may become the largest source of Atom on the web
for the same reasons that hCard is becoming the largest source of vCards on the web
and so forth
it's easier to author/publish than a separate file with a separate mime-type etc.
thus it is more important for microformats to get things right, than it was for various independent/individual XML formats
I see it that way too. If hAtom were ready to be publicised and rolled out within the next few months it would be reasonable to ask the question "why implement an atom feed when you can implement the hAtom feed?"
yes
i'm confident we can work through the issues fairly quickly
Ok. I'll raise the specific summary & title issues on hAtom-issues. I think the spec is currently at the stage where generalisations about which element names should be used are not useful, but I would encourage anyone who has specific input to record it for orderly resolution. I'll try to get an email out also.
I still wish title wasn't reserved by hcard, though ;)
fuzzy, btw, these principles have been documented for some time in the process document
naming things is one of the hardest things to do well, especially in the context of existing work
and even then, especially in the context of several existing works
BTW, my understanding of the Atom process for naming was to pick the names that made the most sense on their own in Atom. There was no attempt (AFAIK) to reuse names of elements or properties from existing standards.
Thus it should not surprise us that hAtom will likely have different names than Atom, since hAtom, as a microformat, is focussed on reusing pre-existing names, whereas Atom did not.
Ideally the most widely-applicable and understood meaning of a term would be the one that is widely used, but microformats are intended to shape this process of understanding anyway.
If the process is successful, the microformat definitions will be the understood ones.
[[hatom-issues]] http://microformats.org/wiki?title=hatom-issues&diff=0&oldid=3643 * FuzzyBSc * (+295) Add title and summary reservation issues
Tantek: How is the mfo process going? Have you been able to pull a few people into involvement with it?
By the way, do you have an answer on the relationship between hAtom terms and hReview terms? Specifically, should hAtom use "dtreviewed" instead of "published" or perhaps tread a middle line and use "dtpublished"? Should it use "reviewer" instead of "author"?
I also wouldn't mind if you could comment on the rel-tag issues on hatom-issues. Should a reverse-encoding be attempted?
fuzzy, the question between hAtom and hReview could be asked differently
consider that hReview properties were derived from hCard and hCalendar
thus, contrast hAtom with hCard and hCalendar directly
which reveals the need to do research on VJOURNAL, since that is part of hCalendar
make sense?
Ahh. I didn't have that connection in my head before.
I'm having a go at filling out the rss 2.0 structure now. I'll see if I can dig up data on VJOURNAL afterwards.
thanks fuzzy, that will help a lot!
Hello Tantek
and Happy new year
(other people too)
Hello Frederic
Happy New Year to you!
at least in 3 hours or so right?
those of us in California still have 12 hours to go
FYI, <card> and <calendar> (merging hCard and hCalendar into HTML5) are slated for late february
Yeah, just 3 hours, but my wife has prepaired a good meal, and I don't think she'll be very happy to see me speding new year's eve on IRC like I did 2 years ago
so I send my wishes now
Happy New Year!
Hixie, good to know
Fuzzy, Robert - the emails finally came through to me, I'll followup on David Janes' latest email
tantek: of course, that's assuming that i'm still alive by then. Slated for January 2006 is "define how to parse HTML", which i think is as likely to drive me to suicide as anything.
Hixie, please feel free to add issues you run into to hcard-issues and hcalendar-issues as you run into them - don't wait until the last second.
hCard is pretty darn finalized
yup, already raised the issues i know about
I still have some work to do on hCalendar, specifically the supporting documents like -profile, -parsing, etc.
cool, thanks Hixie.
the -parsing is the one i'm mostly worried about :-)
the semantics will be pretty simple, i'll just defer to v*
[[blog-post-formats]] http://microformats.org/wiki?title=blog-post-formats&diff=0&oldid=3644 * FuzzyBSc * (+1783) Add RSS 2.0 structure
My concentration is flagging a little (I'll be off to bed soon), so I think some of the numbers might be out... but the basic RSS structure is in place now.
It has been 2006 for six and a half hours where I'm standing ;)
I have provided a full profile. "required and recommended" would have left rss 2.0 with only four elements. rss 2.0 does very little of either.
Hixie: Could some of our favourite uf css classes become html elements?
it's on the table
fuzzy, thanks for the RSS2 structure docs!
fuzzy, Hixie, in my opinion we may need more real world experience with some of our favorite microformat class names (note: they are *HTML* class names, not css classes ;) before considering adding them to HTML5.
totally
i'm doing some research into this, hope to publish something next week
research into what?
class names and other real world use of html
did you see John Allsopp's lengthy research and blog post on use of class and id in the wild?
yeah
ok, cool.
BTW, I'd suggest doing the research on a wiki page, so that others can add to it and build on it
e.g. perhaps /wiki/class-name-examples
you mean putting the results on a wiki page?
yeah, could do
yes
even "in progress" work as well
just mark it as such
yes, well
no reason to not edit it in the open right?
you'd think
cool
unfortunately, it's not that simple when you're at a big company
but we'll see
[[blog-post-formats]] http://microformats.org/wiki?title=blog-post-formats&diff=0&oldid=3645 * FuzzyBSc * (+1284) Fill out VJOURNAL structure and example
Hixie, you've pointed out one big reason why I'm not at a big company
:-)
ref: recent blog post about web dev opening at Technorati
it'd be easier if everyone wasn't on holiday right now :-)
(google is remarkably good at not having politics and red tape, but if everyone's absent, it makes things harder)
i'd be interested to hear your perspective on their "culture of secrecy" some time.
i'm afraid i can't talk about that
LOL
my opinion is that before i was at the company, i thought it was silly, but now that i'm at the company, i realise that actually google is very open about a lot of things (e.g. see the papers on code.google.com), and that the things they actually keep secret are things that are kept secret for good reason.
(and inside the company, there are basically no secrets)
er, s/code.google.com/labs.google.com/
Hixie, the evidence I have seen (e.g. GoogleBase), indicates that the secrecy is actually causing them to make technical mistakes, such as poor design decisions, ignoring previous work, etc.
imagine if GoogleBase (and the various Atom extensions etc.) had been design out in the open, rather than behind closed doors and then launched all at once.
yeah, i strongly believe that standards should be developed in the open
google's paying me to develop HTML5 in the open :-)
right. i knew that. :) hence why i asked your opinion.
oh, that's good sign of change.
i don't know much about google base, i'm still learning about everything google's doing. as and when i come across things that should be done in the open, i'm trying to do something about it
mind you, i'm in the open source group at google, so i've probably got a biased opinion of how open we are, since everything i hear about directly is specifically open stuff
Good. Keep doing good open work and perhaps you can fix things from the inside.
trying :-) the company culture here is very much in line with doing things "right", it's mostly a matter of people being new to something and thus not knowing what "right" is that causes mistakes, imho
we'll see
if you do hear of any things (like the atom extensions stuff) do let me know
now i must go play board games
ttyl
ok, ttyl
might want to let them know that Atom 1.0 is an RFC now, and that they can stop using Atom 0.3 ;)
[[blog-post-formats]] http://microformats.org/wiki?title=blog-post-formats&diff=0&oldid=3646 * FuzzyBSc * (+1948) Expand VJOURNAL data
factoryjoe is Chris Messina, works for Flock, Bar Camp and Rhyzomatic and is working towards open source world domination
[[hatom-issues]] http://microformats.org/wiki?title=hatom-issues&diff=0&oldid=3647 * FuzzyBSc * (+209) Add Dependancies section
Night, all.
[[hatom-issues]] http://microformats.org/wiki?title=hatom-issues&diff=0&oldid=3648 * Kevin Marks * (+494) rel-tag -
[[hatom-issues]] http://microformats.org/wiki?title=hatom-issues&diff=0&oldid=3649 * FuzzyBSc * (+61) Create title suggestion list
[[hatom-issues]] http://microformats.org/wiki?title=hatom-issues&diff=0&oldid=3650 * FuzzyBSc * (+196) Suggest description as nomenclature for atom:summary
greetings
Did folks see the XOXO blog?
http://blogxoxo.blogspot.com/
does anyone know Stephen Paul Weber ? http://singpolyma-tech.blogspot.com/2005/12/xoxo-blog-and-template.html
bkdelong is B.K. DeLong, Head Research Analyst for HALO Worldwide - http://www.haloworldwide.com. Web: http://www.brain-stream.com. Email: bkdelong@pobox.com - Is At ApacheCon
hey i'm wondering what the benefit of microformats would be over some sort of open API?
do they serve the same purpose?
well, they can be orthogonal
microformats give a way of standardising structures
so your API coudl return microformats
or you may find that using microformats on your main HTML pages, and using REST URLs for your site can mean you don't need an API
as in generating your HTML you are generating the structures an API would return
would there be any benefit to both? like a soap api that returns xml markup and using appropriate microformating on all the generated pages?
well XHTML is XML
megasquid, APIs come and go. Data persists. Thus formats are orders of magnitude more important than APIs. The best APIs are the ones that simply get and put well formatted data. E.g. REST.
Programmer's tend to focus on designing APIs because that's their touch-point, that's where their code interacts with the "outside world".
s/Programmer's/Programmers
ok, well i'm looking to design a web app, where other web apps can access and catalog the info, so i'm trying to weigh the benefits between microformts and an api
it's not a vs.
it seems like microformats are good for crawlers and presentation
by just using microformats on your pages, you essentially present a very simple "default" API
then if you want more complex APIs for the 10% cases, you can design those
as needed
but just by using microformats in the data you are already presenting, you handle perhaps 80% of the use cases
that folks would otherwise have for an API
so it comes down to laziness/efficiency
right
microformats for you, might be the easiest/fastest means to a simple API for your website/webservices
Tantek: lets say for instance, that I had a site like amazon, and I wanted people to be able to access product title's and the url of that product, so they could be cataloged and organized in any particular way, but for the full description the url would take them to the actual page, wouldn't an api serve a better purpose here?
[[hatom-issues]] http://microformats.org/wiki?title=hatom-issues&diff=0&oldid=3651 * Kevin Marks * (+270) summary reserved by hReview -
megasquid, it still sounds like you are comparing things that are not comparable
your question: "wouldn't an api serve a better purpose here?"
implies "better than what?"
the REST approach would say the only API you need in that case is a GET API
then all that remains is defining the *format* of the data/content that is returned
and that's where microformats come in
These logs were automatically created by mflogbot on chat.freenode.net using a modified version of the Java IRC LogBot.
See http://microformats.org/wiki/mflogbot for more information.