Re: [uf-discuss] re: HTML5 support
On Tue, Jul 20, 2010 at 1:07 PM, Philip Jägenstedt wrote: > Well, it's not in W3C's version of HTML5, they published it as a separate > spec (which is strange, IMO). Regardless of what spec it is in, it still > works just the same, so that's OK. Oh, really? Sorry, I'm out of date in that case. I think it's bundled together with 'HTML5' in the public consciousness anyhow. -Ciaran ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] re: HTML5 support
On Tue, Jul 20, 2010 at 5:05 AM, Angelo Gladding wrote: > Can an enlightened soul describe in which ways microdata is actually > superior to profiled poshformats? To me it's not a question of Microdata vs POSH, it's more like Microdata vs class attributes where both are methods that can be used in POSH style data embedding. The main arguments (and I present these without necessarily agreeing!) seem to be: 1. Class is ingrained as a CSS hook mechanism. Most people on this list are fine with class being used for other purposes, but despite that the argument comes up incredibly often that using class is somehow a 'hack'. Microdata overcomes that, so right or wrong, it may be worth ditching class for embedded data just to help uptake. 2. The class space is already populated with lots of ill-thought-out CSS identifiers. This means POSH formats have to attempt crude forms of namespacing (e.g. picking a uniquely-named root element) to try and not collide with existing markup. That works for @class="fn" say, but it's easy to collide with @class="email". Microdata separates out the important stuff. 3. Related to 2, microdata extraction is possible without having to be profile-aware, so for instance microdata can be converted to JSON without knowledge of the vocabulary used. 4. Microdata features some structures like @itemref that help combine disparate data across a document into one Microdata element, which in Microformats would need the slightly hacky rel-include structures that frankly I don't think anyone has been completely happy with. 5. Microdata allows locally-scoped typing using the @itemtype property and a URL, while a POSH format can only do something similar with a document-level @profile. 6. Microdata defines an API for DOM access to Microdata that allows scripts to deal with Microdata-embedded data when doing the same with Microformats involves some fairly heavy DOM parsing. The arguments against Microdata are basically that it's complex, huge, obviously isn't based on any existent markup in the wild, and really doesn't look like an obvious core element of HTML5 so it's weird that it's included in the same spec. -Ciaran ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: An Inconvenient hCard
On Wed, May 20, 2009 at 12:30 PM, Mirko Gustony wrote: > making my way through the microformats I stumbled upon the > type-internationalisation issue. Are there any news how to mark up a > type for fax in microformats without misusing abbr? There's recently been a lot of work on the value-class-pattern [1] One of the examples is given as follows: mobile +44 7773 000 000 This would seem to have obvious uses for i18n. -Ciaran McNulty [1] http://microformats.org/wiki/value-class-pattern#Parsing_value_from_a_title_attribute ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Rel-Canonical
Just catching up with this list.. It's interesting you should say that about Content-Location, I made a similar comment in a blog post [1] and there seemed to be some confusion over the exact semantics of the header. As an aside, does anyone know where google/yahoo/MSN discuss this stuff? Is it in a public setting, or is it all behind-doors talks? -Ciaran McNulty [1] http://tinyurl.com/daj7j8 On Sun, Feb 15, 2009 at 4:27 PM, Toby A Inkster wrote: > Brian Suda wrote: > >> Google has started to use rel-canonical to specific the best URL for >> page information. > > It is a shame they don't seem to have openly discussed this idea before > implementing it. If they had, people may have pointed out that it more or > less duplicates the semantics of the existing Content-Location header from > HTTP 1.1. Content-Location is already a fairly commonly used header, and > although HTTP headers can sometimes require a bit of voodoo to configure, > is available as a substitute. > > -- > Toby A Inkster > <mailto:m...@tobyinkster.co.uk> > <http://tobyinkster.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
Re: [uf-discuss] Using YQL with Microformats
George Looks good! You might want to handle URLs with the http:// omitted. -Ciaran McNulty On Mon, Feb 16, 2009 at 11:47 AM, George Ornbo wrote: > Hi all > > I'd like to share an example I knocked up showing how YQL can be used > to populate forms using just a URL. > > YQL returns JSON from Microformats and jQuery handles it to put the > correct data into the form. No database, just semantic web goodness. > > Demo here: http://tr.im/hcardme > Blog post here: http://tr.im/yqlmf > > Cheers > George > > -- > George Ornbo > > twitter: http://twitter.com/shapeshed > work: http://shapeshed.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] ISO Dates and Durations
On Tue, Sep 23, 2008 at 11:56 PM, Martin McEvoy <[EMAIL PROTECTED]> wrote: > 5.33 > > and in the head of your document you could have something like this: > > > > has any one any thoughts on this approach. I have reservations about it, to be honest. If we're going to have hidden data (and frankly from what I can tell from discussions so far about this, we're heading that way) it's better that its 'near' the visible version in the HTML rather than being hidden in the HEAD. -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCard: Quick question about nicknames
On Fri, Aug 29, 2008 at 12:17 PM, Michael Smethurst <[EMAIL PROTECTED]> wrote: > For now I'm marking them all up with class="nickname". Is this stretching > the semantics of nickname too much? > > Should I just be POSH and use class="pseudonym"? Even if you use class="pseudonym" you still need to decide whether to populate N or NICKNAME. What I mean is you either say George Eliot is given-name + family-name or a nickname, regardless of any extra POSH semantics you'd care to add. The vCard RFC seems remarkably unenlightening about the semantics of the different fields: " Type special note: The nickname is the descriptive name given instead of or in addition to the one belonging to a person, place, or thing. It can also be used to specify a familiar form of a proper name specified by the FN or N types. Type example: NICKNAME:Robbie NICKNAME:Jim,Jimmie " Based on the two examples I'd lean towards markup up pseudonyms that are structurally formatted like names as names, with everything else as nickname, i.e.: George Eliot = given-name, family-name with a pseudonym wrapper El Greco = nickname However I don't think there's any hard-and-fast rule about it. -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Employment end dates in hResume - outstanding issue
As there's been some discussion about moving drafts into specification status lately, I'd like to address one of the outstanding issues in hResume. The problem that has arisen quite a few times, is that a lot of people with a resume are currently employed and don't know what to provide as the DTEND in their markup for their current job. The problem is not as apparent with educational events, as they tend to have a defined end point even if it's in the future (PhD students may argue, mind you). The solutions in the wild tend to be either: 1. Set the DTEND to the date the resume was generated. The problem with this approach is that if I save your resume and come back and look at it in a year's time, I might think your employment period ended on that date. 2. Set the DTEND to some far-future date. This could be confusing and could be taken to indicate that your contract ends at some specified date in the future. 3. Set the DTEND to the same as DTSTART. This makes the event be either instantaneous or 1 day long in hCalendar, which could be confusing. 4. Omit the DTEND. This is actually equivalent to option 3 (see http://microformats.org/discuss/mail/microformats-discuss/2006-October/006477.html) Personally I don't think this problem is going to be solvable within hCalendar, and 'ongoing' events may be somewhat out of spec for that particular format. I would lean towards choosing one of the above approaches and defining some optional additional semantic within hResume that indicates that an experience event is 'ongoing'. My particular preference would be to recommend option 4 and add a @class="ongoing" that can be added to an event in hResume: Managing Director Example PLC 2002 to 2005 CEO Another PLC 2005 to Present When viewed by an hCalendar parser, the second event would be considered to be an all-day event occuring on 23rd Jan 2005. An hResume parser would however note the presence of @class="ongoing" within the event and be able to I'd welcome any feedback about: A. Whether this is a problem that needs solving, or if there's an obvious way of representing these events in hCalendar that we've all missed. B. Whether it needs to be solved by adding a concept of 'now' to hCalendar or whether it needs to be solved in hResume as I've suggested. C. What people think of my example markup. Thanks, -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Problems with rel-license?
On Fri, Aug 22, 2008 at 2:01 PM, Martin McEvoy <[EMAIL PROTECTED]> wrote: > http://somewhere.com/licence";>Read My Licence > > This (to me) seems semantically wrong , should I be bothered about this? I think we Brits should just accept that the uF in question is specified in en_us and not worry too much about it. The idea of internationalising uF fields is too horrific to contemplate, after all! See also text-align: center; -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hcard: additional additional names
To add to the confusion I'll throw a few more data points in. 'Mc' prefixes are historically contractions of 'Mac', and names often get the prefixes dropped. I've seen the names McNulty, Nulty and MacNulty listed in surname lists: a) Separately as you'd expect alphabetically b) All together under N c) Nulty separately with McNulty and MacNulty listed together in a separate Mc section after the M section. That said I think sorting is a bit out of scope for hCard and would consider O'-, Fitz-, Mc- and Mac- prefixes to be parts of surnames, nowadays. -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Human and machine readable data format
Another example of non-Gregorian calendaring is Saudi Arabia, where the arabic calendar is in common usage: http://www.sama.gov.sa/ (actually clicking the 'english' tab on that page shows the gregorian dates) -Ciaran McNulty On Tue, Jul 15, 2008 at 3:40 AM, Karl Dubost <[EMAIL PROTECTED]> wrote: > > Le 15 juil. 2008 à 11:16, Scott Reynen a écrit : >> >> Do you have any examples of the non-Gregorian dates being published >> online? Or any examples of applications that can take non-Gregorian dates >> as input? > > For those who need to understand. > http://en.wikipedia.org/wiki/Japanese_era_name > > The era system is very common on paper form, and on labels in supermarket at > least (for those I have noticed in my daily life in Japan). In fact it is a > mix, it is not regular. Some forms have even the possibility to deal with > the two systems. > > It is mostly used by officials organizations like governments. > > For example this article in one of the main national newspapers: Yomiuri > > 「平成20年度（第１回）超長期住宅先導的モデル事業の採択事業」 > http://home.yomiuri.co.jp/wnews/20080711hg03.htm > > 平成20年 - this is the year 20 of Heisei Era. > The sentence says the project started at this date. You will notice that the > article has also dates in gregorian calendar, so it mixes both. > > > > -- > Karl Dubost - W3C > http://www.w3.org/QA/ > Be Strict To Be Cool > > > > > > > > ___ > 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] Human and machine readable data format
On Sat, Jul 12, 2008 at 7:39 PM, Zachary Carter <[EMAIL PROTECTED]> wrote: > +1 for class="data-" > Hidden metadata isn't going away anytime soon. HTML 5 features it, > RDF/RDFa uses it, the empty abbr pattern already does it, and many > others. I think consensus seems to be that hidden data is ok for machine data, as long as it's right next to the human-readable date in the HTML (so that it's less likely to be overlooked when editing). However, -1 from me for using @class in that way - I think it breaks the semantics completely. -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] class="tag"
On Sun, Jun 29, 2008 at 3:07 PM, Duncan Cragg <[EMAIL PROTECTED]> wrote: > Those of us who favour opaque URLs (actually for practical reasons such as > clean separation of concerns, maintainability, etc.) are unhappy with being > forced into a semantic URL schema when using rel-tag. Can you go into a bit more detail, or point to a resource explaining the benefits of opaque URLs? It's something I've not come across before and I'd be intrigued to see the reasons behind it. -Ciaran ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] One more shot at accessible hCalendar
On Wed, May 21, 2008 at 8:58 AM, Zhang Zhen <[EMAIL PROTECTED]> wrote: > But someone might argue that "2008-5-21T09:22+08:00" wouldn't be a > human-readable date. As far as I know, HTML4.01 doesn't offer an > attribute for the machine-readable purpose and abbr design pattern > seems relatively the best way to do the job, but it's not perfect. As another aside, HTML5 has the proposed TIME element for exactly this. Friday 5pm -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: One more shot at accessible hCalendar
On Wed, May 14, 2008 at 2:38 PM, Toby Inkster <[EMAIL PROTECTED]> wrote: > I'm sorry, but this sounds like a really bad idea. Parsers would need to > maintain translation tables for day and month names, plus abbreviations > for them, I agree that it sounds a bit over the top for hCalendar but it's not *that* ridiculous. Most languages have a toolkit for displaying dates in different languages, how is the reverse particularly harder? > plus some sort of heuristic for figuring out the language of the > page. (In practice, many authors leave out lang/xml:lang attributes, and > Content-Language headers.) As an aside, xml:lang and lang can apply to any element and inherit downwards, so aren't particularly more difficult to add to markup than, say, a @title. is perfectly valid. > Andy Mabbett's proposed "data:" prefix already solves the abbr design > pattern accessibility issue and can be implemented in just a few lines of > code. All we need to do is build support for it into parsers. (Cognition > has supported it since alpha2.1.) If the problem is 'machine readable dates get read out sometimes' I don't see how the data: prefix solves that. I'd also like to see a bit more evidence of how common uFs are treated by screen readers - is there a wiki page somewhere? A lot of the talk about 'accessibility' that goes on on this list seems to come from non-experts making assumptions (that's not to say Charles Belov is doing this, I'm speaking generally). -Ciaran ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Parsing XFN in PHP
On Thu, Apr 10, 2008 at 1:40 PM, Mark Ng <[EMAIL PROTECTED]> wrote:
> XFN itself is fairly easy to deal with by just throwing pages through
> tidy and using DOM/SAX/xPath, surely ? I made a rudimentary parser to
> do this some time ago. The code is a little ugly to publish, but I
> don't mind sharing privately.
Here's a *very* hacky code example from when I just wanted to check my
'me' links - I include it here just to demonstrate how simple XFN can
be and hopefully it's apparent how easy it would be to work up into a
nice objecty system for spidering:
http://ciaranmcnulty.com/';
if($html = @file_get_contents($url)){
$dom = new DomDocument();
if(@$dom->loadHtml($html)){
$xpath = new DomXpath($dom);
if($nodes = $xpath->query("//a[contains(concat(' ',
normalize-space(@rel), ' '),' me ')]")){
foreach($nodes as $node){
echo $node->getAttribute('href'), PHP_EOL;
}
}
}
else{ echo 'Could not parse HTML', PHP_EOL; }
}
else{ echo 'Could not fetch file', PHP_EOL; }
?>
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Optimus 0.5.1
On Thu, Apr 10, 2008 at 10:48 AM, Ciaran McNulty <[EMAIL PROTECTED]> wrote: > The only problem I can see is that it doesn't handle invalid HTML that > well (an example would be http://ciaranmcnulty.livejournal.com/). In fact it does just look like you need to turn down error reporting to do that (or precede your loadHtml() call with an @). You do also need to check the return value of your fopen() - if I enter a URL that 404s, your code appears to keep trying to read from that resource, meaning I get returned a few hundred Mb of 'error in fread - file resource is not valid' type messages. Send me an email off-list of you want me to take a look at those bits for you. -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Optimus 0.5.1
On Thu, Apr 10, 2008 at 4:56 AM, Dmitry Baranovskiy <[EMAIL PROTECTED]> wrote: > I did some massive update to Optimus* (microformats transformer): Dmitry, all looks great! The only problem I can see is that it doesn't handle invalid HTML that well (an example would be http://ciaranmcnulty.livejournal.com/). -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Parsing XFN in PHP
On Thu, Apr 10, 2008 at 8:30 AM, Julian Bond <[EMAIL PROTECTED]> wrote: > - Modifications to reduce dependencies and just possibly work with PHP4 -1 from me, PHP5 is approaching 4 years old and PHP6 is just around the corner, and the gains from using PHP5's object syntax are almost immeasurable IMO. -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Parsing XFN in PHP
On Tue, Apr 8, 2008 at 1:10 PM, Julian Bond <[EMAIL PROTECTED]> wrote: > I need some advice about reading rel="me" tags in arbitrary web pages using > PHP. I'm intending to use this to help build a lifestream style function. > The basic intent is to cut down the amount of data entry the user has to do. > When they give me a MyBlogLog, Friendfeed, Plaxo Pulse page that has lists > of links to their profile pages I should be able to avoid having to ask them > for all of them again. So:- > > - User gives me a URL for one of their profile pages > - Use Curl to collect the source > - Parse the source looking for links with a rel="me" > - Extract an array of Link URL - Link Text > - Do something useful with the array. ( followed by Profit!) Have a look at the Google Social Graph API [1] - it doesn't query things 'live', but because it's Google they can return all the results in one response to your query, and it saves you spidering the site yourself and worrying about all the complexity that would involve. Alternatively, if you want to parse uFs in PHP, I believe hKit by Drew McLellan [2] may have some @rel=me support? -Ciaran McNulty [1] http://code.google.com/apis/socialgraph/ [2] http://code.google.com/p/hkit/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] entry-title on
On Sun, Apr 6, 2008 at 5:38 PM, Sarven Capadisli <[EMAIL PROTECTED]> wrote: > @alt is meant for "alternative text" in cases where can't be > experienced visually. It is otherwise invisible. > @title is meant to be visible alongside the . > > entry-title value should be visible. Quite, but entry-title should only be on an image when that image contains the text of the title (bad practice admittedly). So in this case the @alt should contain the text in the image. -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Standardized Representation of Microformats in PHP/other languages
On Thu, Apr 3, 2008 at 4:20 PM, Derrick Lyndon Pallas <[EMAIL PROTECTED]> wrote: > The only real way to share microformatted information is to pass it around > in an HTML container, directly or as a URL. Defining a generic conversion is > a mistake. Instead, we should focus on semantics and let applications define > their own internal representations. I think the point is, services are already providing hCard->JSON conversion and it would be nice if they were all doing it the same way. As I said at the start of this subject, the idea of talking about a representation in other languages is really a side issue (but there are already existant hCard->PHP services, for instance). Basically iff we're going to be talking about JSON representations maybe it's good if other languages can benefit from it. -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: Standardized Representation of Microformats in PHP/other languages
On Thu, Apr 3, 2008 at 11:16 AM, Toby A Inkster <[EMAIL PROTECTED]> wrote: > Agree 100%. Of course the json_decode() function was only added to PHP in > (IIRC) version 5.1, but that needn't effect code which is simply aiming at > outputting a structure that is equivalent to the output from json_decode. I hadn't realised it was so recent - according to php.net it was added in 5.2. It is in the mainstream PHP though so is probably a good one to go with - I'm a little wary of basing a specified behaviour on it though - it's not that unheard of for PHP functions to start behaving differently between point releases! There appears to be a Zend::Json package that can decode() JSON - simple testing makes it appear that it parses the JSON output of hKit identically (when told to return an object rather than an array). I've not seen any other widespread JSON parsing packages - I would have thought PEAR would have one but they don't seem to. -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Standardized Representation of Microformats in PHP/other languages
As a tangential note from the discussion about a standardised JSON format, it would be useful to be able to represent uF data as datastructures in other programming languages. hKit, I know, can return a serialised PHP object which is very useful for those of us in that world. The simplest way of 'specifying' such a structure would, IMO be to say that it should be the equivalent of the JSON uF format, as if it had been run through the json_decode() [1] function (which by default returns an object but can be made to use an associative array). Do any other of the PHP types have a strong opinion about this? I realise that at the moment it's a side issue. Is there an obvious representation in any other programming languages? -Ciaran McNulty [1] http://uk2.php.net/json ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Standardized Representation of Microformats in JSON / was: (no subject) & hCardMapper v0.96
It's important to consider who jCard is 'for'. In Microformats we put the publisher first, and shift as much complexity to the parser as we think we can get away with. For jCard, there are precious few people publishing in JSON - this format is either going to be optimised for: a) People writing hCard->jCard converters b) People who want to parse jCard (including parsing hCards via a converter). In my opinion, to promote people using uF more in their projects (I'm thinking things like hCardMapper) we should squarely aim the format at group b, and shift as much complexity as we can into the converter. What I propose is that a lot of our defaulting rules, designed to make things easier for HTML authors, should not be present in jCard. As an example, hCard has rules for parsing fn values into 'n' values - a step designed to promote uptake in HTML authors. Conversely, I would propose that 'n' values are mandatory in jCard to make things easier for parsers, and that converters be responsible for applying the defaulting rules. -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Standardized Representation of Microformats in JSON / was: (no subject) & hCardMapper v0.96
On Wed, Apr 2, 2008 at 4:03 PM, Gordon <[EMAIL PROTECTED]> wrote: > One more thing: I am unsure about the plural naming convention I suggested. > Apart from indicating if the value of a property can hold multiple values, > I don't see any added benefit right now. But I do see an unnecessary level > of complexity when it comes to parsing an hCard into a jCard. You would need > to know how to properly inflect a property, e.g. you cannot simply add an s > to "honorific-prefix". And whats the plural of adr anyway? Same for > converting plurals back into singulars. And since we want to represent an > hCard anyway, why should we deviate from the property names of an hCard, if > it's not adding any worthwhile benefit. So, back to singular? Totally agreed, the only change to the hCard field names should be from hyphen-separated to camelCase (this transform is used in stylesheet attribute names in DOM so may be formally specified somewhere if it seems non-obvious enough we need to lay it out. There's very little utility in having the field names reflect their plurality - a parser needs to know how to parse each field separately anyhow, for most real-world applications. Keeping vCard names is more useful than changing them for very little gain. -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] How to avoid building erroneous social network graphs?
On Thu, Mar 27, 2008 at 9:59 AM, Dan Brickley <[EMAIL PROTECTED]> wrote:
>
> On 27 Mar 2008, at 07:34, Ciaran McNulty wrote:
> > The simplest way to stop it is to add @rel="nofollow" to any comment
> > links - this has the effect of negating any XFN values in the links,
> > as well as preventing linkspamming and all sort of other good stuff.
>
> Where is this interaction specified? Should a compliant XFN parser not
> emit any data from elements where it finds rel=nofollow? Does that
> extend to all Microformats.org ('big M') microformats?
It's specified here:
http://microformats.org/wiki/xfn-clarifications#me_nofollow_interaction
Actually it looks like it only applies to @rel="me" from the looks of
things - I'm not aware of any other uFs that interact with nofollow.
> > As others have said, this is a publishing issue rather than a parsing
> > issue. A page that is linked to with @rel="me", and then allows
> > outbound XFN values authored by people who are not the representative,
> > is broken.
>
> Presumably they could *author* the links, but they just have to bear
> in mind that (if the claims in the page are ever to be true) those
> links describe the person who is the 'primary topic' (or 'owner') of
> the page.
Agreed - in that case it becomes an issue of trust as to who you allow
to author that sort of content.
Any commenting/posting system for 'untrusted' users should be
considering how to filter user input anyhow - if you're allowing
completely rich HTML editing for third parties you have to accept that
they'll do 'bad stuff' sometimes - posting huge images, CSS to blank
the page, embedded malicious OBJECTs and so on.
I've found the only way to guard against markup abuse that you've not
thought of is to have a whitelist-based approach to what content you
allow users to author, i.e. a set list of tags/attributes that are
acceptable. Blacklisting known abuse routes has always ended up as an
exercise in firefighting, in my experience.
-Ciaran McNulty
-Ciaran McNulty
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] How to avoid building erroneous social network graphs?
On Wed, Mar 26, 2008 at 7:32 PM, Costello, Roger L. <[EMAIL PROTECTED]> wrote: > Hi Alice. Nice page. I would like to introduce you to my friend href="Sally.html" rel="friend">Sally some time. If a page has @rel="me" links then it shouldn't really be allowing comments that can attempt to build social graphs. The simplest way to stop it is to add @rel="nofollow" to any comment links - this has the effect of negating any XFN values in the links, as well as preventing linkspamming and all sort of other good stuff. As others have said, this is a publishing issue rather than a parsing issue. A page that is linked to with @rel="me", and then allows outbound XFN values authored by people who are not the representative, is broken. -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Operator 0.9.1
On Thu, Mar 20, 2008 at 3:05 PM, Andrew Jaswa <[EMAIL PROTECTED]> wrote: > The hCard below doesn't get picked up by Operator: > > >http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Who cares? Re: Unjust banning of Andy Mabbett
On Mon, Mar 17, 2008 at 11:18 PM, Charles Iliya Krempeaux <[EMAIL PROTECTED]> wrote: > How many people do you think actually have wiki accounts? As far as I know they're free to create, aren't they? -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: rel=tag problem
On Mon, Mar 17, 2008 at 3:23 AM, David Meade <[EMAIL PROTECTED]> wrote: > But the specification clearly states that spaces should be encoded > with + or %20, and wordpress is encoding them as dashes. > http://microformats.org/wiki/rel-tag#Encoding_issues It's a SHOULD, not a MUST - + or %20 is best practice, but wordpress is free to use a different scheme if they already have a system in place that rel-tag is being bolted on to. It would be great if they could change it, but we have to be aware that the concept of tagging both predates and is more widely known than rel-tag. > > this is a non-issue because the meaning of tags is > > contextually dependent on the tag space, so there's no possibility for > > standardization around what tags mean, whether they're single- or > > multi-word. > > I'm not sure I follow what you mean here. It pretty much means aggregation is hard. Aside from issues like encoding of spaces, which we've been discussing here, there's a whole host of other issues. As an example, a wiki about metal might have 'lead' as a tag, whereas a site about dogs might have a 'lead' tag that's a synonym for 'leash'. This is the reason that URL prefixes are included in the semantics of tagging - different tagspaces will associate different meanings with different tags, compound or otherwise. Aggregation where URLs are discarded is always going to be a lossy process at best and that applies to character encoding too. -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: hAtom question
On Mon, Mar 10, 2008 at 3:26 PM, Toby A Inkster <[EMAIL PROTECTED]> wrote: > Regarding authorship, if you include: > > BBC > > Anywhere on the page (yes -- one little mention in the footer ought to be > enough), then that should do the trick. The requirement for has been under a lot of scrutiny, because of its inability to contain block elements. hReview has more lenient defaulting rules, and I think there was some mention in another thread of hAtom 0.2 fixing this. -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: hAtom question
On Mon, Mar 10, 2008 at 4:23 PM, David Janes <[EMAIL PROTECTED]> wrote: > this will all be up for grabs soon if > you have an opinion! I think the part of the hAtom spec that says: "If the Entry Author is missing * find the Nearest In Parent element(s) with class name author and that is/are a valid hCard * otherwise the entry is invalid hAtom " Should be amended to: "If the Entry Author is missing * find the Nearest In Parent element(s) with class name author and that is/are a valid hCard * if there is no suitable find the Nearest In Parent element(s) with class name author and that is/are a valid hCard * if there is/are no element(s) with class name author find the Nearest In Parent element(s) that is/are a valid hCard * otherwise the entry is invalid hAtom " In the interest of making it as easy as possible to specify an author. I think the will still need to be matched 'first' to allow for the existing published content that has managed to comply with the parsing rules as they stand. It's also worth noting that the high occurance of invalid feeds has meant that nearly all feed readers can cope with a missing AUTHOR element in an Atom feed. -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] RFC on hCardMapper script
On Wed, Feb 27, 2008 at 11:37 AM, Gordon Oheim <[EMAIL PROTECTED]> wrote: > I have assembled a small script that maps hCards onto form fields. The > reason for this was a client job, where I wanted to simplify filling out a > contact form. The script uses PrototypeJS and Scriptaculous for the dialogues > and the mofo parser on the serverside to fetch remote hCards. Very impressive, Gordon! One small comment: It doesn't appear to pick up my 'website' in the case where there are multiple URL in one hCard. I believe your best strategy would be to pick the first HTTP url. -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] uf on mobile devices
On Jan 3, 2008 12:33 PM, Andy Mabbett <[EMAIL PROTECTED]> wrote: > In message <[EMAIL PROTECTED]>, Michael MD > <[EMAIL PROTECTED]> writes > I can't even copy plain text from web pages using the native browser on > my Nokia N95; nor for that matter, with Opera Mini - though I have more > confidence in the ability being added to the latter. Lack of cut+paste is indeed an annoyance with the N95. The good news is that it can handle most vCards or iCals correctly, if delieverd over HTTP. -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: Precise Expansion Patterns (was: Re: [uf-discuss] Hcalendar in bbc.co.uk/programmes)
On Dec 15, 2007 1:40 AM, Scott Reynen <[EMAIL PROTECTED]> wrote: > It seems to me "3:23" is already > machine-readable Does 3:23 mean 3 mins 23 seconds, or 3 hours 23 mins, or 23 minutes past three o'clock? ;-) -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Hcalendar in bbc.co.uk/programmes
On Dec 14, 2007 6:45 PM, Andy Mabbett <[EMAIL PROTECTED]> wrote: > That's a reasonable argument. It's not reasonable, though, to argue > (which you're not, at least not here, but which others seem to be) that > 16:03 is an abbreviation of what a human (geeks aside) would gather from > the context as being "20070912T16:03:00+01:00" (or whatever). Well, I think a human would know from context that it was an abbreviation for 16:03 on 9th Dec 2007, and would know what time zone we were talking about, which is all the info in that ISO date. I do agree that ISO dates are often completely unreadable and we should continue to explore alternatives, I've not seen on that makes more sense than [EMAIL PROTECTED] yet as I am somewhat against the idea of hiding it in title attributes on arbitrary elements. -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] XFN syntax question
On Dec 14, 2007 10:14 AM, Thom Shannon <[EMAIL PROTECTED]> wrote: > I've just installed a new blogging platform, the blogroll supports XFN > out of the box which is nice. I just noticed in the source it's writing > it like this rel="contact;friend ;met;co-worker" > > There's no mention of using ; as a seperator in the XFN specs. I just > wanted to check I wasn't missing anything. XFN just mentions using multiple rel values for complex relationships, and rel values are space-separated so I don't think that is valid XFN. -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Hcalendar in bbc.co.uk/programmes
On Dec 13, 2007 3:19 PM, Benjamin Hawkes-Lewis <[EMAIL PROTECTED]> wrote: > Robert O'Rourke wrote: > 1. 16:03 isn't an abbreviation for 12 September 2007. That's > /additional/ information. So that should be a SPAN not an ABBR. I'd disagree with this. 16:03 in the context of your original page *will* refer to 16:03 on a specific day (I'm finding it hard to think of a non-contrived example where it wouldn't) - it's just abbreviated to 16:03. A human would gather that information from context but it's more explicit in the machine-readable version. -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] ‘XHTML’ references to ‘HTML’
On Nov 26, 2007 3:42 PM, Ben Ward <[EMAIL PROTECTED]> wrote: > This is about making clear that microformats are an HTML technology, > not an exclusively XHTML technology. 'HTML' implies compatibility > with XHTML, 'XHTML' does not imply compatibility with HTML. It sounds like a solid idea to me, but I'd really worry that it would be unclear that we mean 'HTML and XHTML'. Is (X)HTML too unwieldy to be the global replacement? -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCalendar duration problem.
On 9/25/07, Andy Mabbett <[EMAIL PROTECTED]> wrote: > > The first hCalendar on: > > <http://www.westmidlandbirdclub.com/diary/2008/03.htm> > > for "The Outdoors Show", has a duration of "P3D", which is detected by > operator, but does not appear in the exported event, in any of the > several parsers I've tried. > > Is it my mark-up at fault, or is there some other problem? Opening the Operator-exported .ICS in a text editor shows that the DURATION field is missing, which suggests it's an Operator issue. -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Optimus — microformats parser
On 9/20/07, Philip Tellis <[EMAIL PROTECTED]> wrote: > well, what you do is, you blast all possible 8 bit sequences through > usenet, and the ones that come out alive... that's your list. Is this mailing list available on Usenet? -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Optimus — microformats parser
On 9/20/07, Andy Mabbett <[EMAIL PROTECTED]> wrote: > Whatever character you have before that "f" isn't 7-bit Usenet > compliant. Is this list available on Usenet? -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Correct way to use the "key" property of hCard
On 9/18/07, Philip Tellis <[EMAIL PROTECTED]> wrote: > What do others think? Is this possibly a case where hCard needs to > deviate slightly from the vCard specification while still staying > reasonably close to the spec? Possibly some sort of usage of OBJECT would be appropriate? My public key id is http://pgpkeys.mit.edu:11371/pks/lookup?op=vindex&search=0x1F140E17";>1F14 0E17 Maybe with an appropriate @rel? -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Marking up table rows
On 9/4/07, Nick Fitzsimons <[EMAIL PROTECTED]> wrote: > > I suspect it's the fact the lon/lat need a @class="geo" wrapper. that > > would have to go on the TR meaning the vcard gets pushed up a level. > > > > or is that naughty? :-) I believe that vcard child properties have to be on child HTML nodes. -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Marking up table rows
On 9/4/07, Nick Fitzsimons <[EMAIL PROTECTED]> wrote: > > LongitudeLatitudeHeightFooo > > barPlace > > 16.3061.07140zzzWi > > dgetsville > > > > with both hCard and geo? > Maybe I'm missing something, but what's the problem with > > I suspect it's the fact the lon/lat need a @class="geo" wrapper. that would have to go on the TR meaning the vcard gets pushed up a level. The lack of anything to wrap table columns in is quite a frustration. -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hResume - notes on creation and some feedback wanted
On 8/29/07, Brian Suda <[EMAIL PROTECTED]> wrote: > > 2. Thinking of places to link to to add rel-tag links is problematic - > > at the moment I suspect people will err on the side of not using > > rel-tag > > -- this has also been noted when some resume services let you add more > free-text than simple 1-2 word terms. Can you document your > experiences here: > > http://microformats.org/wiki/hresume-issues > http://microformats.org/wiki/hresume-brainstorming I will do - in some ways it's more to do with the fact I *have* to link to an external site just to indicate what 'PHP' is, which seems like a heavy load to place on the user. > > 3. A very common element in CVs is a list of skills and years > > experience with that skill. > > --- if this is common can you please add examples to the wiki? Maybe > it was missed or omitted for some reason: I can only really put my own CV on there, my only evidence is anecdotal based on looking at a lot of (UK) developer's CVs lately. > You could experiment with tagging and adding skills to an experience > event. vevents can take "categoies" which can be rel-tags. So if i had > a skill in 2001, then you could deduce date()-2001= years with skill. That's a very good idea, thanks > > 4. I've seen this discussed before without resolution - there doesn't > > seem to be a way of marking up 'the present' as a finish date for an > > experience vevent. > > as Ted said "Just leave out the dtend and you should be all set." > > i didn´t see this on the FAQ page, so please add this with an answer. > http://microformats.org/wiki/hresume-faq I think your message has crossed with my reply to Ted - this isn't on the faq page because it's an existing issue on the hresume-issues page. I've no objection to leaving off dtend as a solution but I think it would need to be added to the hResume spec as a departure from iCal. -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: hResume - notes on creation and some feedback wanted
On 8/29/07, Ciaran McNulty <[EMAIL PROTECTED]> wrote: > Unfortunately vCard has a mechanism for generating default dtends when > they are missing [1] - this is one of the issues on the hresume-issues > page [2] that I'd really like to see resolved. Apologies: [1] http://microformats.org/discuss/mail/microformats-discuss/2006-October/006477.html [2] http://microformats.org/wiki/hresume-issues ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Need for plain-language intros for each microformat
On 8/29/07, Brian Suda <[EMAIL PROTECTED]> wrote: > --- moving the specs would break links from all over the web and in > dead tree books that say "you can view the hCard spec at ..." Cool > URIs don't change. It is probably a better idea create new pages about > each format and point people to those instead and link the specs to > them. I agree that moving the specs could be confusing, I'd propose either: a) Moving the specs to *-specification and having a big clear note at the top of the 'root' page directing trafic or, preferably b) Adding a *-intro page and a small island at the top of the existing spec pages that says 'This is a specification, for a quick introduction to * see *-intro' or something a bit more user-friendly. -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: hResume - notes on creation and some feedback wanted
On 8/29/07, Edward O'Connor <[EMAIL PROTECTED]> wrote: > > 4. I've seen this discussed before without resolution - there doesn't > > seem to be a way of marking up 'the present' as a finish date for an > > experience vevent. > > Just leave out the dtend and you should be all set. Unfortunately vCard has a mechanism for generating default dtends when they are missing [1] - this is one of the issues on the hresume-issues page [2] that I'd really like to see resolved. Possible solutions would be: 1. Stating in the hResume spec that an absent dtend in an hresume event doesn't use this mechanism 2. Having some 'special' value that can be used for 'present' Both would have negative impacts on hCal parsers that were trying to consume the page and weren't 'hResume-aware'. -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] hResume - notes on creation and some feedback wanted
Hi all, I've just published an hResume here: http://ciaranmcnulty.com/cv I'd appreciate any comments about the markup. Operator seems happy with it but I've not tried with any other consumers. Are there any active hResume aggregators I could submit it to? Some notes on my experiences of marking it up: 1. Overall, with an existing knowledge of hCard and hCalendar, marking up a CV as hResume is very straightforward. 2. Thinking of places to link to to add rel-tag links is problematic - at the moment I suspect people will err on the side of not using rel-tag 3. A very common element in CVs is a list of skills and years experience with that skill. Current skill markup is rel-tag which doesn't encapsulate this, so it may be an area to look at. 4. I've seen this discussed before without resolution - there doesn't seem to be a way of marking up 'the present' as a finish date for an experience vevent. -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Geo precision
On 8/27/07, Ben Ward <[EMAIL PROTECTED]> wrote: > Since then the only additional information I've found is that Flickr > stores accuracy (as an integer) based on the zoom level of the map > when you place a photo. In fact, if you zoom all the way out and > place a photo you'll get a notice warning you that the location is > too approximate and the photograph won't show up at higher zoom levels. I've been doing some work with Google's geocoder, encoding addresses into co-ordinates for mapping purposes. Google uses an 9-point enum that is specified as a human-understandable scale rather than specific geographical terms: 0Unknown location. 1Country level accuracy. 2Region (state, province, prefecture, etc.) level accuracy. 3Sub-region (county, municipality, etc.) level accuracy. 4Town (city, village) level accuracy. 5Post code (zip code) level accuracy. 6Street level accuracy. 7Intersection level accuracy. 8Address level accuracy. ref: http://www.google.com/apis/maps/documentation/reference.html#GGeoAddressAccuracy -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Spliting the Address of Vcard
On 8/22/07, Tom Byers <[EMAIL PROTECTED]> wrote: > More tags can be added but the problem is that the telephone number is > in the middle of address elements - this part of the mark-up cannot be > changed. I don't believe this is a problem - there shouldn't be a problem with other hCard subproperties being used inside a @class="adr". -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: Combining hCard and hCalendar
On 8/7/07, Peter Bremer <[EMAIL PROTECTED]> wrote: > My table row template is as follows: > > > Event 1 > 2007-01-01 > http://example.org/event1"; class="url">subscribe > Organiser 1 > mailto:[EMAIL PROTECTED]" class="email">contact > This is pretty tricky, as there's no valid element that can wrap around the TDs. I think something like the following may make semantic sense: Event 1 2007-01-01 http://example.org/event1"; class="url">subscribe Organiser 1 mailto:[EMAIL PROTECTED]" class="email">contact But a close reading of the HTML spec would be required, and I doubt any parsers would pick it up.. -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats in Google Maps
On 8/2/07, Andy Mabbett <[EMAIL PROTECTED]> wrote: > I addressed this in: > > <http://microformats.org/wiki/hcard-brainstorming#ADR_with_no_children> I've been trying to find an explanation of what 'extended-address' actually means, the examples in the vCard spec seem to omit it. >From its order in the sequence of the fields in ADR, however, I think it's reasonably clear that it's more specific than the street address, so would be something like 'Flat 2b'. This also seems to be the common usage in hCard. For those reasons I'm unconvinced about putting all the address data available into that one field. It might be useful if someone could experiment with conforming agents to see if they can take multi-line imput for different ADR fields? > but people (Brian Suda, chiefly) insisted that my suggestion should not > be followed, and that such addresses should instead be wrapped with > class="label" - which is supposedly for: > > "formatted text corresponding to delivery address" > > Note the use of "formatted". Can you elaborate on what the issue is there? Most text on web pages is formatted, and I think in this context it just means 'with linebreaks' which fairly simple parsing rules would solve. My main hesitation about using LABEL is that it isn't part of ADR and so isn't appropriate for the ADR-without-hCard usages. > More recently, Tantek added: > > <http://microformats.org/wiki/hcard-brainstorming#implied_adr_subproperties> > > which strikes me as unworkable, being overly complex and not suitable > for internationalisation (not just in non-English speaking countries, > but outside the USA) I agree that i18n issues make this a bit too strict (I have similar reservations about the implied-n optimisations but that's tangential). IMO it may be that the best option is to say that ADR can exist without subproperties for hCard / solo-ADR use for the purposes of semantically expressing 'hey this is an address' but then to offer no mapping to vCard unless the sub-properties are present. -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Specifying a contact person for an org in hCard
On 7/31/07, Andy Mabbett <[EMAIL PROTECTED]> wrote: > Are there any examples of publishers or parsers using "agent" in hCard? I don't think so, there was some discussion of it a while back on the mailing list but you'd have to search the archives. -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Specifying a contact person for an org in hCard
On 7/30/07, Andy Mabbett <[EMAIL PROTECTED]> wrote: > The address book on my Nokia N95 has an "assistant" field, with no > further granularity (so I could fudge an entry for "FooBar Ltd", with > "Brian Suda" as the "assistant"). The field is exported to .vcf as > "X-ASSISTANT". That's interesting, as vCard allows an AGENT field that can contain a complete other vCard. I don't know if any applications use it much. -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] [hCard] Implied type=work
On 7/18/07, Brian Suda <[EMAIL PROTECTED]> wrote: --- this is a known issue with Outlook. http://microformats.org/wiki/vcard-implementations#TEL I know, that's where I found out about it! :-) -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] [hCard] Implied type=work
On 7/12/07, Marek Pawłowski <[EMAIL PROTECTED]> wrote: I would like to ask shouldn't the type=work be implied on properties "tel", "url" and "adr" if properties "fn" and "org" are of the same value. Certainly sounds worth considering. All existing implementations I've tested converted such hCard into vCard with "phone" and "url" set as private (home). That's a vCard rule. I think technically a hCard @class="tel" without a type should be converted to something like: TEL:02076115040 and the consuming application default it to 'home', but Outlook doesn't like vCard TEL without a TYPE, so most converting apps will insert the default type explicitly. -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Date of Death in hCard
On 6/28/07, Ben Ward <[EMAIL PROTECTED]> wrote: Although this particular extension wouldn't have a major impact on that use, if we're to open the can of adding new fields, I'd like it considered that we clearly separate it, perhaps into a separate I certainly agree, I think having hCard mapping onto vCard is very useful but that there are a number of extra fields that it would be useful to have a semantic way of representing. I have an interest in genealogy so would like to see a way of getting things like place of birth, marriage dates/locations/spouses into the format too (date-of-death of course also fits into this usage). -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] "abbr" and accessibility - a work around.
On 6/27/07, Andy Mabbett <[EMAIL PROTECTED]> wrote: Nope. Pages such as: <http://flickr.com/photos/stevenhorner/612098574/> have coordinates exposed by default - look at the tags. They currently have: "250,911 results for photos matching geo:lon" Andy, I can't see this, but maybe I'm being stupid. Where on the page do you see this? I can see the geo tags, but only if I expand the 'machine tags' section, which seems like a nice comprimise for machine-targetted / human-targetted data. -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] "abbr" and accessibility - a work around.
On 6/27/07, Christian Heilmann <[EMAIL PROTECTED]> wrote: Why? Unless you are a geography geek there is not that much sense in it. Geo becomes useful by conversion to something human understandable, like a map or a named location. For print you could just override the style in the print stylesheet. Well, to use it in any application that doesn't yet consume GEO (i.e. sadly a lot of them) you'd want to be able to cut and paste it at the minimum... -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] "abbr" and accessibility - a work around.
On 6/27/07, Christian Heilmann <[EMAIL PROTECTED]> wrote: Also, speaking as a human being, what is the point of lat/lon information being displayed to me anyways? I cannot fathom where that might be from two numbers, unless you run it through a geolocator or show me a map. You may want to write it down, print it out, etc. -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] uF dumped in tag soup?
On 6/18/07, David Thompson <[EMAIL PROTECTED]> wrote: Granted, the behaviour can't be guaranteed in the case of a non-compliant document, but are Microformats actually specified as working in valid, but non-XML-compliant, HTML markup? Surely the only requirement should be that the markup can be parsed unambiguously into a DOM tree? Most proxy-type services seem to run everything through Tidy anyhow. I can't think of any uFs I'm aware of that wouldn't 'work' in HTML, although some of the nesting features wouldn't work if people did (for instance): Ciaran McNulty (which I think is valid HTML) -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: geo in Firefox 3 (as: Microformats gets strong showing in Firefox 3 UI)
On 6/15/07, Pelle W <[EMAIL PROTECTED]> wrote: Could such a microformat be designed like perhaps? HTML already has :-) -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] XFN for email addresses?
On 6/13/07, Chris Messina <[EMAIL PROTECTED]> wrote: mailto:[EMAIL PROTECTED]" rel="me">Buddy Clearly the biggest issue I see with this scheme is the inability to link out *from* the email address. However, I'm not sure that this case nullifies the utility of such links. In this case, I believe @rel="me" requires a symmetric link to be valid. -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] a question about concatenation and hAtom entry content
On 6/1/07, Brian Suda <[EMAIL PROTECTED]> wrote: --- maybe that is a good thing, if i am converting hFeed into something that is NOT html, say MySQL statements, or a simple CSV list. Should it have the HTML mark-up or should the app be allowed it to be 'down-cast' to simple ASCII? is this a spec issue? I don't think it's a spec issue at all. Nearly ALL* of the fields in hAtom are going to be (X)HTML (for instance entities will be escaped) and if the consuming application needs them in a specific text format then it's up to the application to determine how/why it should downconvert them to text. The hCard-Parsing wiki describes a recommended method[1] for converting (X)HTML to plaintext, but I'm dubious about whether it's particularly within the Microformats domain (I wouldn't argue it's not useful!). If we do want a generic recommendation for how to parse HTML into text, it's a good place to start. -Ciaran McNulty * I'm thinking the exceptions are that that dates are ISO8601 and that category names will be rel-tag and therefore RFC3986 encoded [1] http://microformats.org/wiki/hcard-parsing #Plain_Text_Formatting_of_Structural.2FSemantic_HTML ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hResume question
On 5/23/07, Andrew Jaswa <[EMAIL PROTECTED]> wrote: I've been looking at microformats for a few weeks now and I'm slightly confused with the proposed hResume format. My confusion comes from the employment history. Why would one want to put a personal hCard into an hCalendar event that essentially has old information in it? One wouldn't, as far as I can see. Certainly in my hResume, the hCards for each hEvent in the employment history is the name and url of the company involved. Regards, -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Fwd: [whatwg] Predefined classes are gone
On 5/23/07, Maciej Stachowiak <[EMAIL PROTECTED]> wrote: I find it questionable to argue that microformats.org defining semantics for particular classes is generally good, but to assume that W3C or WHATWG defining them is ill-conceived. Note that HTML has always predefined some "rel" values, and this has not stopped microformats from defining other rel values, some of which will be folded back in to the HTML spec. To me the difference is that Microformats have a system for indicating whether they are in use (although it's not used widely) in the @profile mechanism, whereas anything 'hard coded' into the HTML spec will not be optional. -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] changing abbr-design-pattern to title-design-pattern?
On 5/1/07, Andy Mabbett <[EMAIL PROTECTED]> wrote: In message <[EMAIL PROTECTED]>, Dan Champion <[EMAIL PROTECTED]> writes >If the aim is to retain the data in the body, yet render it invisible >to all users, including those of assistive technologies, what about >using a comment as the data container: I'd been thinking about that, too, but, sadly, there is no guarantee that comments will be available to a parser - some CMSs (not least Wikipedia) remove them from the output HTML; as (I've read) do some web proxies, particularly those which compress pages for use on mobile devices or slow connections. I concur, an HTML parser should be allowed to ignore comments, and many will. The similar decision to 'hide' Javascript and other scripting languages inside HTML comments has been widely criticised and is no longer considered best practice in a lot of places, for similar reasons. -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Authority (was: Text::Microformat - a uf parser for Perl)
On 4/26/07, Andy Mabbett <[EMAIL PROTECTED]> wrote: That's a point-of view, but not a definitive fact. Who says it's not a microformat? With what authority? Microformats are the things that are following the process on microformats.org. The authority presumably comes from whoever made up the term (Tantek?) -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCard names - n vs. fn
On 4/22/07, Andy Mabbett <[EMAIL PROTECTED]> wrote:
I'm not clear on the relationship between "n" and "fn " in hCard. I have
some markup:
The Rt Hon
Tony Blair
MP
Operator gives:
fn=Tony Blair
object n {
object honorific-prefix {
0=The Rt Hon
}
object honorific-suffix {
0=MP
}
Which is right, and is the mark-up valid?
Operator is correct in this instance. The markup is valid in the
sense there's nothing wrong according to the spec, but it's probably
not conveying the meaning you hope.
'fn' in your example is clearly "Tony Blair"
A parser will find the 'n' and then find its sub properties
'honorific-prefix' and 'honorific-suffix' but not find any other
sub-properties such as 'given-name' because they are not present.
What may be causing confusion on this issue are the implied-n
optimisation rules [1]. It's important to note that they only come
into effect when n is not present.
On a side-note, the issue of what to do with user-entered names where
one isn't sure of the formatting is one I've also had issues with and
could do with some attention - for now hCard is only going to be
useful in applications where the author has the users' names split
into the relevant fields and for me it's a major stumbling block.
At the moment, by omitting n, the author is making an assertion about
the formatting of the fn, i.e. the author is effectively saying 'I do
not need to specify n subproperties because fn is in one of the
standard formats'.
It's not correct behaviour to wrap arbitrary user-entered names in fn
and assume that parsers will work it all out.
One possible solution, which I've experimented with, is to use:
$user_entered_name
Then whatever the user has entered as their login becomes their full
name and nickname, and the other vCard fields are effectively blank.
Actually $foo where $foo is one word already
has this optimisation [2]
-Ciaran McNulty
[1] http://microformats.org/wiki/hcard#Implied_.22n.22_Optimization
[2] http://microformats.org/wiki/hcard#Implied_.22nickname.22_Optimization
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Datetime design pattern
On 4/16/07, Ryan King <[EMAIL PROTECTED]> wrote: That's a great suggestion. At the very least, any page could have a section at the bottom for "discussion elsewhere", for linking to resources outside the wiki that provide background information. Hm, that's probably a better idea than my one of a separate page per uF, in that there's lower overhead in adding it to the existing pages, and the fact it's visible on the page could prompt people to add links, rather than it being tucked away. -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Datetime design pattern
On 4/16/07, victor jalencas <[EMAIL PROTECTED]> wrote: Is the datetime design pattern strictly limited to the abbr element, or can it be used on other elements (like a list item for example). Yes, it's limited to ABBR [1] If so, what is the rational behind it? I'm not questioning it, just intend to fully grok it. Some of Tantek's initial thoughts on the subject that led to the agreement are on his blog [2] The basic idea behind restricting it is that the use of @title on arbitrary elements would be a form of data-hiding, which is not in the spirit of microformats, whereas using ABBR makes sense if you view things like '10am Monday" as an abbreviation for '10:00:00BST on Monday 16th April'. It would be nice, IMO, if the wiki linked to the relevant sections of the mailing list, IRC logs and influential blog posts for decisions like this. It would help to explain a lot of the thinking behind 'controversial' decisions like the datetime design pattern, rel-tags url scheme and a few other things that seem to cause puzzlement. -Ciaran McNulty [1] http://microformats.org/wiki/datetime-design-pattern#How_to_use_it [2] http://tantek.com/log/2005/01.html#d26t0100 ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Geo - why still draft
On 4/9/07, Andy Mabbett <[EMAIL PROTECTED]> wrote: Why is "geo" still a draft, when it's included in the already-published hCard spec? It's the idea of pulling the GEO out of hCard and making it usable on its own that is a draft specification, I believe. GEO and ADR as stand-alone microformats outside of hCard came later, which is why they're at a less advanced stage than hCard. -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Geo deployed on Wikipedia.
On 4/4/07, Costello, Roger L. <[EMAIL PROTECTED]> wrote:
Likewise, many wiki articles have the name of a country. The country
name could be wrapped in a template such as this:
{{country-name |Singapore}}
The HTML that is generated by the template could be:
Singapore
(Singapore
How is this better than just:
Singapore
?
-Ciaran McNulty
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Marking up properties (buildings) as hCard
On 4/3/07, Jason Garber <[EMAIL PROTECTED]> wrote: That's how I've approached it in the past if I don't have a "proper" name for the location. I'd lean toward using "fn" instead of "org", but someone with a bit more know-how might have better insight than I. I wasn't sure if I included an FN, isn't there a requirement for an N as well? -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Marking up properties (buildings) as hCard
In my day job I develop a property listings database that contains a large number of records of commercial property available to let/buy. We're undergoing a big rewrite and it's a good opportunity for me to inject some microformats into the equation. When looking at the details page for of a property, the following are present: * A description, headline, lots of info about availability, square-footage, price etc. * Contact details for the agent responsible (which can be an hCard) * The address of the property (ADR?) * (for some) The co-ordinates of the property (GEO?) The last two seem primed for grouping together into an hCard for the property itself, but I have the following issues: * Does marking up a property as an hCard make sense? * hCard requires either an FN or an ORG, from what I can tell. I'm not clear which of these is preferable for a property. Commercial properties are generally referred to by either the building name (i.e. Microformats House) or the number/street (10 Microformats St.). These are both usually also the first line of the address, do I just have 1 Madeup St. ? Any guidance would be appreciated. -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Geo deployed on Wikipedia.
On 4/3/07, Costello, Roger L. <[EMAIL PROTECTED]> wrote: Question: why are there parentheses around the lat/lon values: (54.58, 5.938) Since this information is not being displayed (style="display:none"), I don't see any value for the parentheses (or for the comma). It's somewhat dangerous to assume elements set to be display:none will never be seen... -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] addresses for rural delivery
On 2/9/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: So far I have for this Beverleigh and Grant Muir RD1 Hari Hari 7953 South Westland New Zealand I would think that the name of the recipients is the FN, not part of the address. Are Rural Delivery numbers similar enough to "post-office-box" perhaps? -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Should microformat features (like rel-tag) have explicit scope?
On 2/2/07, Derrick Lyndon Pallas <[EMAIL PROTECTED]> wrote: Except it does need it. Say you put your del.icio.us (or otherwise) feed on your page and want to include it and the associated tags as xFolk entries. How can a generic rel-tag parser know that the xFolk entires don't apply to the current page without knowing about xFolk. That's the scoping problem. The tag applying to the page just means that there's something on the page relevant to that tag. And there is - the del.icio.us feed! The problem is not that they "may be applied to the page" it's that they "are applied to the page" I meant 'may' as in 'yes, the parser can go ahead and apply them' - my ambiguity sorry. and there are reasons that is inappropriate, Can you expand on the reasons? Basically, if a page has a blog entry about Cats and an hCard in the category 'Dogs' on it, why can't that page validly be tagged with 'cats' and 'dogs'? My solution (to indicate scope with a generic rel-tag counterpart and then allow specific parsers to override the scoping rule if they understand the containing element) is both general and powerful. I haven't looked at the different scoping proposals and certainly I'm not saying yours is bad, I'm questioning the need to complicate what is after all an incredibly simple format. Take the example of a dead relative: there is no way to put a family tree with relatives you need to tag as "deceased" on your own page without a document level parser concluding that you are dead. That doesn't make any sense to me. All a rel-tag parser would take from it would be that the page had something on it about someone who's 'dead', surely. I don't know where it starts making inferences about me. -Ciaran ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Should microformat features (like rel-tag) have explicit scope?
On 2/1/07, Derrick Lyndon Pallas <[EMAIL PROTECTED]> wrote: What about an xFolk link with a tag of <http://wikipedia.org/wiki/NSFW>? Should that imply that the containing page is not safe for work? Well if an item on a page is tagged NSFW doesn't that mean the page is NSFW? I must confess I'm not 100% familiar with xFolk. rel-tag is reusable. It applies to whatever contains it. Well, except under specific circumstances which are documented in the other formats in which it has been reused, then it only applies to a sub-container, which we didn't mark in a generic way. I'm just looking for a generic scoping mark. ~D My point is that rel-tag doesn't have any scope, and I'm sort-of arguing it doesn't need it. Take the example of a page that contains: * An hAtom entry tagged with 'FOO' * An hCard with the category 'BAR' An hAtom parser will correctly note that the only rel-tag in the hAtom entry is 'FOO' and so that's the category for the entry. An hCard parser will note that the only rel-tag inside the hCard is 'BAR, and so that category applies to the card. However, a generic rel-tag parser doesn't need to know "don't look inside hAtom and hCard", as you seem to be suggesting. Any rel-tags it finds may be applied to the page itself quite fairly, and so a rel-tag parser would say 'this page contains something relevant to FOO and something relevant to BAR. Does that make sense? -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Should microformat features (like rel-tag) have explicit scope?
On 2/1/07, Derrick Lyndon Pallas <[EMAIL PROTECTED]> wrote: If I have a parser that only knows (and only cares about) the rel-tag format, it will be confused by people that use rel-tag for the category property in hCard. It seems unreasonable that every microformat should have to know about every other microformat, especially when they are nested. Can I ask what the confusion is? If I have a hcard with a rel-tag indicating 'football' in that hCard, then the naive interpretation that 'this page has something on it to do with football' that your parser will take from it is probably correct. -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: Vote on this: rel="me self" to indicate an authoritative hCard {was: Re: [uf-discuss] Authoritative hCards [was RE: Canonical hCards (was: Search on CSS element)]}
To further muddy the water, is it wise to start adding @rel="me" to indicate authoritative hCards? If I have a list of employees (please forgive any markup errors): John Doe Jane Doe Then an XFN parser will surely interpret that the 'me' on the linked pages is the same as the 'me' of the current page? -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] code microformat
On 1/30/07, anders conbere <[EMAIL PROTECTED]> wrote: I would consider the rss and atom tools be not in accordance with the (x)html specs on this one. And I believe that muddying the code with non-semantic tags makes is much more difficult to digest. I'd argue that does have semantics for a number of languages, actually! "The language tag always defines a language as spoken (or written) by human beings for communication of information to other human beings. Computer languages are explicitly excluded." Ah, well spotted. Shame! -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] code microformat
On 1/30/07, Colin Barrett <[EMAIL PROTECTED]> wrote: I have been posting some code listings on my blog recently. It would be really nice to have these sections identified (so then a source coloring tool could identify them and color them) code is the awful HTML I have been using. It would be nice to have something more semantic to put up, particularly with regards to licensing -- Some of the code snippets are public domain, some are GPL, and I don't really have any way of noting this currently. In a blog context, I've found that common RSS or Atom tools don't do well at retaining the whitespace in posts so relying on PRE isn't foolproof, even though it makes sense. I've ended up entity-encoding and adding to my code examples when I use them. I'm normally averse to but I think that code listings are one of the few areas where they make sense. This isn't particularly structured stuff, I'll try and tidy it up for the wiki, but anecdotally I'd expect the following sorts of things: * The language the code is written in. The HTML @lang attribute seems to be vaguely relevant. A look at RFC1766[1] suggests the use of x-foo values for 'unusual' languages, the example given being x-klingon. Would @lang="x-PHP" be considered abuse? * The origin of the code Most code displayed on the web (again this is anecdotal) is in the form of snippets. Some reference to the complete listing if available would seem to be in order. Is this a possible extension/application for hCite? At the very least the semantics would be similar. * Authorship (hCard), licence details (@rel="licence"? May be scope issues) -Ciaran [1] http://www.ietf.org/rfc/rfc1766.txt ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats and Wikis
On 1/16/07, Scott Reynen <[EMAIL PROTECTED]> wrote: hCard has only one required property: fn. I think that should solve your problem, unless you're collecting contact data without names. I believe n is also required, or rather if it's omitted you're having to assume that the implied-n optimisation will be appropriate for the user input. I came across this myself in an application where we had a single input for 'name'. If you just output $foo then if the user has entered something like Sir Michael the implied-n optimisation will take Sir as the given-name and Michael as the family-name. -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCalendar include: check, please (inc. possible bug in Operator extension)
On 1/9/07, Andy Mabbett <[EMAIL PROTECTED]> wrote: Thank you. Is that a requirement of HTML or the way include-pattern is parsed? It's defined in HTML, but I should have said uri rather than url,uri being a superset of url. The data attribute of object [1] should contain a uri [2], i.e. an identifier for the place the data should come from. -Ciaran McNulty [1] http://www.w3.org/TR/REC-html40/struct/objects.html#adef-data [2] http://www.w3.org/TR/REC-html40/types.html#type-uri ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Operator & AUMP bugs: .htm file name parsed as tag
On 1/9/07, Andy Mabbett <[EMAIL PROTECTED]> wrote: Based on: <http://www.westmidlandbirdclub.com/tag-test.htm> which includes rel-tag links to both: <http://www.westmidlandbirdclub.com/site/links.htm#breadcrumb> <http://www.westmidlandbirdclub.com/club/branches.htm> Operator and the AUMP are both finding the tags links.htm branches.htm This is the correct behaviour, as they are the last section of the URL's path[1]. You might want to look at changing it to /site/links/index.html and then omitting the latter in your hyperlink, if you're not able to set up rewrite rules etc. I think that, in any case, a tag cannot have a period in it - is that so? Perhaps there could be a "sanity check" for valid tags? Though I'm not sure that there is a canonical specification for what is and isn't valid... The spec explicitly mentions encoding in Unicode chars[2] so I don't think there's any inherent limitation on which characters can be in a tag. In fact, I'd say that this should be something the tagging index should be looking after (i.e. the uF is agnostic but westmidlandbirdclub.com can impose their own rules). -Ciaran McNulty [1] http://microformats.org/wiki/rel-tag#Tag_spaces [2] http://microformats.org/wiki/rel-tag#Encoding_issues ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Tagging Tag-spaces
On 12/24/06, Ben Ward <[EMAIL PROTECTED]> wrote: So my tag space is now itself tagged with the same tag name on two external resources. Does this mean anything? The URL establishes which tagging authority the tag is from. Whether a parser looks at that is left up to them - just the tag itself will be enough for many uses. One note on Wikipedia as a tagging authority, the spec says that the destination page "is required to be a tag space (a place that collates or defines tags)", which things like Wikipedia only are if you squint a bit. I think the use of this sort of site stems from rel-tag being applied to more generic 'categorisation' tasks in other uFs, where the user might not have a tagging index set up. It's worth considering whether the wording of the spec should be changed IMO. -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCalendar include: check, please (inc. possible bug in Operator extension)
On 1/8/07, Andy Mabbett <[EMAIL PROTECTED]> wrote: The @data should contain a URL, not data, the way you have here. A parser would end up looking for an element with ID 'summaryA+ with...' etc., Not sure about an elegant solution, I'm afraid, you may be better off just repeating the content. -Ciaran ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] rel="tag"
On 1/5/07, Andy Mabbett <[EMAIL PROTECTED]> wrote: So the "workaround" at: <http://microformats.org/wiki/advocacy#Google_as_rel-tag_namespace> will not work? Not in a fully conformant parser, no. -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] rel="tag"
On 1/5/07, Fil <[EMAIL PROTECTED]> wrote: I second this, though I think it's easy (but admittedly ugly) for wordpress or any other to do something like ?cat=13&cleartext=/tagName Except rel-tag explicitly uses the last part of the URL path, and should ignore query parameters and fragment identifiers[1] i.e. http://example.com/tags?tag=/fish => tags Careful with this: already having accents is not a piece of cake, but you will have to match été and other niceties (and consider the charset) You'll also have the case where the link is on an image... There are also issues with multilingual sites that might want a unified tagging scheme. e.g. http://example.com/tags/fish"; rel="tag">poisson -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] rel="tag"
On 1/3/07, Nick Peters <[EMAIL PROTECTED]> wrote: Seeing the tag implementation on Operator has made me question the existing tagging standard. With wordpress you may get something like "?cat=13" for a tag or something that may not even be the intended tag at all. Agreed, the default behaviour is very clear and easy to understand, but I'd quite like to see some sort of escaping mechanism for overriding the tag value. Maybe http://example.com/?tag=foo"; title="foo">Foo? It could bear looking at but I'd want to check through the mailing list archives to see what has previously been discussed. I still don't see why the standard extracts the tag from the last part of the URL instead of the information inside the anchor tag. When I see a tag and click on it, I expect the visible content, not what's appended to the end of a URL. Anyone care to shed some light on this for me? The main reason that I can see is to allow normalisation of tags across different pages. One might have http://en.wikipedia.org/wiki/Football_%28soccer%29";>Soccer and the other http://en.wikipedia.org/wiki/Football_%28soccer%29";>Football, for instance. -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] rel="nsfw"
On 1/1/07, Eran <[EMAIL PROTECTED]> wrote: That last sentence pretty much leaves all interpretation of scope to the application. In a blog the scope is usually a single post (even if several posts appear on the same page), in hReview it is the product (or the rating for the product) and in xFolk it's the page pointed to by the taggedentry link Is that a problem though? If a page contains an hAtom blog entry about Tom, an hReview of Dick and an hListing about Harry then it's actually a perfectly valid interpretation of the tags to say that that page is tagged with Tom, Dick, Harry even though parsing the individual uFs would yield more specific interpretations. -Ciaran ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] rel="nsfw"
On 1/1/07, Colin Barrett <[EMAIL PROTECTED]> wrote: On Jan 1, 2007, at 7:29 AM, Ciaran McNulty wrote: > Another @rel value that is more similar to the @rel="nsfw" would be > @rel="no-follow", which is trying to express an opinion about the > linked page rather than describing the link relationship. Not really -- it's saying that this link isn't a link that should be followed by an automated search engine. The relationship between document A and document B is "don't follow if you're a search engine". You can't really find an appropriate way to finish the sentence "The relationship between document A and document B is " with rel- nsfw. It's a pretty good litmus test for the correct usage of @rel. But isn't it the case that rel-nsfw is exactly the same class of relationship as rel-nofollow? If your example is OK then surely "don't follow if you're at work" is just as valid? -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] rel="nsfw"
On 1/1/07, Colin Barrett <[EMAIL PROTECTED]> wrote: On Jan 1, 2007, at 5:51 AM, Andy Mabbett wrote: > I thought tagging was for tagging the current page, not labelling a > link > to a second page. It could be expanded to include links? -- I don't know a whole lot about it, it was suggested in the discussion I had with someone where it was pointed out that this is an incorrect use of rel. I don't believe rel-tag is an incorrect use of 'rel'. @rel="tag" means that the page being linked to is a tag for the current page. The linked page should ideally contain a definition of what the tag means. Another @rel value that is more similar to the @rel="nsfw" would be @rel="no-follow", which is trying to express an opinion about the linked page rather than describing the link relationship. My own opinion is that a rating is more like an hReview, but the semantics don't correspond too well. -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] A microformat for relationship availability and preference?
On 12/20/06, Angus McIntyre <[EMAIL PROTECTED]> wrote: There are all kinds of inferences that it's dangerous to draw from an incomplete description. I concur, Microformats allow us to publish information, but the absence of them shouldn't be taken as conveying information. Which raises the whole question for me with XFN, which is a practical one, rather than a technical one: do we really want the world to know all that stuff about us? Yes, quite. Inherent in the Microformats movement is the desire to make information easier to publish and aggregate, but people need to consider carefully what parts they want to make available about themselves and their relationships to others. In my day job, I keep seeing places where an hCard would be useful where organisations are publishing contact information, but far from wanting to make it easily parsable they seem to put all their efforts into trying to obfuscate it to avoid getting more spam! -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] A microformat for relationship availability and preference?
On 12/20/06, Chris Messina <[EMAIL PROTECTED]> wrote: You could also use the absense of certain XFN values as a stopgap... At least you know that the folks without sweatheart or spouse haven't removed themselves from the pool! What if one's sweetheart doesn't have a URL (insane as that sounds in this day and age)? :-) -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] ANN: hCard Tutorial
On 12/19/06, Ciaran McNulty <[EMAIL PROTECTED]> wrote: Where you say "Why isn't it hCard? Apparently there are some historical reasons for it, but I do not know the reasons." in slide 3, the simple answer is that in vCard, the root property is VCARD, as in: I should have added 'so because hCard gets all its fieldnames from vCard, this is carried across'. -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
