Re: [uf-discuss] rel-tag: Sorry, I'm confused as to what it means
On 7/11/06, Lee Amosslee [EMAIL PROTECTED] wrote: So, if I apply rel-tag, am I saying that this is an important link? Am I missing something? A little, I saw a couple of earlier replies but thought there were some bits I could clarify. With markup like: pTags: a rel=tag href=http://technorati.com/tag/foo;bar/a/p You are not, as I think you've assumed, tagging the linked URL with the tag 'bar'. What you're actually doing is tagging the current page with the tag 'foo'. I don't believe the content of the A is actually relevant to the tagging semantics, although having it match the tag is a good idea. This presumably frees you up to use different capitalisation or even language. From http://microformats.org/wiki/rel-tag: By adding rel=tag to a hyperlink, a page indicates that the destination of that hyperlink is an author-designated tag (or keyword/subject) of the current page ... i.e. the semantics say something about the current page, not the URL being pointed at Tags are embedded in HTTP URIs in a well-defined manner so that the tag embedded in an HTTP URI can be mechanically extracted from that URI. Specifically, the last segment of the path portion of the URI (after the final / character) contains the tag value ... implying the tag in the example would be tagged with 'foo' rather than 'bar' The linked page SHOULD exist ... note that the linked page doesn't even have to be a real one, it's just a very good idea to link it to a page that is the index for all similarly tagged pages, to avoid presenting broken links. Hope this clarifies a few points? -Ciaran ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] More responses to slashdot comments
On 7/13/06, Sho Kuwamoto [EMAIL PROTECTED] wrote: Exactly my point. There are two competing schema living in the same document: the world of HTML (semantically poor and unextensible), and the world of microformats. While this works out OK usually, I believe there are cases where the two worlds combine in uncomfortable ways. There have to be two types of schema because there are, as you rightly said, two orthogonal sets of semantics in HTML. The first is the tag/attribute based semantics, which are very strictly defined by the W3C spec. These are mainly to do with document structure and so on, and everyone understands what they mean. The second set of semantics are class/id based, and are completely 'unregulated', that is to say the specific meanings aren't specified by the HTML spec. If I want @id=shopping-list then there's no reason I shouldn't mark my pages up that way, and there's some semantic value in doing so over something like @id=centre-column. Microformats form conventions for how the *both* sets of semantics should be used. Microformats will, by preference, use the first set as far as possible (i.e. using ADDR in hCard) and then define sensible semantic ids/classes for stuff that isn't covered. Microformats differ from schemas like the W3C's HTML spec, because pages don't have a mechanism for declaring that they conform to a specific microformat. I don't think this is so much a weakness as a strength! Take @rel=tag for instance. The microformat for this declares very specifically what semantics we can read from the relationship between the current page and the URL being linked. However, there's nothing to stop someone who's never heard of microformats deciding to use @rel=tag on one of their pages, because it seems a sensible value to use, and you can't tell my looking at a page whether the author had the microformat in mind or not. I believe that the strength of microformats is that they are always sensible markup, so it doesn't matter if someone knows about the microformat being used or not, the markup still makes sense to them - if I'm looking at a link and see @rel=tag in there then that's not cryptic - I can understand what the link is saying even if I haven't heard of the microformat. The converse of this is that if I build a parser that understands @rel=tag into my search engine, then I have a spec that tells me a sensible way to parse and understand the semantics of the link. When my search engine finds the hypothetical page above, that uses @rel=tag without knowing the microformat, then because the spec defines a sensible way of parsing it, my search engine will have a good chance of correctly understanding what the link relationship means. -Ciaran ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Currency microformat
On 7/18/06, Charles Iliya Krempeaux [EMAIL PROTECTED] wrote: Maybe something like... Pay me abbr class=currency title=CAD$/abbr5.00 now! Something along these lines would be pretty sensible IMO Some other things to consider... there might be an implicit currency that comes with what's defined in the HTML lang attribute. Like if you have lang=fr-CA than you could assume the currency is CAD. (But that takes some intelligence to do that kind of mapping.) I'm very wary of this - a website in France might want to provide an English translation for international customers, but shouldn't have to then convert all the costs into GBP, for instance. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Currency microformat
On 7/18/06, Mike Stickel [EMAIL PROTECTED] wrote: Since there can be a difference between different languages within countries I thought it might be a good idea to include that in the currency definition of the formating, eg., CAD eng or CAD fr. If you need to specify the language, for instance to indicate how to interpret the chars/spacing in the number formatting, HTML has the @lang attribute which covers this (@lang=fr_CA and @lang=en_CA in this case). However, there's been a lot of close coupling of the concepts of 'language' and 'currency' in this discussion so far and I don't think that's at all necessary - I should be able to go to a foreign website that provides an English translation without my user-agent assuming the prices are in US Dollars, for example. So far on the examples sent to the list there has been no definition around the actual dollar amount which confused me a bit. I'm curious, is there a reason for that? The only microformat that I've noticed currency units in is hListing, and that deliberately shies away from parsing the actual values because it's too free-form in most existing Listing formats. My own preference would be for something like: p class=moneyThis item costs span class=currencyGBP/span span class=amount10.00/span /p Which with similar parsing rules to existing formats would also allow things like: p class=money It'll cost you abbr class=currency title=50.00fifty/abbr abbr class=amount title=GBPquid/abbr , mate! /p Or, a more complex example with multiple languages: p lang=en span class=money span class=amount50/span abbr class=currency title=GBPpound;/abbr /span span lang=fr class=money (c'est span class=amount75/span abbr class=currency title=EUReuro;/abbr pour ca) /span /p (sorry about the bad french) It'd be pretty neat to have a browser widget that converted all the USD prices on an American site into their equivalent GBP on mouseover, or something along those lines. -C ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Currency microformat
On 7/18/06, Ciaran McNulty [EMAIL PROTECTED] wrote: Or, a more complex example with multiple languages: [...] Sorry, screwed this up a bit. I meant to demonstrate different number formatting. p lang=en Price: span class=money abbr class=currency title=GBPpound;/abbr span class=amount1,250.00/span /span span lang=fr class=money (Prix: span class=amount1600,00/span abbr class=currency title=EUReuro;/abbr ) /span /p ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Currency microformat
On 7/18/06, Scott Reynen [EMAIL PROTECTED] wrote: It already is pretty neat: http://viewmycurrency.wordpress.com/about/ http://nybblelabs.org.uk/projects/exchequer http://6v8.gamboni.org/Greasemonkey-Yahoo-Finance.html Which prompts the question: what exactly is the problem we're trying to solve here? Huh, good point. Wonder how it works? -Ciaran ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] The scope of rel-tag
The spec for rel-tag states that the tag applies to the page, or specifically to the main content of the page. Rel-Tag is one of several MicroFormats. By adding rel=tag to a hyperlink, a page indicates that the destination of that hyperlink is an author-designated tag (or keyword/subject) of the current page. Note that a tag may just refer to a major portion of the current page (i.e. a blog post). [http://microformats.org/wiki/rel-tag#Abstract] In some other microformats, the rel-tag is scoped more specifically to a section of the page. For instance, in xFolk the rel-tag is specifically scoped to the container of class xfolkentry. [http://microformats.org/wiki/xfolk#Format] I asked about this on IRC and Tantek clarified that a parser should, if it doesn't understand the microformat that specifies a scope for rel-tag, it should default to the tag applying to the page, which seems very pragmatic. [http://rbach.priv.at/Microformats-IRC/2006-07-28#T101855] My question is should the spec be updated to mention that the scope can change in other microformats? Something like: Note that a tag may just refer to a major portion of the current page (i.e. a blog post). In some microformats the tag may refer to a smaller portion on the page but the prescence of this smaller portion but by implcation can also apply to the page as a whole. -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Easy book citations
Someone said that the citation uformat should use hcards for authors; this is probably an ideal situation, but not necessarily practical in all cases - for instance, I'm slurping author data from Amazon and don't have control of how it segments into first, middle, last names, etc. You don't need to partition names, I believe the minimal hCard is something like: div class=vcarddiv class=fnCiaran McNulty/div/div (It may be possible to do without the inner DIV and apply the fn to the outer one, I'm not 100% clear on whether the fn has to be on a child element of the vcard). -Ciaran ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCard and vCard
On 8/3/06, Andrew Sidwell [EMAIL PROTECTED] wrote: Could one use cite class=vcard fnBen Barren/cite instead? That would fit HTML semantics more closely. The fn has to be inside the vcard, but cite class=vcardspan class=fnBen Barren/span/cite would be ok. -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Getting started with microformats
I did think about using the agent field --- unfortunately, in this instance John Smith is (in real life) an agent and John Doe is the agent's assistant. I have a feeling that using the agent's agent field for the agent's assistant's hcard or the associate agent's hcard is just going to cause confusion all round. The vCard 'agent' field strongly means that the enclosed vCard is an assistant or proxy of the main vCard, it doesn't mean 'agent' in any of the other senses of the name. This type typically is used to specify an area administrator, assistant, or secretary for the individual associated with the vCard. A key characteristic of the Agent type is that it represents somebody or something that is separately addressable. Looks like it's an unfortunate semantic conflation which is restricted to this particular domain of discourse. I suppose if you're using 'agent' to mean something else then yeah, but that's a risk that all the microformat class names run. -Ciaran ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] vcard fn for name in A. B. Smith format
On 8/29/06, Bruce D'Arcus [EMAIL PROTECTED] wrote: I am assuming 'A' is an abberiviation for a first name? 'B' is a middle name, and 'Smith' is the last name you can do the following: On 8/28/06, Brian Suda [EMAIL PROTECTED] wrote: Yeah, but I don't think you can asssume that. Better to just treat A. B. as the given-name string. That's a good point, there are quite a few people whose given name is their 'middle' name, it could be A. Brian Smith or Anthony B. Smith, you can't necessarily assume. -Ciaran ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] vcard fn for name in A. B. Smith format
On 8/31/06, Jeremy Keith [EMAIL PROTECTED] wrote: I was working an intranet site for a posh estate agent recently, and they had all sorts of ludicrous edge cases in their database of upper- class landed gentry. I work for a site that deals in the Construction industry, and for whatever reason, surveyors seem to get really upset if they can't have a string of qualifications after their name, so insist on trying to cram them into the 'last-name'* field. -Ciaran * I know, very western-biased ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Tentative proposal for What's New listings
On 9/26/06, Stephen Paul Weber [EMAIL PROTECTED] wrote: pubDateTue, 26 Sep 2006 20:00:00 +/pubDate As I said, the title=blah on the abbr is assumed to go with the date, not the title. Am I right in thinking that while other microformats specify that ABBR titles should replace the literal content for parsing, hAtom only specifies this for dates? What is the reasoning behind this? -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats in Form Fields
Lets say you have a personal registration form in your web app, for entering contact data which will later be output as an hCard in various places. What if I was to mark up the form (and fields) with hCard classes? I've long thought that a form should be marked up as if the data was non-editable. This is especially relevant when presenting an object for editing, because the data is all there in the form. The problem is that under most uF parsing rules, input elements' @value will not be used to determine their content. However, a textarea would be parsable as you'd expect. I haven't read any previous discussion on this topic though so I don't know what the group consensus is... -Ciaran ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: Currency + Unit of measurement (Was: Currency+Product)
On 10/1/06, Scott Reynen [EMAIL PROTECTED] wrote: I think $ is a unit of measuring currency, and barrel is a unit of measuring oil, which in this case is the product the currency references. I disagree. There are plenty of other things that can be sold by the barrel, and I doubt there are many instances of $/barrel being used without oil being specifically referenced. I think it's fairly clear that $ is a unit of currency, 'barrel' is a measure of volume, and $/barrel is a measure of currency/volume in its own right, similar to other composite measures like m.p.h. -Ciaran ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hPlaylist Status?
On 10/5/06, Lucas Gonze [EMAIL PROTECTED] wrote: I'd be happy to have your input or help you tackle related problems. Let's talk offlist. Lucas, This is certainly something I'd be interested it hearing more about, so I'd encourage you to continue progress on this in public! Do you have some pointers to the existing research? Thanks -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats in Form Fields
On 10/5/06, Ben Ward [EMAIL PROTECTED] wrote: The first that comes to mind: If the form is pre-filled then you have a valid vcard that could be parsed (with the addition of some form parsing rules). Take for example an 'Edit Profile' page that contains existing values. That's a very good point, but it would depend on some changes to the uF parsing rules. Elements like textarea/ that just wrap values could be parsed normally but others like input type=text/ would need to be parsed using the @value, and I'm not sure what we'd have to do to be able to parse, for instance, radio buttons. -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats in Form Fields
On 10/5/06, Tom Armitage [EMAIL PROTECTED] wrote: Quick question (and this isn't mean as a troll or a leading one, it's just because right now I can't think of any): what uF could be valuably applied to a radio button? I guessed you might have two radio buttons saying home address and work address... but I can't see _many_ instances where radios or checkboxes would be vastly useful _for the uFs which exist right now_. Your example of home address/work address is a very good one! Another might be an hCalendar event's free/busy time status. Maybe [EMAIL PROTECTED]radio buttons weren't the best example, but I was trying to point out that form elements' values often lie in odd places that aren't covered by the parsing rules. That said, I'd expect that a few additions to the uF parsing rules, similar to those for IMG @alt and ABBR @title would cover more than 80% of the form use cases. A similar element that wouldn't automatically parse well is SELECT. It's fairly easy to come up with some use cases for this in forms - date selection is the first that springs to mind. It's also certainly possible that, for instance, my Person editing form could constrain me to choosing their ORG from a SELECT that's populated with organisations that are defined elsewhere. as for class=vcard-input? not sure. I think class=vcard input - adding *two* things to the form - is a better compromise, but I don't think that's very microformatic. It's a bit like http verbs, I guess, the difference between POST and GET at a url, except in this case we have a vcard on inputs, and a vcard on display elements. One demands input in a format, the other displays data with extra semantics. I agree with this. I think indicating that a form contains an hCard is semantically valid in and of itself, especially in the case of presenting an hCard in a form for editing. There's also nothing immediately wrong with saying that an empty form is an empty hCard, IMO. Decoupling the semantics that say 'this accepts input' is a very good idea. I'm not actually sure if any new class needs to defined to say that though - surely the semantics of FORM/INPUT elements say all of that anyhow? As you can probably gather from the above, my personal instinct would be to expand uFs' parsing rules to explain how to deal with forms. The fact the uF consists of form elements is surely enough to allow a 'smart pasting' implementation to figure out where to place data (although some guidance e.g. recommending that the field-identifying classes are applied directly to the INPUT might turn out to be necessary). Regards, -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats in Form Fields
of the thread so far is moot ;-) The options discussed in a hypothetical hCard input system so far appear to be: 1) create a new root class other than vcard to indicate a form that's fillable with hCard data. Benefits: Doesn't overcomplicate hCard with new parsing rules, doesn't require rewrite of existing parsers to ignore 'unparsable' data. Drawbacks: Requires completely new parsers to be written. Existing parsers would ignore data even if a valid hCard could be extracted. 2) extend hCard's parsing rules to cover form elements and relying on the FORM/INPUT semantics to indicate that stuff is inputtable. Benefits: Small addition to existing format rather than new one. Semantics of an input form and the eventual display format are the same. Drawbacks: Existing parsers would/could parse forms as invalid hCards, would need re-writing. Regards, Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCard-o-matic toplevel div not address?
On 10/16/06, Jan Ptacek [EMAIL PROTECTED] wrote: Hi, as usually, w3c is giving as a really wonderfull spec: qThe ADDRESS element MAY be used by authors to supply contact information for a document or a major part of a document such as a form. This element often appears at the beginning or end of a document./q http://www.w3.org/TR/html401/struct/global.html#h-7.5.6 or did I read a wrong w3c spec? is it defined somewhere more precisely? jan ptacek I can't see anything imprecise about this. If it's the MAY you're worried about, that's indicating that the ADDRESS element isn't mandatory, surely. -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] include-pattern semantics
When the include-pattern[1] is used, the spec says that 'include' on the object element to indicate that that object refers to a subtree which should be included in its place' [2]. What I'm interested in is what happens to any additional classes that are applied to the inclusion element (i.e. the A or OBJECT). My instinct when marking up an entry in hAtom, for example, would be to use something like the following: a class=include author href=#vcard-elsewhere / The spec and examples don't make it clear whether the included element will 'inherit' the @class=author from the A, or whether it would be ignored. Does anyone with an existing implementation or parser have an opinion about whether this sort of markup is correct? If not, what would be the correct markup, or what would be the behaviour of existing parsers when presented with something like the above? Whatever the answer, I think it'd be a good idea to update / add to the examples to cover this case - I'd be happy to do so myself once I know what the correct answer is. Cheers, -Ciaran McNulty [1] http://microformats.org/wiki/include-pattern [2] http://microformats.org/wiki/include-pattern#class_name_.22include.22 ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hResume - Marking up experience and present date
Is this a correct way of marking this up? Are there better options? I want to make sure I have the uses of hCard and hCalendar correct, with regards to hResume. In iCal (and therefore presumably hCal), the following rule applies for events that lack a DTEND or DURATION: For cases where a VEVENT calendar component specifies a DTSTART property with a DATE data type but no DTEND property, the events non-inclusive end is the end of the calendar date specified by the DTSTART property. For cases where a VEVENT calendar component specifies a DTSTART property with a DATE-TIME data type but no DTEND property, the event ends on the same calendar date and time of day specified by the DTSTART property. http://www.ietf.org/rfc/rfc2445.txt Therefore your markup would therefore have an implicit DTEND at the end of 15th Dec 2005, by my reading of the spec. Unfortunately I don't think ISO8061 has a way of representing 'now' - the only thing I could suggest would be that you set it equal to the document's publication date, maybe using PHP as you suggest. -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Design-patterns: mystery meat?
On 10/19/06, Andy Mabbett [EMAIL PROTECTED] wrote: It appears that, nowhere on the Wiki, is the concept of a design-pattern defined or explained. Design Patterns aren't a uF-specific concept. Maybe rather than trying to write a definition, a link out to Wikipedia or somewhere similar would be appropriate, http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: RE: title attribute and abbreviated classnames(Was:[uf-discuss]Currency Quickpoll: Preliminary results)
On 10/19/06, Brian Suda [EMAIL PROTECTED] wrote: I personally like this idea: span class=moneyabbr class=currency title=USD$/abbrspan class=amount5.99/span/span It has worked well for ADR, TEL, EMAIL in hCard and is also being explored for UIDs. I like that idea too, there've been a few similar variations suggested and they seem the right general approach. I think it would also make sense to add some rules that could compact the markup in common cases. For instance, we could introduce the implied optimisation that if there is no explicit 'amount' then the amount could be taken to be everything inside the 'money' that isn't the 'currency'. i.e. span class=moneyabbr class=currency title=USD$/abbr5.99/span would be equivalent to your example above. That would simplify the markup in a large number of the cases, and I don't think would complicate the parsing *too* much. -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] First version of Currency proposal
On 10/20/06, Emiliano Martinez Luque [EMAIL PROTECTED] wrote: That example in particular might not be a problem but consider the following: span class=currency title=USD$1,000/span In the US that will mean one dollar, in Argentina (where I'm from) it will mean a thousand dollars. And tying this to the currency identification (even though the first 2 letters represent a country) will not solve the issue, since I should be able to markup values in different currencies within a single web page. I do agree though that there should be some sort of optimization. Actually it's 1000 in America too ;-) There are plenty of other countries where your assertion is true, though. However I'm not convinced that the problem of number-parsing needs to be solved in a microformat. The @lang attribute already exists in HTML and should indicate which locale numeric values are being written in. This would then hopefully also cover more complex cases like figures written in Japanese etc. -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] First version of Currency proposal
On 10/20/06, Mike Schinkel [EMAIL PROTECTED] wrote: Question: How does a human currently interpret a website that is have values such as $1,000 when it it was designed by a US company with US customers in mind? Is there something in the HTTP headers that makes this explicit that a machine could read, or does the Argentine viewing the web page just have to figure it out in context? If not, then we'd need a page-global currency seperator too... The @lang attribute specifies an ISO639[1] or ISO3166[2] country code for the element it's applied to (and any descendant elements. The W3C recommend[3] that the HTML element have this for every page. You could easily, for instance have: html lang=en-gb [...] pThis product is $1,000 (span lang=fr-pr1.500€/span)/p [...] /html And hopefully a user agent would know how to parse the numbers. @lang also has benefits for things like screen readers and so on. -Ciaran McNulty [1] http://ftp.ics.uci.edu/pub/ietf/http/related/iso639.txt [2] http://ftp.ics.uci.edu/pub/ietf/http/related/iso3166.txt [3] http://www.w3.org/International/O-HTML-tags.html ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] First version of Currency proposal
On 10/20/06, Mike Schinkel [EMAIL PROTECTED] wrote: Question: how would someone implement a wiki with different pages in different languages since they don't have access to changing the header or HTML element for each wiki page? I'm not that familiar with Wikis, they could probably implement a per-page language setting. The @lang doesn't have to be on the HTML element really. As long as it's on *an* element that contains your content, a user-agent should know what's going on. -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCard URL for page being visited
On 10/22/06, Andy Mabbett [EMAIL PROTECTED] wrote: Thank you. That's probably the best fix for the situation I describe; but it does require a change to the page, which is not supposed to be required by uFs. One of the key factors in microformats is to keep the data visible URL-of-current-page is a unique case, because the URL us already visible to the user, in the address bar (or whatever) of their browser, and known to any parsing user-agent. The problem, in my opinion, is that none of those are really part of the actual document itself. Consider a scenario where someone has saved a page locally, or is viewing it through a cache such as Google's, it'd be a mistake to infer the URL as C:\Temp\whatever, for instance. These are edge cases, but worth thinking about. -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Size considerations (or how to choose)
On 10/21/06, Charles Roper [EMAIL PROTECTED] wrote: Can anyone give any real *disadvantages* to using output compression? The choice to use compression is one of bandwidth vs. processing time. I have personally had a bad experience with a cut-rate ISP who had some sort of CPU-usage throttling that meant we had to turn off output compression on a largeish site. -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Visible Data...a Microformat requirement?
On 10/23/06, Andy Mabbett [EMAIL PROTECTED] wrote: Consider a page of events, with variable start times; and an introductory paragraph which says all events last for two hours. You're saying that the microformat should not include a dtend with the end time, for each event, because that end time is not separately and explicitly displayed to the user? In that example there isn't any invisible data, the duration is clearly present on the page. When we talk about 'hidden data' we mean things like, if the author didn't want to mention the duration anywhere on the page but still have all the events being 2 hours wrong. The general use-case of microformats is in marking up existing data in a way that makes it more semantic and therefore machine-readable. If something's considered important enough to tell a parser about, it should probably be important enough to tell a human about. For the specific example you mention, the '2 hours' declaration could probably be used as the DURATION (probably with an ABBR) and then transcluded into each VEVENT using the include-pattern. -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] species questions; process: examples questions
On 10/23/06, Andy Mabbett [EMAIL PROTECTED] wrote: What do you mean by authoring practices? ... What do you mean by the structure of the markup? ... I don't know how to be any more clear. I find it odd that you decline to answer such straightforward questions (and others in my same post, which you haven't quoted), especially when they come in response too your having written: Surely we can begin communicating better. Andy, I don't want to get in the middle of a disagreement, but I think that part of Ben's issue is that the terms you're asking about are fairly self explanatory, or at least appear to be to him. Authoring practices are the current practices and conventions used by people authoring content. The structure of the markup is the syntactic structure of pages marked up with (X)HTML. -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Visible Data...a Microformat requirement?
On 10/23/06, Michael MD [EMAIL PROTECTED] wrote: For the specific example you mention, the '2 hours' declaration could probably be used as the DURATION (probably with an ABBR) and then transcluded into each VEVENT using the include-pattern. do many parsers out there support include-pattern yet? Not many, but they probably should* ... whereas any older or very simple hCalendar parser would probably be able to see dtend! Well you can put a DTEND in and hide it with CSS if you really must. It's not best practice by any means, but if you're going to aim at existing parsers there's not really another option, sure. -Ciaran McNulty * It's very easy to volunteer other people's time like this, I appreciate ;-) ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Visible Data...a Microformat requirement?
On 10/23/06, Mike Schinkel [EMAIL PROTECTED] wrote: I'd suggest could be solved using an appropriate new [EMAIL PROTECTED], and then convicing the search engines to pay attention to it ;-) Do you mean in head? Did you see my earlier comments about wikis, CMS, and forums, where the user often may not have control of putting things in head? I did, I'm not sure what to think about it. It'd take a lot to convince me that HEAD isn't the place for meta-data, for a start ;-) The similarities between this and [EMAIL PROTECTED]alternate are particularly striking, and so that's the solution that would immediately suggest itself to me. [EMAIL PROTECTED]bookmark [1] encapsulates some of the semantics of being an 'authoritative version' of an item (for instance in hAtom[2]). You could potentially use that in your markup, but using it with an 'empty' link wouldn't be something that I'd find appealing, YMMV. I can do two things; implement it and probably get it wrong because I'd not have the benefit of feedback from the so many skilled people involved in Microformats, or include in the Microformats process and get the feedback to make it (and others) the best they can be. The microformats list and/or IRC channel are, I've found, a great place to discuss semantic XHTML in general. I'd encourage you to publish your data using whatever sensible scheme you deem appropriate, maybe after some discussion here and elsewhere. -Ciaran McNulty [1] http://microformats.org/wiki/rel-bookmark#rel.3D.22bookmark.22 [2] http://microformats.org/wiki/hatom#Entry_Permalink ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Visible Data...a Microformat requirement?
On 10/26/06, Mike Schinkel [EMAIL PROTECTED] wrote: Thanks. That maybe solves this use case. Can you do the same using link in the head in case you don't want the hyperlink visible? Or what about on a div within body? And do you know if the search engines pay any attention to this? @rel=bookmark is scoped to the current page, I think. It can be applied to an A or a LINK. -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Persons, Groups, Resources
On 10/26/06, Lorenzo De Tomasi [EMAIL PROTECTED] wrote: The code: li class=vcard personspan class=fn nTantek Çelik/span/li is compatible with the standard code: li class=vcardspan class=fn nTantek Çelik/span/li? Yes that's correct, an hCard parser will ignore any classes it's not aware of[1], so you can add any other identifiers onto it. However, hCard does already distinguish between organisations and individuals [2] (who can then be members of an organisation), so the extra markup may not be worth it. -Ciaran McNulty [1] http://microformats.org/wiki/hcard-parsing#forward_compatible_parsing [2] http://microformats.org/wiki/hcard#Organization_Contact_Info ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] rel- uFs : still draft after all this time?
On 10/31/06, Andy Mabbett [EMAIL PROTECTED] wrote: I didn't know that. How may it be disabled (I'll decide how I use my bandwidth, TYVM). There's an FAQ [1], it's worth noting that FF will wait until it's not downloading anything before it starts prefetching pages. [1] http://www.mozilla.org/projects/netlib/Link_Prefetching_FAQ.html -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Best Practice for fn and n?
On 11/6/06, Mike Schinkel [EMAIL PROTECTED] wrote: Maybe I'm missing something, but wouldn't you have to include white-space for a visible display anyway? i.e. span class=vcard span class=n fn span class=honorific-prefixMr./spannbsp; span class=given-nameJohn/spannbsp; abbr class=additional-name title=QuinlinQ./abbrnbsp; span class=family-namePublic/span,nbsp; span class=honorific-suffixM.D./span/ /span /span Not in HTML, no. The whitespace between Mr./span and span class=given-name, for instance, would be normalised to a single space when rendered. -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] vote-for
On 11/1/06, Siegfried Gipp [EMAIL PROTECTED] wrote: Well, at least i know many examples saying exactly that, but without using rel=vote-for. There are many pages out there trying to make the visitors vote for them. rev=vote-for means The current page is a vote for this URL. By definition that makes rel=vote-for mean This url is a vote for the current page. It could be used, for instance, to link to people who are adding their names to a petition? I don't think it can be taken to mean 'This is a place where you can vote for the current page', which seems to be your intent. -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCard - Telephone types (cell, office etc)
Rather than hiding data using CSS, would it be valid to do something like the following? abbr title=cell class=typeOffice/abbr I think that would parse correctly, but the usage of the ABBR is very semantically dodgy. -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCard - Telephone types (cell, office etc)
On 11/14/06, Ciaran McNulty [EMAIL PROTECTED] wrote: abbr title=cell class=typeOffice/abbr Sorry, abbr title=cell class=typeMobile/abbr makes more sense. -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] simple rss question
On 12/1/06, David Janes [EMAIL PROTECTED] wrote: a rel=alternate url type=application/rss+xml title=RSS feed of Ted Drake href=http://example.com/feed.rss; Ted Drake's feed/a @rel=alternate is not really appropriate in this instance. Semantically it says that the link is an alternate for the current page, which I doubt is correct. -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] cheat-sheets, rekeyed
On 12/5/06, Dr. Ernie Prabhakar [EMAIL PROTECTED] wrote: * What exactly does default rule mean in the hatom cheat? Yeah that's not really clear. It means that if the field isn't literally stated, it's often derivable anyhow. For instance, if there is no @class=author in an entry, then the entry author will default to the nearest in-parent [EMAIL PROTECTED]author -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: Microformats *do* seek to change behaviour (was: XFN usage stats and Re: [uf-discuss] rel=muse implies romantic relationship?)
On 12/11/06, Tim White [EMAIL PROTECTED] wrote: To address the poster's concerns, address is a block-level element, not inline, This would seem to contradict that? http://www.w3.org/TR/html4/struct/global.html#h-7.5.6 I've stayed away from using address on some of my pages precisely because of this, so I'd be delighted to find I'd read it wrong! -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: Microformats *do* seek to change behaviour (was: XFN usage stats and Re: [uf-discuss] rel=muse implies romantic relationship?)
On 12/13/06, Siegfried Gipp [EMAIL PROTECTED] wrote: address is an element designed to contain contact information. So if you want to include contact information use address. That is indepenent of using hCard or not. address is a html element, specified by the w3c, hCard is an attribute vocabulary, designed by microformats. You can pretty well use both together. In fact, microformats is designed in that way: To be used together with html. I'm referring to it's inline-ness. -Ciaran ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: Microformats *do* seek to change behaviour (was: XFN usage stats and Re: [uf-discuss] rel=muse implies romantic relationship?)
On 12/13/06, Tim White [EMAIL PROTECTED] wrote: I believe that the (%inline) refers to what address can contain -- inline elements. See same structure for headings: http://www.w3.org/TR/html4/struct/global.html#h-7.5.5 Aha, that sounds probable (apologies to Siegfried). The fact it can't contain block level elements still makes it unusable for my needs though (I can't fit my hCard into entirely inline elements, so my pages don't validate correctly if I add address). -Ciaran ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformat versioning
On 12/13/06, Steve Marshall [EMAIL PROTECTED] wrote: This, to my mind, is sub-optimal: the version of the format in use isn't something most (if any) users care about and, ideally, shouldn't be required to be part of the content. For Microformats that have an XMDP profile this is at least in part solved, a page using hCard would, for instance, have the following: html profile=http://www.w3.org/2006/03/hcard; Which clearly references a time-based version of the hCard profile. Presumably if hCard is updated, then new profile URLs will be established. However because hListing is still a draft, there isn't a profile to link to, so I don't know if there's a solution for you. The status of the draft format is so much in flux, it might not be practical to start 'version numbering' them just yet anyhow. -Ciaran ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformat versioning
On 12/13/06, Chris Messina [EMAIL PROTECTED] wrote: If it's not been done already, could this be added to the wiki under versioning practices? There's a bit about it here: http://microformats.org/wiki/profile-uris But it doesn't seem to be a resolved issue yet. -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Regarding Profile URIs and Disambiguation (wasComments from IBM/Lotus rep about Microformats)
On 12/14/06, Mike Schinkel [EMAIL PROTECTED] wrote: Just curious, what did you mean by double entendre markup? It means 'double meaning'. -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Regarding Profile URIs and Disambiguation(wasComments from IBM/Lotus rep about Microformats)
On 12/14/06, Mike Schinkel [EMAIL PROTECTED] wrote: Sigh A double entendre often refers to something with a negative meaning. I was basically asking if that's what he was implying without being defensive. Oh, right. Sorry. I didn't read any particularly negative meaning into it, I assumed Scott was just making a bit of wordplay. -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Principles of Microformats?
On 12/14/06, Siegfried Gipp [EMAIL PROTECTED] wrote: Yeah, microformats only represent visible data. Sure? Think of: link rel=tag href=http://www.microformats.org/xfolk; title=xfolk/ Actually, the rel-tag microformat explicitly excludes usage on LINK elements for precisely this reason. See: http://microformats.org/wiki/rel-tag#Tags_Are_Visible_Metadata -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Operator: Microformat detection for Firefox 2
On 12/16/06, Alex Faaborg [EMAIL PROTECTED] wrote: Today Mozilla Labs released a microformat extension for Firefox 2 named Operator. The extension was developed by Michael Kaply at IBM, and detects hCard, hCalendar, geo, hReview and rel-tag. Alex, This is absolutely excellent, congratulations to all concerned on a great product. -Ciaran ___ 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
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] 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] 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] 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, 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=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 a href=http://example.com/?tag=foo; title=fooFoo/a? 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 a href=http://en.wikipedia.org/wiki/Football_%28soccer%29;Soccer/a and the other a href=http://en.wikipedia.org/wiki/Football_%28soccer%29;Football/a, for instance. -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=13cleartext=/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 a rel=tag href=.../%E3t%E3eacute;teacute;/a 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. a href=http://example.com/tags/fish; rel=tagpoisson/a -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, 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] hCalendar include: check, please (inc. possible bug in Operator extension)
On 1/8/07, Andy Mabbett [EMAIL PROTECTED] wrote: object data=#summaryA+ with +#summaryC class=include /object 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] 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/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] 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) precode code /code/pre 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 br / to my code examples when I use them. I'm normally averse to br / 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] 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 br / 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] 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: [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/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] addresses for rural delivery
On 2/9/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: So far I have for this p class=adr span class=extended-addressBeverleigh and Grant Muir/spanbr / span class=extended-addressRD1/spanbr / span class=localityHari Hari/span span class=postal-code7953/classbr / span class=regionSouth Westland/spanbr / span class=country-nameNew Zealand/span /p 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] Geo deployed on Wikipedia.
On 4/3/07, Costello, Roger L. [EMAIL PROTECTED] wrote: Question: why are there parentheses around the lat/lon values: span class=geo style=display:none (span class=latitude54.58/span, span class=longitude5.938/span) /span 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
[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 span class=adrspan class=street-address org1 Madeup St./span/span ? 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] 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
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
span class=adr style=display:none
(span class=country-nameSingapore/span)
/span
How is this better than just:
span class=adrspan class=country-nameSingapore/span/span
?
-Ciaran McNulty
___
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] 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] 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:
TD class=n
SPAN class=honorific-prefixThe Rt Hon/SPANnbsp;
nbsp;
SPAN class=fnTony Blair/SPAN
nbsp;
SPAN class=honorific-suffixMP/SPAN
/TD
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:
span class=fn n
span class=nickname$user_entered_name/span
/span
Then whatever the user has entered as their login becomes their full
name and nickname, and the other vCard fields are effectively blank.
Actually span class=fn$foo/span 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] 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] 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] 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] 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] 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] XFN for email addresses?
On 6/13/07, Chris Messina [EMAIL PROTECTED] wrote: a href=mailto:[EMAIL PROTECTED] rel=meBuddy/a 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] 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 a href=foobar.com/foo/bar/ rev=application/pdf perhaps? HTML already has a href=foo type=application/pdf / :-) -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): p class=vcardem class=fnCiaran/p pMcNulty/em/p (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] 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, 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] 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] [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] [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] Re: Combining hCard and hCalendar
On 8/7/07, Peter Bremer [EMAIL PROTECTED] wrote: My table row template is as follows: tr class=vcard vevent td class=summaryEvent 1/td tdabbr title=20070101 class=dtstamp2007-01-01/abbr/td tda href=http://example.org/event1; class=urlsubscribe/a/td td class=fnOrganiser 1/td tda href=mailto:[EMAIL PROTECTED] class=emailcontact/a/td /tr 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: colgroup span=2/colgroup colgroup span=2 class=vcard organiser/colgroup tr class=event td class=summaryEvent 1/td tdabbr title=20070101 class=dtstamp2007-01-01/abbr/td tda href=http://example.org/event1; class=urlsubscribe/a/td td class=fnOrganiser 1/td tda href=mailto:[EMAIL PROTECTED] class=emailcontact/a/td /tr 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] 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
[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] 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
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, 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] 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] Marking up table rows
On 9/4/07, Nick Fitzsimons [EMAIL PROTECTED] wrote: trthLongitude/ththLatitude/ththHeight/ththFooo bar/ththPlace/th/tr trtd16.30/tdtd61.07/tdtd140/tdtdzzz/tdtdWi dgetsville/td/tr with both hCard and geo? Maybe I'm missing something, but what's the problem with tr class=vcard 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] 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. tr class=vcard geo 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] 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 object class=key type=whatever_PGP_keys are data=http://pgpkeys.mit.edu:11371/pks/lookup?op=vindexamp;search=0x1F140E17;1F14 0E17/object 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] 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
