From bsittler at gmail.com Fri Jun 1 08:48:20 2007 From: bsittler at gmail.com (Ben Wiley Sittler) Date: Fri Jun 1 08:48:24 2007 Subject: [uf-dev] hAtom atomic tests In-Reply-To: <4EA50F3A-4E40-4FED-9D29-4B410D262224@technorati.com> References: <4EA50F3A-4E40-4FED-9D29-4B410D262224@technorati.com> Message-ID: On 5/31/07, Ryan King wrote: > On May 30, 2007, at 5:11 PM, Ben Wiley Sittler wrote: > > > nice! i have tried a few of the tests, and intend to try more. > > > > i notice the tests use the same interpretation of "concatenation" as > > hAtom2Atom.xsl, but that's an issue for discussion on the list and/or > > wiki, not a bug. > > A number of the tests were written to support hAtom2Atom.xsl and may > have some extensions or misinterpretations. Currently (personally) > only endorse the atomic tests (those whose filenames start with 'a0x-'). [snip] ah, great. the others use some non-specced extensions like .title for feed-level title. there is no such beast in hAtom at the moment, although i suspect that if there were it would be .feed-title to avoid conflict with hCard, with a fallback to the first h# in the feed, and a further fallback to page title. -ben From kevinmarks at mac.com Fri Jun 1 23:26:39 2007 From: kevinmarks at mac.com (Kevin Marks) Date: Fri Jun 1 23:26:45 2007 Subject: [uf-dev] hAtom atomic tests In-Reply-To: References: Message-ID: <080E6A7B-5ABA-430A-A4EC-0D71653CB8C4@mac.com> On May 30, 2007, at 10:47 AM, Ryan King wrote: > As hinted at by a previous email[1], I'm starting to organize our > test suite into something with a bit more structure. > > hAtom is currently on my plate for implementation, so I'm focusing > on that. I just pushed a changeset[2] to the mercurial respository > that adds some atomic tests for hAtom [3]. > > Please give feedback if you have any suggestions for improvements. > > -ryan > > 1. http://microformats.org/discuss/mail/microformats-dev/2007-May/ > 000325.html > 2. http://hg.microformats.org/tests? > cmd=changeset;node=ef2a531a19ac;style=gitweb > 3. Atomic tests for hAtom were actually pretty hard to write. > Atomic tests should be as simple and isolated as possible, but it > turns out that Atom has some non-trivial requirements for creating > valid documents. Have a look at Mark Pilgrim's test suite; if you have atom2hAtom, that could be a big source http://feedparser.org/tests/wellformed/atom10/ From ryan at technorati.com Sun Jun 3 00:35:58 2007 From: ryan at technorati.com (Ryan King) Date: Sun Jun 3 00:36:02 2007 Subject: [uf-dev] hAtom atomic tests In-Reply-To: <080E6A7B-5ABA-430A-A4EC-0D71653CB8C4@mac.com> References: <080E6A7B-5ABA-430A-A4EC-0D71653CB8C4@mac.com> Message-ID: On Jun 1, 2007, at 11:26 PM, Kevin Marks wrote: > On May 30, 2007, at 10:47 AM, Ryan King wrote: > >> As hinted at by a previous email[1], I'm starting to organize our >> test suite into something with a bit more structure. >> >> hAtom is currently on my plate for implementation, so I'm focusing >> on that. I just pushed a changeset[2] to the mercurial respository >> that adds some atomic tests for hAtom [3]. >> >> Please give feedback if you have any suggestions for improvements. >> >> -ryan >> >> 1. http://microformats.org/discuss/mail/microformats-dev/2007-May/ >> 000325.html >> 2. http://hg.microformats.org/tests? >> cmd=changeset;node=ef2a531a19ac;style=gitweb >> 3. Atomic tests for hAtom were actually pretty hard to write. >> Atomic tests should be as simple and isolated as possible, but it >> turns out that Atom has some non-trivial requirements for creating >> valid documents. > > Have a look at Mark Pilgrim's test suite; if you have atom2hAtom, > that could be a big source > > http://feedparser.org/tests/wellformed/atom10/ Having atom2hAtom would be nice, but it doesn't exist yet because that's kinda what we're trying to define right now. -ryan From tantek at cs.stanford.edu Mon Jun 18 11:06:43 2007 From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik) Date: Mon Jun 18 11:05:22 2007 Subject: [uf-dev] Re: [uf-new] Microformats parsing, in general (was: hAudio final draft) In-Reply-To: <9610F3D3-5473-4BC8-ADAB-023FDE017610@makedatamakesense.com> Message-ID: On 6/17/07 12:55 PM, "Scott Reynen" wrote: > So we're left choosing > between two microformat principles that don't work well together in > practice. We could get them to work together by continuing that MFO > discussion, but then we'd be conflicting with yet another principle: > solve a specific problem. So which principle do we discard here? This is likely to be precisely why we may need to solve this problem by continuing the mfo discussion. If you look at the current known alternatives: 1. require parsers to update whenever new nestable microformats are introduced, and precisely define rules for handling known/common nesting cases (to at a minimum avoid wasting time on straw-man arguments). 2. add a new class name to indicate a encapsulation scope (e.g. "mfo") when embedding - = one new class name, only in cases where nesting occurs. 3. replicate/prefix property class names for each microformat e.g. audio-fn - = numerous new class names It is pretty clear that #3 is the worst from a complexity (most new class names) that would affect the most people (publishers) point of view. So we should seek to avoid #3 since that violates the principles the most. #2 adds some incremental authoring complexity in some cases. #1 is something that we can probably still do today since both the number of microformats is small (a good reason to keep the overall number small), and the number of parser implementations is small and parser implementers are both involved in the community and able to update their code quite quickly ( cc'ing microformats-dev accordingly). Therefore it is reasonable IMHO to: Pursue #1 in the short term until we have solved #2 in the medium term. Tantek From tantek at cs.stanford.edu Mon Jun 18 15:18:53 2007 From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik) Date: Mon Jun 18 15:17:14 2007 Subject: [uf-dev] Re: [uf-new] Microformats parsing, in general (was: hAudio final draft) In-Reply-To: <21e770780706181427h3ca95a3fi5a4eee885abbd9cf@mail.gmail.com> Message-ID: (moving largely parsing discussion to microformats-dev, microformats-new bcc'd) On 6/18/07 2:27 PM, "Brian Suda" wrote: > On 6/18/07, Tantek ?elik wrote: >> This is likely to be precisely why we may need to solve this problem by >> continuing the mfo discussion. > > --- Part of the reason the MSO discussion died is because it didn?t MFO > actually solve anything. No it helps abstract when to stop looking into a node for property values. Full stop. Nothing more, nothing less. >> If you look at the current known alternatives: >> >> 1. require parsers to update whenever new nestable microformats are >> introduced, and precisely define rules for handling known/common nesting >> cases (to at a minimum avoid wasting time on straw-man arguments). > > --- i do NOT like this alternative because it makes the assumption > that you WANT the data to be two different things. For instance, if i > have a URL as a child of hCard. Then the common parsing rules might > say, when that hCard is a location of an hCalendar ignore the URL, but > what happens when i WANT that URL to be part of the hCalendar - this > leads to incorrect assumptions. That case "when you want the URL (of the hCard) to be part of the hCalendar" - I assert is *way* less than 20%. If you think this is a real issue, let's start with at least one concrete example you have seen where this is true. > I would rather let the PUBLISHER be as > explicit as they want or not, rather than parsers attempt to > interpret their intents. I agree with that methodological statement, yet perhaps we are coming to two different conclusions. >> 2. add a new class name to indicate a encapsulation scope (e.g. "mfo") when >> embedding >> - = one new class name, only in cases where nesting occurs. > > --- The problem with MSO is something like the following: MFO > - hCalendar > -- location (MSO) > --- hcard > ---- URL This is a false strawman example. MFO is only for root microformat class names, not for arbitrary properties. e.g. class="vcard mfo", NOT class="location mfo". second example snipped for same false assumption. > From what i remember MSO didn?t actually solve anything, it just > created more problems. This is why IMHO it was never persued any > further than just a thought. No it wasn't pursued due to lack of time, and lower priority than other pursuits. >> 3. replicate/prefix property class names for each microformat e.g. audio-fn >> - = numerous new class names >> >> It is pretty clear that #3 is the worst from a complexity (most new class >> names) that would affect the most people (publishers) point of view. So we >> should seek to avoid #3 since that violates the principles the most. > > --- each microformat can also defined its parsing rules. For instance, > hAtom only looks for rel-tag NOT inside an hentry. there is no reason > that a media format can?t define that an FN can ONLY be taken when it > is NOT a child of an hCard, but then this limits the way people can > publish. These specific parsing rules are already part of the #1 option I mentioned. >> #2 adds some incremental authoring complexity in some cases. > > --- i am against MSO, it is un-needed, adds complexity and doesn?t > actually solve much. Based on the misspelling and false strawman examples, I think you may be against something that is not being proposed. >> #1 is something that we can probably still do today since both the number of >> microformats is small (a good reason to keep the overall number small), and >> the number of parser implementations is small and parser implementers are >> both involved in the community and able to update their code quite quickly ( >> cc'ing microformats-dev accordingly). >> >> >> Therefore it is reasonable IMHO to: >> >> Pursue #1 in the short term until we have solved #2 in the medium term. > > --- i think this can be fixed without either of these options. If we > spend the time actually examining real data in the wild, i think we > will find that many of these theoretical issues will either disappear, This is a good approach of course. > or we will have some exact examples that we can further explore and > encode the rules in the format itself rather than trying to work with > any of the above options... Hence why I prefer pursuing #1 first as well. > #1 doesn?t sit well with me because it causes an exponential code > growth and potential to introduce more and more bugs. Not necessarily. I don't believe the assertion of required exponential code growth. I'm optimistic that patterns that emerge will solve a lot of this. > Each format simply represents data, which can be divisible from each > other. If there are hCards on the page, that is simply people data - > no matter what it is nested in - i should be able to extract them > independently of their scope. Agreed. > Introducing constraints i think makes > things more complex, so i think this should be avoided. In general yes we are trying to minimize complexity. Sometimes it is difficult to avoid adding complexity *somewhere* and thus the key point in this discussion is where to put necessary added complexity. Thanks, Tantek From connolly at w3.org Mon Jun 18 16:01:25 2007 From: connolly at w3.org (Dan Connolly) Date: Mon Jun 18 16:01:31 2007 Subject: [uf-dev] Microformats parsing, in general (was: hAudio final draft) In-Reply-To: References: Message-ID: <1182207685.6367.12.camel@pav> On Mon, 2007-06-18 at 11:06 -0700, Tantek =?ISO-8859-1?B?xw==?=elik wrote: [...] > If you look at the current known alternatives: > > 1. require parsers to update whenever new nestable microformats are > introduced, and precisely define rules for handling known/common nesting > cases (to at a minimum avoid wasting time on straw-man arguments). > > 2. add a new class name to indicate a encapsulation scope (e.g. "mfo") when > embedding > - = one new class name, only in cases where nesting occurs. > > 3. replicate/prefix property class names for each microformat e.g. audio-fn > - = numerous new class names > > > It is pretty clear that #3 is the worst from a complexity (most new class > names) that would affect the most people (publishers) point of view. So we > should seek to avoid #3 since that violates the principles the most. > > > #2 adds some incremental authoring complexity in some cases. > > > #1 is something that we can probably still do today since both the number of > microformats is small (a good reason to keep the overall number small), and > the number of parser implementations is small and parser implementers are > both involved in the community and able to update their code quite quickly ( > cc'ing microformats-dev accordingly). > > > Therefore it is reasonable IMHO to: > > Pursue #1 in the short term until we have solved #2 in the medium term. Well, perhaps. I don't like #1. I don't have much tangible argument against it, but it puts a burden on me (as a parser implementor) that I'm not convinced to take on. If other implementors take on that burden and work out all the details, I'll perhaps reluctantly comply. On the other hand, I find #2 appealing and I'm inclined to put effort into it. I think that authors are willing to jump thru a certain number of hoops if that's what it takes to get the tools to do what they want, and they'll likely find the mfo burden acceptable. -- Dan Connolly, W3C http://www.w3.org/People/Connolly/ From davidjanes at blogmatrix.com Mon Jun 18 16:39:39 2007 From: davidjanes at blogmatrix.com (David Janes) Date: Mon Jun 18 16:39:43 2007 Subject: [uf-dev] Microformats parsing, in general (was: hAudio final draft) In-Reply-To: <1182207685.6367.12.camel@pav> References: <1182207685.6367.12.camel@pav> Message-ID: <21e523c20706181639lc46ef6age67d2df341f01c0f@mail.gmail.com> On 6/18/07, Dan Connolly wrote: > I don't like #1. I don't have much tangible argument against it, but > it puts a burden on me (as a parser implementor) that I'm not convinced > to take on. If other implementors take on that burden and work out > all the details, I'll perhaps reluctantly comply. > > On the other hand, I find #2 appealing and I'm inclined to put > effort into it. I think that authors are willing to jump thru > a certain number of hoops if that's what it takes to get the > tools to do what they want, and they'll likely find the mfo > burden acceptable. I've been mulling through the various options and I have to say #2 is the most appealing to me also. Consider, for example, a parser that understands hListing [1] and in particular the field "summary". Now let's say we invent a new microformat hNew that also uses "summary" as a field. Now, an author can embed hNew in hListing, but obviously there's no clear way for the pre-hNew parser to know "summary" associated with hNew and not hListing hListing * hNew ** summary <- confusion I think MFO -- which says microformats _above_ the mfo-node shouldn't look for fields _under_ the node -- handles it quite clearly: hListing * hNew mfo ** summary <- hListing does not see summary (assuming it understands mfo) I have other related suggestions -- BLOCKQUOTE and Q are always "mfo", hCard and hCalendar are always mfo -- but they can wait. Regards, etc... David [1] http://mail.google.com/mail/ -- David Janes Founder, BlogMatrix http://www.blogmatrix.com http://blogmatrix.blogmatrix.com From derrick at pallas.us Mon Jun 18 18:35:45 2007 From: derrick at pallas.us (Derrick Lyndon Pallas) Date: Mon Jun 18 18:35:45 2007 Subject: [uf-dev] Microformats parsing, in general In-Reply-To: <1182207685.6367.12.camel@pav> References: <1182207685.6367.12.camel@pav> Message-ID: <467732F1.3090102@pallas.us> Dan Connolly wrote: > On Mon, 2007-06-18 at 11:06 -0700, Tantek ?elik > wrote: > >> 2. add a new class name to indicate a encapsulation scope (e.g. "mfo") when >> embedding >> - = one new class name, only in cases where nesting occurs. >> > On the other hand, I find #2 appealing and I'm inclined to put > effort into it. I think that authors are willing to jump thru > a certain number of hoops if that's what it takes to get the > tools to do what they want, and they'll likely find the mfo > burden acceptable. > For what it's worth, this issue comes up about every six months and the solution has always been that #1 is the best solution in the short term because it causes the least problems for authors. Personally --- being someone that's written a parser and uses it on a daily basis --- I am unwilling to take on the burden of knowing all future formats and sub-properties of existing formats. I am very interested in pursing #2, just as I was six months ago. Perhaps the best course of action is to work toward codifying "mfo" as a pattern and Best Practice (but not a Requirement) in the short term so that it is able to gain any adoption it might be due in the long term. If it doesn't gain any adoption, then it is probably a non-issue anyway but at least it's not a required pattern. That should both stifle the issue six months from now and make current authors and parsers happy. Respectfully (and still lurking) ~Derrick From tantek at cs.stanford.edu Tue Jun 19 10:46:53 2007 From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik) Date: Tue Jun 19 10:45:21 2007 Subject: [uf-dev] Re: [uf-new] Microformats parsing, in general (was: hAudio final draft) In-Reply-To: <21e523c20706190714g1b82cff7kb7efee0e521eee63@mail.gmail.com> Message-ID: moving *parsing* discussion to microformats-dev, microformats-new bcc'd. please see http://microformats.org/wiki/mailing-lists for which topics are better for which lists. On 6/19/07 7:14 AM, "David Janes" wrote: > On 6/19/07, Manu Sporny wrote: >> This is the heart of the problem. >> >> The Microformats community has adopted two mutually exclusive philosophies: >> >> 1. Scope-less approach to parsing. > > This is why I've been picking at this like a scab for the last week. I > don't think we've adopted #1 at all. "scope-less" is a mischaracterization and false. For example, root class names have always been used to indicate the root of a compound microformat. e.g. see: http://microformats.org/wiki/hcard-parsing Tantek From davidjanes at blogmatrix.com Tue Jun 19 15:04:41 2007 From: davidjanes at blogmatrix.com (David Janes) Date: Tue Jun 19 15:04:45 2007 Subject: [uf-dev] Re: [uf-new] Microformats parsing, in general (was: hAudio final draft) In-Reply-To: References: <9610F3D3-5473-4BC8-ADAB-023FDE017610@makedatamakesense.com> <21e770780706181427h3ca95a3fi5a4eee885abbd9cf@mail.gmail.com> <96F26828-9C64-4441-8873-4C37F8BE117B@makedatamakesense.com> <4677E343.2070902@digitalbazaar.com> <21e523c20706190714g1b82cff7kb7efee0e521eee63@mail.gmail.com> Message-ID: <21e523c20706191504l4a1ad899sd44dc2ed513feaf6@mail.gmail.com> On 6/19/07, Scott Reynen wrote: > On Jun 19, 2007, at 8:14 AM, David Janes wrote: > > >> 1. Scope-less approach to parsing. > >> 2. Requirement to heavily re-use class names. > > > > This is why I've been picking at this like a scab for the last week. I > > don't think we've adopted #1 at all. > > I'm publishing a website with events marked up in hCalendar. Each > event has attendees, marked up in hCard. The attendees have URLs, > but the event does not. How do I limit the scope of an hCard URL to > the contact (and not the event)? Here's a real world example of this > problem: > > http://playinghere.com/2007/07/21/LA/New_Orleans/The_Parish/ > > As far as I can tell, the current answer is that I can't do that, and > it's not a big deal because the contact URL is somewhat relevant to > the event. But as a publisher, I don't like that I can neither > control nor predict how my events will be parsed. [moved to microformats-dev] As briefly mentioned earlier in the thread -- I think hcard and hcalendar should probably always be mfo, which would deal with this problem. Even if they weren't, you could explicitly mark them as "mfo" Regards, etc... -- David Janes Founder, BlogMatrix http://www.blogmatrix.com http://blogmatrix.blogmatrix.com From scott at randomchaos.com Tue Jun 19 15:55:30 2007 From: scott at randomchaos.com (Scott Reynen) Date: Tue Jun 19 15:55:42 2007 Subject: [uf-dev] Re: [uf-new] Microformats parsing, in general (was: hAudio final draft) In-Reply-To: <21e523c20706191504l4a1ad899sd44dc2ed513feaf6@mail.gmail.com> References: <9610F3D3-5473-4BC8-ADAB-023FDE017610@makedatamakesense.com> <21e770780706181427h3ca95a3fi5a4eee885abbd9cf@mail.gmail.com> <96F26828-9C64-4441-8873-4C37F8BE117B@makedatamakesense.com> <4677E343.2070902@digitalbazaar.com> <21e523c20706190714g1b82cff7kb7efee0e521eee63@mail.gmail.com> <21e523c20706191504l4a1ad899sd44dc2ed513feaf6@mail.gmail.com> Message-ID: On Jun 19, 2007, at 4:04 PM, David Janes wrote: >> >> 1. Scope-less approach to parsing. >> > >> > This is why I've been picking at this like a scab for the last >> week. I >> > don't think we've adopted #1 at all. >> >> How do I limit the scope of an hCard URL to >> the contact (and not the event)? > > As briefly mentioned earlier in the thread -- I think hcard and > hcalendar should probably always be mfo, which would deal with this > problem. > > Even if they weren't, you could explicitly mark them as "mfo" I'm a bit confused by this thread now, but it seems we agree that the current inability of publishers to indicate scope is a problem, and MFO is a potential solution. Is that correct? If so, I think we need to openly discuss the semantics of MFO (i.e. follow the process) before we get into a more limited discussion of how to parse MFO. I don't think it's ready to parse at all yet, so I'm not sure why it's on -dev. Peace, Scott From davidjanes at blogmatrix.com Tue Jun 19 16:05:36 2007 From: davidjanes at blogmatrix.com (David Janes) Date: Tue Jun 19 16:05:38 2007 Subject: [uf-dev] Re: [uf-new] Microformats parsing, in general (was: hAudio final draft) In-Reply-To: References: <9610F3D3-5473-4BC8-ADAB-023FDE017610@makedatamakesense.com> <21e770780706181427h3ca95a3fi5a4eee885abbd9cf@mail.gmail.com> <96F26828-9C64-4441-8873-4C37F8BE117B@makedatamakesense.com> <4677E343.2070902@digitalbazaar.com> <21e523c20706190714g1b82cff7kb7efee0e521eee63@mail.gmail.com> <21e523c20706191504l4a1ad899sd44dc2ed513feaf6@mail.gmail.com> Message-ID: <21e523c20706191605v7d145893r8ef6e86716cc59f5@mail.gmail.com> On 6/19/07, Scott Reynen wrote: > I'm a bit confused by this thread now, but it seems we agree that the > current inability of publishers to indicate scope is a problem, and > MFO is a potential solution. Is that correct? If so, I think we > need to openly discuss the semantics of MFO (i.e. follow the process) > before we get into a more limited discussion of how to parse MFO. I > don't think it's ready to parse at all yet, so I'm not sure why it's > on -dev. I moved my response to -dev since that's where Tantek tried to move it earlier, twice I believe, and I don't see any particular reason to disagree that. MFO is only particular potential solution for a bigger problem which you'll have to trace back through this discussion thread to read. Briefly, there's problems reusing uF elements because they could potentially be incorrectly associated with the wrong semantic object. Regards, etc... -- David Janes Founder, BlogMatrix http://www.blogmatrix.com http://blogmatrix.blogmatrix.com From tantek at cs.stanford.edu Tue Jun 19 16:42:40 2007 From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik) Date: Tue Jun 19 16:40:59 2007 Subject: [uf-dev] Re: [uf-new] Microformats parsing, in general (was: hAudio final draft) In-Reply-To: <21e523c20706191605v7d145893r8ef6e86716cc59f5@mail.gmail.com> Message-ID: On 6/19/07 4:05 PM, "David Janes" wrote: > On 6/19/07, Scott Reynen wrote: >> I'm a bit confused by this thread now, but it seems we agree that the >> current inability of publishers to indicate scope is a problem, and >> MFO is a potential solution. Is that correct? If so, I think we >> need to openly discuss the semantics of MFO (i.e. follow the process) >> before we get into a more limited discussion of how to parse MFO. I >> don't think it's ready to parse at all yet, so I'm not sure why it's >> on -dev. > > I moved my response to -dev since that's where Tantek tried to move it > earlier, twice I believe, and I don't see any particular reason to > disagree that. It's on -dev because this is first and foremost a discussion or parsing, because we are focusing on the discussion of the problem, rather than the discussion of the solution. It's a subtle distinction but an important one, which often gets forgotten (especially with typical new proposals with microformats which seem to almost always prematurely jump to solution discussions before problems are properly documented - especially on the wiki). > MFO is only particular potential solution for a bigger problem which > you'll have to trace back through this discussion thread to read. > Briefly, there's problems reusing uF elements because they could > potentially be incorrectly associated with the wrong semantic object. Which, I would say, at this point, if you want more time/focus/energy spent solving those problem(s), start to document URLs on the wiki to real world examples that demonstrate the problem. Enough with the theory in email. Tantek From ryan at technorati.com Tue Jun 19 17:12:42 2007 From: ryan at technorati.com (Ryan King) Date: Tue Jun 19 17:12:56 2007 Subject: [uf-dev] creators Message-ID: <40C2DA5A-F798-435A-8801-779DCF4F766D@technorati.com> We have several simple tools for creating microformats at [1], [2] and [3]. Up until now, I've been maintaining them, but I've been having trouble finding the time to deal with issues discovered in them. The apps are pretty simple html forms + javascript, but appear to have some compatibility issues with a few browsers. If anyone would like to help out with testing and fixing them in various browsers (IE6, IE7 and Opera in particular) it'd be a great help to the community. The source code is available in our mercurial repository at http:// hg.microformats.org/generators thanks, ryan From davidjanes at blogmatrix.com Tue Jun 19 17:17:23 2007 From: davidjanes at blogmatrix.com (David Janes) Date: Tue Jun 19 17:17:26 2007 Subject: [uf-dev] Re: [uf-new] Microformats parsing, in general (was: hAudio final draft) In-Reply-To: References: <21e523c20706191605v7d145893r8ef6e86716cc59f5@mail.gmail.com> Message-ID: <21e523c20706191717i4b4d8179g5b9fd0b8fc0de069@mail.gmail.com> On 6/19/07, Tantek ?elik wrote: > > > MFO is only particular potential solution for a bigger problem which > > you'll have to trace back through this discussion thread to read. > > Briefly, there's problems reusing uF elements because they could > > potentially be incorrectly associated with the wrong semantic object. > > Which, I would say, at this point, if you want more time/focus/energy spent > solving those problem(s), start to document URLs on the wiki to real world > examples that demonstrate the problem. Enough with the theory in email. Since this all came out of hAudio and "audio-title" vs. "fn", I'll wait to see how that shakes out before f-cking up my hands with more RSI of wiki-edits that may be rendered pointless. -- David Janes Founder, BlogMatrix http://www.blogmatrix.com http://blogmatrix.blogmatrix.com From ryan at technorati.com Tue Jun 19 17:55:13 2007 From: ryan at technorati.com (Ryan King) Date: Tue Jun 19 17:55:30 2007 Subject: [uf-dev] creators In-Reply-To: <40C2DA5A-F798-435A-8801-779DCF4F766D@technorati.com> References: <40C2DA5A-F798-435A-8801-779DCF4F766D@technorati.com> Message-ID: <9818732F-BAF3-40E1-9DFF-9DB24007B551@technorati.com> On Jun 19, 2007, at 5:12 PM, Ryan King wrote: > We have several simple tools for creating microformats at [1], [2] > and [3]. Up until now, I've been maintaining them, but I've been > having trouble finding the time to deal with issues discovered in > them. > > The apps are pretty simple html forms + javascript, but appear to > have some compatibility issues with a few browsers. > > If anyone would like to help out with testing and fixing them in > various browsers (IE6, IE7 and Opera in particular) it'd be a great > help to the community. > > The source code is available in our mercurial repository at http:// > hg.microformats.org/generators Whoops. I forgot to add the links: 1. http://microformats.org/code/hcard/creator 2. http://microformats.org/code/hcalendar/creator 3. http://microformats.org/code/hreview/creator -ryan From robertc at gmail.com Wed Jun 20 10:00:48 2007 From: robertc at gmail.com (Rob Crowther) Date: Wed Jun 20 10:00:53 2007 Subject: [uf-dev] creators In-Reply-To: <9818732F-BAF3-40E1-9DFF-9DB24007B551@technorati.com> References: <40C2DA5A-F798-435A-8801-779DCF4F766D@technorati.com> <9818732F-BAF3-40E1-9DFF-9DB24007B551@technorati.com> Message-ID: <3ce2ebd20706201000x57fcde47r34553e1ec35184ef@mail.gmail.com> > > Up until now, I've been maintaining them, but I've been > > having trouble finding the time to deal with issues discovered in > > them. > > Is the list of issues on the feedback pages on the wiki the definitive list? I'm going to have a look, but I'm not sure how much help I could actually be. This is possibly not the main problem, but the file http://microformats.org/code/lib/string.js seems to be missing. Restoring the file on a local installation stopped the 'object required errors for me in IE, IE6 and Opera, I didn't do any deeper testing than clicking the 'Build It!' button though. Rob From ryan at technorati.com Wed Jun 20 12:10:19 2007 From: ryan at technorati.com (Ryan King) Date: Wed Jun 20 12:10:23 2007 Subject: [uf-dev] creators In-Reply-To: <3ce2ebd20706201000x57fcde47r34553e1ec35184ef@mail.gmail.com> References: <40C2DA5A-F798-435A-8801-779DCF4F766D@technorati.com> <9818732F-BAF3-40E1-9DFF-9DB24007B551@technorati.com> <3ce2ebd20706201000x57fcde47r34553e1ec35184ef@mail.gmail.com> Message-ID: <3C1F384F-7C08-48C5-B8FF-98FCD22CBDE4@technorati.com> On Jun 20, 2007, at 10:00 AM, Rob Crowther wrote: >> > Up until now, I've been maintaining them, but I've been >> > having trouble finding the time to deal with issues discovered in >> > them. >> > > Is the list of issues on the feedback pages on the wiki the definitive > list? I'm going to have a look, but I'm not sure how much help I > could actually be. It's probably not definitive. It's just everything I've seen or heard about. One thing someone could tackle is replacing MochiKit. I started using it some convient DOM and Events apis, but its proven to be a hassle when it comes to compatibility. I'd much rather use jQuery now. > This is possibly not the main problem, but the file > http://microformats.org/code/lib/string.js seems to be missing. > Restoring the file on a local installation stopped the 'object > required errors for me in IE, IE6 and Opera, I didn't do any deeper > testing than clicking the 'Build It!' button though. I've fixed that js file. It should be there now. -ryan From tantek at cs.stanford.edu Wed Jun 20 22:37:51 2007 From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik) Date: Wed Jun 20 22:37:56 2007 Subject: [uf-dev] include-pattern parsing In-Reply-To: <002501c7b3b2$b18c21d0$116bacca@COMCEN> Message-ID: redirecting parsing assertion to microformats-dev per mailing-list guidelines. On 6/20/07 8:17 PM, "Michael MD" wrote: >> >> Is the object tag to be used instead for the include pattern? >> > > given no, not given, not without a URL to documentation. > the complexity it adds to non-browser-based parsers what specific complexities have you encountered in your development of a non-browser-based parser and have you documented them on the wiki (say on the include-pattern-issues page)? Tantek From scott at randomchaos.com Thu Jun 21 06:14:26 2007 From: scott at randomchaos.com (Scott Reynen) Date: Thu Jun 21 06:14:37 2007 Subject: [uf-dev] Re: [uf-new] Microformats parsing, in general (was: hAudio final draft) In-Reply-To: References: Message-ID: <3A8EC6F7-C190-47B1-9B84-40173982D039@randomchaos.com> On Jun 19, 2007, at 5:42 PM, Tantek ?elik wrote: > It's on -dev because this is first and foremost a discussion or > parsing, I disagree. I think the problem is that the markup semantics are undefined, which is no more a parsing issue than a publishing issue. > because we are focusing on the discussion of the problem, rather > than the > discussion of the solution. I agree we should focus first on the problem, but I think the problem is that nobody knows what the markup means when we publish embedded microformats. And what it means should not be determined by how it's parsed; rather, how it's parsed should be determined by what it means. > It's a subtle distinction but an important one, > which often gets forgotten (especially with typical new proposals with > microformats which seem to almost always prematurely jump to solution > discussions before problems are properly documented - especially on > the > wiki). I agree, but the problem here is conflicting assumptions about what something that's already published actually means, so describing those assumptions (which sound a lot like proposed solutions) is part of documenting the problem. > Which, I would say, at this point, if you want more time/focus/ > energy spent > solving those problem(s), start to document URLs on the wiki to > real world > examples that demonstrate the problem. Enough with the theory in > email. Um, ok. http://microformats.org/wiki/mfo-examples#hCard_in_hCalendar But is theory in the wiki any better? I'm hesitant to rewrite that entire page, but other than the few examples I recently added, it's pretty much all theory right now. Peace, Scott From matnet84 at hotmail.com Mon Jun 25 06:54:35 2007 From: matnet84 at hotmail.com (Mattia Rigo) Date: Mon Jun 25 06:54:47 2007 Subject: [uf-dev] vCard2hCard converter tool Message-ID: Hi there! I'm an italian student of Informatic at the "Ca' Foscari" University of Venice and I developed an online vCard2hCard converter, it's only a scratch for the moment, but it seems to work! I leave my email address for more information or if you're interested for improve my application. Bye Mattia http://wwwstud.dsi.unive.it/~mrigo/vcard2hcard/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://microformats.org/discuss/mail/microformats-dev/attachments/20070625/427b7868/attachment.html From brian.suda at gmail.com Thu Jun 28 15:42:55 2007 From: brian.suda at gmail.com (Brian Suda) Date: Thu Jun 28 15:42:58 2007 Subject: [uf-dev] X2V parsing of #fragment-identifiers Message-ID: <21e770780706281542p28d6c3fct12ac1f4cd24a669b@mail.gmail.com> >From the hcard-parsing wiki page[1]: "If the URL has a fragment identifier, then the parser should parse only the node indicated by the fragment identifier and its descendants, looking for hCards, starting with the indicated node, which may itself be a single hCard." Currently X2V (as i read this spec) does not implement this correctly. I want to double check to see if i need to change my code and/or if the wiki needs a better description. As i read it, you should be able to point to an ID attribute and look for a microformat at that ID and for any microformats that are children of that ID. For instance:

Staff

  • ...
  • ...
If i submit the URL http://example.org/index.html#staff-list to X2V i SHOULD get 2 vCards as a result? At the moment X2V would fail because it is looking for:
...
Which is ALSO valid according to the wiki page and would yield 1 vCard. Currently X2V can only extract the FULL page or a SINGLE instance. As i read the parsing-rules wiki page, the current implementation is not correct. This popped-up recently for myself with GEO, i have a page of various GEO points. I wanted to generate a KML file of multiple GEO points, but only a subset of the FULL list on my page. So i am willing to update my XSLT code, but i'd like some feedback to whether my implementation is in error, or the wiki page. (i think i side with the wiki page at the moment and need to update my code) Thoughts? -brian [1] - http://microformats.org/wiki/hcard-parsing#URL_handling -- brian suda http://suda.co.uk From connolly at w3.org Thu Jun 28 15:54:52 2007 From: connolly at w3.org (Dan Connolly) Date: Thu Jun 28 15:54:59 2007 Subject: [uf-dev] X2V parsing of #fragment-identifiers In-Reply-To: <21e770780706281542p28d6c3fct12ac1f4cd24a669b@mail.gmail.com> References: <21e770780706281542p28d6c3fct12ac1f4cd24a669b@mail.gmail.com> Message-ID: <1183071292.7058.130.camel@pav> On Thu, 2007-06-28 at 22:42 +0000, Brian Suda wrote: [...] > For instance: >

Staff

>
    >
  • ...
    • >
  • ...
    • >
> > If i submit the URL http://example.org/index.html#staff-list to X2V i > SHOULD get 2 vCards as a result? I hadn't thought of that either. It does seem useful, at least in theory. I don't feel that strongly about it either way. Please do capture that example in a test case, regardless of which outcome is chosen. > [1] - http://microformats.org/wiki/hcard-parsing#URL_handling -- Dan Connolly, W3C http://www.w3.org/People/Connolly/ From tantek at cs.stanford.edu Thu Jun 28 17:40:48 2007 From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik) Date: Thu Jun 28 17:40:53 2007 Subject: [uf-dev] X2V parsing of #fragment-identifiers In-Reply-To: <21e770780706281542p28d6c3fct12ac1f4cd24a669b@mail.gmail.com> Message-ID: On 6/28/07 3:42 PM, "Brian Suda" wrote: >> From the hcard-parsing wiki page[1]: > > "If the URL has a fragment identifier, then the parser should parse > only the node indicated by the fragment identifier and its > descendants, looking for hCards, starting with the indicated node, > which may itself be a single hCard." > > Currently X2V (as i read this spec) does not implement this correctly. > I want to double check to see if i need to change my code and/or if > the wiki needs a better description. > > As i read it, you should be able to point to an ID attribute and look > for a microformat at that ID and for any microformats that are > children of that ID. > > For instance: >

Staff

>
    >
  • ...
    • >
  • ...
    • >
> > If i submit the URL http://example.org/index.html#staff-list to X2V i > SHOULD get 2 vCards as a result? At the moment X2V would fail because > it is looking for: >
...
> Which is ALSO valid according to the wiki page and would yield 1 vCard. Yes, I wrote that very deliberately in hcard-parsing, for the reason you outlined, to be able to group hCards on a page, and extract them in groups as well as individually and in entirety. > Currently X2V can only extract the FULL page or a SINGLE instance. As > i read the parsing-rules wiki page, the current implementation is not > correct. > > This popped-up recently for myself with GEO, i have a page of various > GEO points. I wanted to generate a KML file of multiple GEO points, > but only a subset of the FULL list on my page. > > So i am willing to update my XSLT code, but i'd like some feedback to > whether my implementation is in error, or the wiki page. (i think i > side with the wiki page at the moment and need to update my code) The quote from the wiki page is correct. > [1] - http://microformats.org/wiki/hcard-parsing#URL_handling Thanks, Tantek