Re: [uf-discuss] Best practice for the value subproperty
On 11/2/06, Costello, Roger L. [EMAIL PROTECTED] wrote: A thought occurred to me with regards to the Design #3 approach. Can I add information that didn't exist in the original HTML text? Suppose that this is the original HTML text: John will be our speaker. Mr. Public will talk about ... And here is how I mark it up (using Design #3): abbr class=fn title=Mr. John Q. Public, Esq.John/abbr will be our speaker. Mr. Public will talk about ... Notice that I added information that was not in the original HTML text, namely, his middle initial and his suffix. Unfortunately, I don't think this is valid. The real required field is n (name), but hCard uses something called implied n optimization [1] to derive n from fn (formatted name) if only fn is given. This simplifies the common case of given-name family-name. However, this only works if fn is fairly simple. If you want to include prefixes, middle initials, suffixes, etc. then you have to fully specify the n construct yourself. - David [1] http://microformats.org/wiki/hcard#Implied_.22n.22_Optimization ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] xFolk use question - Using taggedlink inside description element
On 11/1/06, Ryan King [EMAIL PROTECTED] wrote: 1. http://microformats.org/wiki/hcard-faq#nesting-properties (though that page is for hcard, it applies to everything) That sounds like something begging to me moved to a more central location. Should it be in the FAQ, or is there a more general authoring guidelines page? - David ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] vote-for
On 11/1/06, Scott Reynen [EMAIL PROTECTED] wrote: There is already an established meaning for rev=vote-for, and the reverse of that doesn't really communicate anything useful. I don't know about that; I could certainly imagine, say, a proposal asking people to vote by making blog posts and linking, and then the proposal has a list showing who voted. It shouldn't be *authoritative*, because only the person casting the vote can say for sure that they voted a certain way. What about a href=javascript:somevotingfunction() rel=vote- for.../a ? I believe that means the page containing this link is voting for a JavaScript function. Probably not what you want to communicate. Hmm, isn't that backwards? somevotingfunction() is a vote-for the current page. See the FAQ entry that you yourself linked. I very much doubt that such a link makes sense, though. - David ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats in Form Fields
Someone can mark up a form as an hCard anyway, regardless of whether it's in the spec or not. I imagine at least one person has already tried it after reading this thread, to see what it looks like. Thus, parsers could be subjected to this construct regardless of whether it's in the spec. Thus, they have to at least handle it somewhat cleanly as an invalid case, if it's decided not to make it part of the spec. I don't think handling it vs. not handling it is as big a job as some may have implied. I don't have an opinion on the handling of the root element, but I have a feeling using the accept attribute may be problematic; it sounds like it's tied to file upload input elements (input type=file) [1]. Simply putting class=vcard on the form element sounds like the purest solution to me. Remember that there may be tens of parsers, but there can be millions of documents, so it's better to optimize for the author than the software developer--and I am a software engineer, so this isn't bias against developers. - David [1] http://www.w3.org/TR/html4/interact/forms.html#h-17.3 ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] [citation]: Brian's outstanding issues 1: UID
On 9/25/06, Michael McCracken [EMAIL PROTECTED] wrote: So suppose I wanted to apply a different style to different types of vcard properties - for instance to highlight all 'home' phones. Is there a good way to do that in CSS? You can always add your own styling hooks to the page to do something like this. It breaks DRY a bit, but it's basically a tradeoff; minimize duplicated content, or minimize processing/styling complexity. - David ___ 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, Andy Mabbett [EMAIL PROTECTED] wrote: there instead of quot; would be perfectly legal and solve the problem, the escaped ampersand is my code escaping out your HTML entities, which the validator then finds bad because there should be no enitities in a title). it seems reasonable to me that, if the HTML in question contains then the corresponding title component of the feed should contain amp;. Why is that not the case? Unfortunately, escaping special characters in RSS feeds is almost entirely unspecified. They can be unescaped, single-escaped, double-escaped, even triple-escaped, and there's not always standardization on one method. This is one of the big reasons the Atom format was developed in the first place. So if the HTML *source* contains amp; (for the sake of playing nice), converting that to RSS could produce any of , amp;, or amp;amp; and each one would be considered valid by different people and software. I believe this is also why the feed validator prints a warning; it honestly doesn't know whether this will work or not. http://weblog.philringnalda.com/2005/12/18/who-knows-a-title-from-a-hole-in-the-ground illustrates some of the variety in support for handling different methods of escaping even when using a format with well-defined rules. If possible, it makes things easier to just not use any special characters in your title at all. - David ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] How's my hReview?
On 8/30/06, Andy Mabbett [EMAIL PROTECTED] wrote: finnaly, the reviewer hCard is also incorrect: p id=creditspan class=reviewer vcard fnAndy Mabbett/spanbr span class=dtreviewed title=200603March 2006/span/p you need to nest the class=fn inside the class=vcard p id=credit class=reviewer vcardspan class=fnAndy Mabbett/spanbr span class=dtreviewed title=200603March 2006/span/p Yuk. How is the latter semantically better than the former? It's just bloat. Is your name really Andy Mabbett March 2006? - David ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] citation: another example of practice in the wild
On 8/16/06, Michael McCracken [EMAIL PROTECTED] wrote: Yes, I missed that, it does. I think we'd have to use it as a child element on the link: a href=link-to-fulltext class=identifierabbr class=format title=application/pdfPDF/abbr full text link/a I think it would be better to mark that up as a href=link-to-fulltext class=identifier type=application/pdffull text link/a. No sense reinventing things that already exist in HTML. - David ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Getting started with microformats
On 8/17/06, Ciaran McNulty [EMAIL PROTECTED] wrote: I believe the markup looks something like: div class=vcard span class=fnJohn Smith/span can be reached via his secretary span class=agent vcard span class=fnJohn Doe/span on span class=tel020 /span /span /div See http://microformats.org/wiki/hcard-examples#2.4.2_VCARD A smart parser will convert that correctly and I suspect even a slightly more simplistic parser would manage to churn out two vCards with the same telephone number for both parties. Would this not be subjected to the same parsing issues as nested hCards in general (see http://microformats.org/discuss/mail/microformats-discuss/2006-August/005130.html)? I'd think a smart parser could properly deal with nested hCards, but Brian seemed pretty convinced any parser would mess things up. - David ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] relatinal modeling in microformats?
If we're looking for a use case for being able to construct a hierarchy of vevents, I could imagine it would be useful in a calendar with a fancy interface: if you're viewing a month at a time, it could collapse all the presentations down into one event labeled ABC Conference, but if you zoom in to a week or a day, it would break out into the individual presentations. It could also use shading, coloring, a container shape, or something to indicate that those presentations are linked together as part of a larger event. Granted, this sounds closer to a gimmick than a useful feature, but it would be much easier to implement if it was possible to unambiguously determine a hierarchy of events. - David ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] What to do when a microformat doesn't quite fit?
What's the best course of action in cases like these? My use-case doesn't exactly fit hAtom because it doesn't meet the mandatory 'author' and 'content' requirements. But at the same time, it looks as if hAtom fits better than anything else. I was under the impression that most of these sorts of requirements are carried over from Atom itself, not things that hAtom invented. For example, the requirements on author as specified in RFC 4287: atom:feed elements MUST contain one or more atom:author elements, unless all of the atom:feed element's child atom:entry elements contain at least one atom:author element. Thus, I suggest you use whatever solution you came up with for generating the actual Atom feeds. Your Atom feeds are valid Atom 1.0, aren't they? :-p I'm guessing the issue is less to do with hAtom and more to do with fitting your data into the Atom content model. I suppose putting yourself/the software as the feed author makes sense, as that is what created the feed. I'm less clear on the content issue. - David ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformat Question
On 3/8/06, Paul Kinlan [EMAIL PROTECTED] wrote: Hi, I am quite new to this list, so please excuse me if I am talking nonsense or if this has been discussed [I have trawled the archives, although only briefly]. Has a microformat been proposed around Questions and Answers. There has been some discussion of a FAQ microformat on IRC. I'm not sure whether we got anything on the mailing list or the wiki, however, so there may not be anything in the archives. I think it would be good to mark a question and the corresponding answer in span class=qaspan class=questionWhere does paul kinlan live?/spanspan class=answerliverpool/span/span It could help solve some semantic meaning to what part of text is a question and what is the anwser. Perhaps, but I don't think we've even gotten as far as documenting current examples. See http://www.microformats.org/wiki/process for the process of creating a microformat. I believe it's too early for strawman proposals. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: one citation microformat use case (Michael McCracken)
On 2/14/06, Michael McCracken [EMAIL PROTECTED] wrote: Speaking from my own viewpoint and that of the BibDesk users I've talked to (generally academics, not librarians - it is a bibtex editor), I think that a complete resource description framework would be welcome, but probably overkill. The pun Ryan made: http://www.w3.org/RDF/. That would be the uppercase-Semantic Web side of the fence, which microformats aren't exactly aligned with. Someone more involved with the politics can probably explain it better. The simple just-a-link references are, I would imagine, already covered by the cite tag and attributes; if we need a microformat, it would be for more complex data like a full MLA citation. It might be worthwhile to simply take the common MLA formats and translate them into microformats and see what that gets us. We may also be able to reuse terms from Dublin Core. I'm kind of fuzzy on the use cases, so if I'm off-base, let me know. I know there are also citation formats other than MLA, I'm not familiar with any of them though. - David ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: wiki-thon? Re: [uf-discuss] Microformats.org usability review
On 2/2/06, Dr. Ernie Prabhakar [EMAIL PROTECTED] wrote: Review/revise desired pathways for: New users learning about microformats Microformat lifecycle Indeed, it does seem that people new to microformats are often either entirely unaware of or somewhat confused about the process that exists to create a microformat. There have been a few instances of a proposal for a new microformat being sent to the list with, for example, no indication of current behavior or formats. This is not an accusation; I recall several people talking about how the microformats process is a different way of doing things, thus it is reasonable to expect people will be unfamiliar with it. Microformats-the-formats have gotten a lot of recognition, but microformats-the-process seems to be languishing a bit, when in fact they are significantly connected. I think we can do something about that. At the least, separate but clearly related (probably containing the word micro) names to disambiguate the two concepts could be useful. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: wiki-thon? Re: [uf-discuss] Microformats.org usability review
On 2/2/06, Tantek Çelik [EMAIL PROTECTED] wrote: I'm a little unclear what you mean by languishing. It seems that not a day goes by when we (even myself personally) must reference the process to someone either on the list or in IRC. I was hunting for the right word there anyways. Microformats seem to be/have been in the news a lot, they are topics at conventions, etc. However, it seems like the formats themselves are getting more coverage than the process used to create them, when the process is as important a development as the formats themselves; the formats grow out of the process. The fact that you have to reference the process to people, rather than them already knowing about it as a result of learning about microformats-in-general, indicates that the formats are more emphasized than the process. Think about it from the other side: has anyone ever said I heard about this great new process for developing data formats, has it been used in practice? ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hReview feedback
They should lean towards plain English, but the results just seem very dissatisfying. This is why I pointed to the date-principle where the visible text is human readable and the Title attribute contained information that was more machine readable than human. As the Title/Alt attribute is likely to almost solely be parsed by machines, it may be prudent to follow the same course of action. You're heading in a dangerous direction here. The alt attribute of an image is most definitely supposed to be data intended for humans, and in fact may change depending on what sort of image is displayed (2 out of 5 stars vs. 2 thumbs up, etc.). See http://www.w3.org/TR/REC-html40/struct/objects.html#adef-alt for more. The last example preserves the ability for users to provide their own, correct alt text for an image in whatever format they choose, while also adding a place for machine-parseable content. The choice of element and format of the content are still debatable. - David ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Ics import in Outlook
On 12/12/05, C. Hudley [EMAIL PROTECTED] wrote: On 12/9/05, David Osolkowski [EMAIL PROTECTED] wrote: The tag: URI scheme[1] provides a fairly effective way to generate unique ID's.I believe it is the recommended way to generate GUIDs for Atom[2]. Thus, it seems likely it could be re-used here. [1] http://www.taguri.org/Has the tag URI scheme been registered successfully?I don't see anupdate on its status on that page. If not, the info URI scheme (as was mentioned here recently), with thesid namespace, could be used the same way, and it has beenregistered. http://info-uri.info/registry/OAIHandler?verb=GetRecordmetadataPrefix=regidentifier=info:sid/The tag scheme is RFC 4151: http://ietf.org/rfc/rfc4151 The sid namespace appears to be for identifying collections of information (The sid namespace facilitates the identification of collections of information assets. A collection of information assets could be an organization, a website, a publisher, or a database.). The point here is to identify a specific event. The tag scheme is similarly used to identify specific entries, as opposed to collections. I suggest that tag is a better match than sid (more semantic, just to tie this back to microformats). - David Osolkowski ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Ics import in Outlook
On 12/9/05, brian suda [EMAIL PROTECTED] wrote: DTSTAMP is easy, that is just the date-time stamp when the was created.You could certainly encode that into your HTML.UID is more difficult. That is Universal ID, and within a given page youcan be use those UIDs are unique, but over the WWW there is now way to gauntee its uniqueness.The tag: URI scheme[1] provides a fairly effective way to generate unique ID's. I believe it is the recommended way to generate GUIDs for Atom[2]. Thus, it seems likely it could be re-used here. [1] http://www.taguri.org/[2] http://diveintomark.org/archives/2004/05/28/howto-atom-id- David Osolkowski ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] rel=homepage?
On 12/6/05, Andreas Haugstrup [EMAIL PROTECTED] wrote: On Tue, 06 Dec 2005 14:11:27 +0100, David Janes -- BlogMatrix[EMAIL PROTECTED] wrote: Danny Ayers wrote: On 12/6/05, Andreas Haugstrup [EMAIL PROTECTED] wrote: Sorry, that was a typo. rel=start gets shown as a home button in the browser. Thanks - got it. [[ Start Refers to the first document in a collection of documents. This link type tells search engines which document is considered by the author to be the starting point of the collection. ]]Hmm, I'm not sure, might there not be a conflict in the blog archive scenario - archived post #1 being rel=start..? Yes, exactly. After reading through the last couple of posts, I would think that rel=home has to be something different.A quick test reveals that Opera creates the home button for rel=home as well. I can't for the life of me figure out how to turn on this featurein Firefox (has it been removed?). Maybe rel=home is to be preferredbecause it doesn't interfere with rel=start and because the browser (Opera at least) actually does useful stuff with it.Mark Pilgrim suggests rel=home: http://diveintoaccessibility.org/day_9_providing_additional_navigation_aids.html The site navigation toolbar was in the full Mozilla suite. I don't think it made it into Firefox, although I wouldn't be surprised if there's an extension for it. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
