From dmueller2001 at gmail.com Wed Feb 6 16:22:20 2008 From: dmueller2001 at gmail.com (Diane Mueller) Date: Wed Feb 6 16:22:23 2008 Subject: [uf-dev] Specification for Inline XBRL 0.54 Message-ID: <62325ff60802061622n75d2795dpd0930cf4569c57af@mail.gmail.com> Dear Microformats development community members, The Rendering Working Group (RWG) of XBRL International has released the first public working draft of the "Inline XBRL" specification. Inline XBRL is a standard for embedding XBRL fragments into an HTML document. The objective is to provide documents which can be viewed in a browser while making use of XBRL tags which can be processed automatically by consuming applications. This specification defines the syntax for such documents and how the syntax maps into an XBRL instance. Your feedback is eagerly sought on this specification, as we are quite interested in aligning with the microformats & RDFa work where & when possible. Please send feedback to rendering-feedback@xbrl.org or directly to myself at dmueller2001@gmail.com You will find this and other Working Drafts of other specifications at http://www.xbrl.org/SpecPWDs/ Kind Regards, Diane Mueller Chair, Rendering Working Group Vice President, New Market Development Justsystems (c) 604.765.3635 (skype) xbrlspy (work email) diane@justsystems.com (alt email) Dmueller2001@gmail.com From msporny at digitalbazaar.com Wed Feb 6 17:09:16 2008 From: msporny at digitalbazaar.com (Manu Sporny) Date: Wed Feb 6 17:09:20 2008 Subject: [uf-dev] Specification for Inline XBRL 0.54 In-Reply-To: <62325ff60802061622n75d2795dpd0930cf4569c57af@mail.gmail.com> References: <62325ff60802061622n75d2795dpd0930cf4569c57af@mail.gmail.com> Message-ID: <47AA5A3C.7090804@digitalbazaar.com> Diane Mueller wrote: > Your feedback is eagerly sought on this specification, as we are quite > interested in aligning with the microformats & RDFa work where & when > possible. Just to point out something that wasn't stated in the e-mail that Diane sent to the list. The XBRL draft is subject to XBRL International's IP Policy, which states: """ 4.1. Ownership of XBRL Recommendations. Subject to the ownership of the copyright in each Contribution by its respective Contributor in accordance with section 4.2 below, XBRL International will own the copyright in the Final Recommendation. """[1] There are a couple of other paragraphs about patents in there that raise a couple of red flags. I'm not suggesting that this is their intention, but one possibility is this: The license to edit, copy, modify, or use XBRL is not royalty-free. One of us could submit an idea to them and they could copyright the text or submit a patent covering the idea. This could come back to bite the uF community if the idea is useful because XBRL would have rights to that idea and the text surrounding the idea. I wouldn't give any feedback until Rohit can take a look at their IP Policy and get back to us on a reasonable way to move forward, if there is any. Sorry Diane, the fact that you're creating a "standard" that is not royalty-free to everybody shows that XBRL is currently not interested in the type of open standards that this community creates. You should have a chat with Rohit Khare - he handles all legal matters regarding this community. He is cc'ed on this e-mail. -- manu [1]http://www.xbrl.org/Legal2/XBRL-IP-Policy-2007-02-20.pdf -- Manu Sporny President/CEO - Digital Bazaar, Inc. blog: RDFa Basics in 8 minutes (video) http://blog.digitalbazaar.com/2008/01/07/rdfa-basics/ From dmueller2001 at gmail.com Wed Feb 6 17:50:36 2008 From: dmueller2001 at gmail.com (Diane Mueller) Date: Wed Feb 6 17:50:40 2008 Subject: [uf-dev] Specification for Inline XBRL 0.54 In-Reply-To: <47AA5A3C.7090804@digitalbazaar.com> References: <62325ff60802061622n75d2795dpd0930cf4569c57af@mail.gmail.com> <47AA5A3C.7090804@digitalbazaar.com> Message-ID: <62325ff60802061750m321da77bgc9e7ca3fdcae8b6b@mail.gmail.com> Manu and Rohit, It is my understanding that all of the XBRL specifications are available royalty-free. Although I completely understand your need to have Rohit's review of our IP policy before commenting. You can find the IP policy at http://www.xbrl.org/Legal2/XBRL-IP-Policy-2007-02-20.pdf and I have added Hugh Wallis, XBRL International's Technical Director to this thread so that he can answer any of your questions directly. Kind Regards, Diane Mueller Chair, Rendering Working Group dmueller2001@gmail.com On Feb 6, 2008 5:09 PM, Manu Sporny wrote: > Diane Mueller wrote: > > Your feedback is eagerly sought on this specification, as we are quite > > interested in aligning with the microformats & RDFa work where & when > > possible. > > Just to point out something that wasn't stated in the e-mail that Diane > sent to the list. The XBRL draft is subject to XBRL International's IP > Policy, which states: > > """ > 4.1. Ownership of XBRL Recommendations. Subject to the ownership of > the copyright in each Contribution by its respective Contributor in > accordance with section 4.2 below, XBRL International will own the > copyright in the Final Recommendation. > """[1] > > There are a couple of other paragraphs about patents in there that raise > a couple of red flags. > > I'm not suggesting that this is their intention, but one possibility is > this: > > The license to edit, copy, modify, or use XBRL is not royalty-free. One > of us could submit an idea to them and they could copyright the text or > submit a patent covering the idea. This could come back to bite the uF > community if the idea is useful because XBRL would have rights to that > idea and the text surrounding the idea. > > I wouldn't give any feedback until Rohit can take a look at their IP > Policy and get back to us on a reasonable way to move forward, if there > is any. > > Sorry Diane, the fact that you're creating a "standard" that is not > royalty-free to everybody shows that XBRL is currently not interested in > the type of open standards that this community creates. > > You should have a chat with Rohit Khare - he handles all legal matters > regarding this community. He is cc'ed on this e-mail. > > -- manu > > [1]http://www.xbrl.org/Legal2/XBRL-IP-Policy-2007-02-20.pdf > > -- > Manu Sporny > President/CEO - Digital Bazaar, Inc. > blog: RDFa Basics in 8 minutes (video) > http://blog.digitalbazaar.com/2008/01/07/rdfa-basics/ > -- Vice President, New Market Development Justsystems (c) 604.765.3635 (skype) xbrlspy (work email) diane@justsystems.com (alt email) Dmueller2001@gmail.com From andy at pigsonthewing.org.uk Thu Feb 7 01:06:23 2008 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Thu Feb 7 01:08:02 2008 Subject: [uf-dev] Specification for Inline XBRL 0.54 In-Reply-To: <62325ff60802061622n75d2795dpd0930cf4569c57af@mail.gmail.com> References: <62325ff60802061622n75d2795dpd0930cf4569c57af@mail.gmail.com> Message-ID: In message <62325ff60802061622n75d2795dpd0930cf4569c57af@mail.gmail.com>, Diane Mueller writes >The Rendering Working Group (RWG) of XBRL International has released >the first public working draft of the "Inline XBRL" specification. >Inline XBRL is a standard for embedding XBRL fragments into an HTML >document. And XBRL is used for..? -- Andy Mabbett From tantek at cs.stanford.edu Thu Feb 7 12:04:50 2008 From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik) Date: Thu Feb 7 13:42:26 2008 Subject: [uf-dev] need for mfo / encapsulation / forward-compatible parsing (was re: changes...) In-Reply-To: <47AB4911.5020809@digitalbazaar.com> Message-ID: On 2/7/08 10:08 AM, "Manu Sporny" wrote: > It invalidates the need for "mfo" in hcard, doesn't it? > If it were applied to the rest of Microformats, it would invalidate the > need for "mfo" entirely. This is one of the reasons "mfo" has not progressed much further than the examples given in mfo-examples - it hasn't been necessary in practice. However, mfo may be needed for current parsers to be able to properly encapsulate new microformats that come along (this is often referred to as forward-compatible parsing), in the same way that they can explicitly do so with the limited set of existing microformats. As this topic is more related to parsing, I think the -dev list (on the To line) may be the more appropriate place to discuss it, while hopefully sympathetically taking into consideration the additional authoring cost/requirement of adding "mfo" (or whatever we come up with) as an additional class name to new compound microformats' root elements, e.g. class="mfo hunknown". Tantek From derrick at pallas.us Thu Feb 7 21:52:53 2008 From: derrick at pallas.us (Derrick Lyndon Pallas) Date: Thu Feb 7 21:55:55 2008 Subject: [uf-dev] need for mfo / encapsulation / forward-compatible parsing (was re: changes...) In-Reply-To: References: Message-ID: <47ABEE35.1080606@pallas.us> Tantek ? elik wrote: > However, mfo may be needed for current parsers to be able to properly > encapsulate new microformats that come along (this is often referred to as > forward-compatible parsing), in the same way that they can explicitly do so > with the limited set of existing microformats I am obligated to point out that this topic comes up every six months, and has for several years now; it is on time once again. (See you again in September.) ~Derrick From lee.jordan at gmail.com Fri Feb 8 13:24:30 2008 From: lee.jordan at gmail.com (Lee Jordan) Date: Fri Feb 8 13:24:32 2008 Subject: [uf-dev] hRecipe Mockup Message-ID: Hi folks, I'm new around these parts. I thought I might have a go at marking up a recipe with a possible hRecipe. It's just an example, with measurements marked up as such which means they can be converted, click the convert link by the measure convention information. The JS conversion script I wrote is very buggy, I did have it converting back to metric based on what a certain abbr tag was set to, it's proof of concept only. Tried to add other existing microformats in there too, even some of the text has em tags to emphasise parts of instructions, styled to be more readable too! I think hmeasure is going to be very useful, for currency, temperature and so forth. The number of times I've seen oven temperatures written in three formats, well I think hmeasure could really help. Any news on work on hmeasure? I've added a couple of non-spec bits: * measure-convention to aid conversions * dietry-suitable and equally dietry-unsuitable as dietry I thought didn't mean anything! * duration <- it's not in a vevent block but borrows its design, only having one instance of duration was restrictive. Here's the example: http://www.leejordan.org.uk/microformats/hrecipe/ The recipie is CC-AttibSA, it's my own apple crumble, but the code I'm happy to be public domain. Any feedback welcome and I work these suggestions in. I've tried to reuse as many existing microformats as possible the code is clunky and the styling a bit basic. Many Thanks Lee -- HTML | CSS | Javascript http://www.leejordan.org.uk From martin at malditainternet.com Fri Feb 8 17:43:19 2008 From: martin at malditainternet.com (Martin Sarsale) Date: Fri Feb 8 20:43:42 2008 Subject: [uf-dev] hRecipe Mockup In-Reply-To: References: Message-ID: On Feb 8, 2008 6:24 PM, Lee Jordan wrote: > Hi folks, > I'm new around these parts. I thought I might have a go at marking up > a recipe with a possible hRecipe. have you seen RecipeML? (kinda oldschool :) RecipeML is a format for representing recipes on computer. It is written in the increasingly popular Extensible Markup Language - XML. http://www.formatdata.com/recipeml/index.html From lee.jordan at gmail.com Sat Feb 9 10:34:41 2008 From: lee.jordan at gmail.com (Lee Jordan) Date: Sat Feb 9 10:34:45 2008 Subject: [uf-dev] hRecipe Mockup In-Reply-To: References: Message-ID: Yeah I based the markup on the RecipeML example stuff on the wiki. XML is great, I don't ever see webpages being written using it though on a large scale, not when a lot of HTML developers don't know what < em > is there for. On Feb 9, 2008 1:43 AM, Martin Sarsale wrote: > On Feb 8, 2008 6:24 PM, Lee Jordan wrote: > > Hi folks, > > I'm new around these parts. I thought I might have a go at marking up > > a recipe with a possible hRecipe. > > have you seen RecipeML? (kinda oldschool :) > > RecipeML is a format for representing recipes on computer. It is > written in the increasingly popular Extensible Markup Language - XML. > http://www.formatdata.com/recipeml/index.html > _______________________________________________ > microformats-dev mailing list > microformats-dev@microformats.org > http://microformats.org/mailman/listinfo/microformats-dev > -- HTML | CSS | Javascript http://www.leejordan.org.uk From mdagn at spraci.com Sat Feb 9 15:54:31 2008 From: mdagn at spraci.com (Michael MD) Date: Sat Feb 9 16:41:14 2008 Subject: [uf-dev] hRecipe Mockup In-Reply-To: Message-ID: <200802100041.m1A0fAN00388@proxy.syd.comcen.com.au> >It's just an example, with measurements marked up as such which means >hey can be converted, click the convert link by the measure Will software using hMeasure need to use a database of all commonly used measurment units and alternate spellings of the units? (eg metre/meter, litre/liter) >I've added a couple of non-spec bits: >* measure-convention to aid conversions >* dietry-suitable and equally dietry-unsuitable as dietry I thought >didn't mean anything! dietry-suitable - will that be a list of predefined standard keywords used there? If someone were to aggregate recipies and make them searchable and then someone wanted to search for a list of recipies suitable for people with a specific food intolerance (eg: wheat allergy), I think it could be helpful if some kind of standard vocabulary could be used. >* duration <- it's not in a vevent block but borrows its design, only >having one instance of duration was restrictive. Clearly so ... the start datetime (important in hCalendar) would not be needed for this, but durations clearly are important! Btw could there be a way to distinguish the duration "total time" from a duration of an individual step? From martin at malditainternet.com Sun Feb 10 08:03:56 2008 From: martin at malditainternet.com (Martin Sarsale) Date: Sun Feb 10 08:04:00 2008 Subject: [uf-dev] hRecipe Mockup In-Reply-To: References: Message-ID: On Feb 9, 2008 3:34 PM, Lee Jordan wrote: > Yeah I based the markup on the RecipeML example stuff on the wiki. XML > is great, I don't ever see webpages being written using it though on a > large scale, not when a lot of HTML developers don't know what < em > > is there for. yes, yes, I was just pointing it because I was not sure if you were basing on it or not. I'll implement it as soon as I can have around 4000 recipes at my site :) From lee.jordan at gmail.com Mon Feb 11 01:15:18 2008 From: lee.jordan at gmail.com (Lee Jordan) Date: Mon Feb 11 01:15:24 2008 Subject: [uf-dev] hRecipe Mockup In-Reply-To: <200802100041.m1A0fAN00388@proxy.syd.comcen.com.au> References: <200802100041.m1A0fAN00388@proxy.syd.comcen.com.au> Message-ID: On Feb 9, 2008 11:54 PM, Michael MD wrote: > > >It's just an example, with measurements marked up as such which means > >hey can be converted, click the convert link by the measure > > Will software using hMeasure need to use a database of all commonly used > measurment units and alternate spellings of the units? > (eg metre/meter, litre/liter) > > >I've added a couple of non-spec bits: > >* measure-convention to aid conversions > >* dietry-suitable and equally dietry-unsuitable as dietry I thought > >didn't mean anything! > > dietry-suitable - will that be a list of predefined standard keywords used > there? > > If someone were to aggregate recipies and make them searchable and > then someone wanted to search for a list of recipies suitable for people > with a specific food intolerance (eg: wheat allergy), I think it could be > helpful if some kind of standard vocabulary could be used. > > >* duration <- it's not in a vevent block but borrows its design, only > >having one instance of duration was restrictive. > > Clearly so ... > the start datetime (important in hCalendar) would not be needed for this, > but durations clearly are important! > > Btw could there be a way to distinguish the duration "total time" from a > duration of an individual step? Dietry: Could do with some work on this, it could again follow the abbr design pattern and include in the title as a coded reference string. veg:vegan:lact:wheat:halal, harder work for the parsers though, but easier than marking up each deitry requirement word and in any case my spelling or wirless keyboard is terrible, "dietary" lol. dietary-allergy="" could mark out allergies, you could then search on alergies and requirements differently, ie vegetarian but avoiding wheat. Either way dietary requirements I think should have an importance in the "relevance" of a recipe to a person. Units: I had trouble actually with the expanded title of the measurement unit. It makes sense if it's in an abbr to write grams, ounces etc, but that's really a headache for parsers and yeah you'd need a database of known units. Duration: Agreed, I think it's wise to stray away from a vevent restriction on durations. In the example you could put a duration on each li tag in the method block? Step one takes this long, step 2 takes that long and so forth and derive a total duration from that. -- HTML | CSS | Javascript http://www.leejordan.org.uk From lee.jordan at gmail.com Mon Feb 11 01:21:37 2008 From: lee.jordan at gmail.com (Lee Jordan) Date: Mon Feb 11 01:21:39 2008 Subject: [uf-dev] hRecipe Mockup In-Reply-To: References: Message-ID: On Feb 10, 2008 4:03 PM, Martin Sarsale wrote: > On Feb 9, 2008 3:34 PM, Lee Jordan wrote: > > Yeah I based the markup on the RecipeML example stuff on the wiki. XML > > is great, I don't ever see webpages being written using it though on a > > large scale, not when a lot of HTML developers don't know what < em > > > is there for. > > yes, yes, I was just pointing it because I was not sure if you were > basing on it or not. > I'll implement it as soon as I can have around 4000 recipes at my site :) > Oh yeah, basing it on RecipeML for sure. I mean I don't see all food sites using rML and XSLT to make XHTML and doing all kinds of transformations and then CSS on top, just to mark up a recipe on a website and get it on the screen. I've got nothing against XML but for web markup it just didn't kick off. From brian.suda at gmail.com Mon Feb 11 01:29:55 2008 From: brian.suda at gmail.com (Brian Suda) Date: Mon Feb 11 01:29:57 2008 Subject: [uf-dev] hRecipe Mockup In-Reply-To: References: <200802100041.m1A0fAN00388@proxy.syd.comcen.com.au> Message-ID: <21e770780802110129w10fd5a2k5a0884a7ff6d6311@mail.gmail.com> 2008/2/11, Lee Jordan : > Dietry: Could do with some work on this, it could again follow the > abbr design pattern and include in the title as a coded reference > string. ... > Units: I had trouble actually with the expanded title of the > measurement unit. ... > Duration: Agreed, I think it's wise to stray away from a vevent > restriction on durations. ... if we are going to talk about a Recipe format, then it is best discussed on the -new list, not the -dev list. Thanks, -brian -- brian suda http://suda.co.uk From lee.jordan at gmail.com Mon Feb 11 01:47:52 2008 From: lee.jordan at gmail.com (Lee Jordan) Date: Mon Feb 11 01:47:56 2008 Subject: [uf-dev] hRecipe Mockup In-Reply-To: <21e770780802110129w10fd5a2k5a0884a7ff6d6311@mail.gmail.com> References: <200802100041.m1A0fAN00388@proxy.syd.comcen.com.au> <21e770780802110129w10fd5a2k5a0884a7ff6d6311@mail.gmail.com> Message-ID: On Feb 11, 2008 9:29 AM, Brian Suda wrote: > 2008/2/11, Lee Jordan : > > Dietry: Could do with some work on this, it could again follow the > > abbr design pattern and include in the title as a coded reference > > string. ... > > > Units: I had trouble actually with the expanded title of the > > measurement unit. ... > > > Duration: Agreed, I think it's wise to stray away from a vevent > > restriction on durations. ... > > if we are going to talk about a Recipe format, then it is best > discussed on the -new list, not the -dev list. > > Thanks, > -brian No probs, cheers for the prompt. -- HTML | CSS | Javascript http://www.leejordan.org.uk From gareth at morethanseven.net Mon Feb 18 15:11:25 2008 From: gareth at morethanseven.net (gareth rushgrove) Date: Mon Feb 18 15:11:28 2008 Subject: [uf-dev] Microformats for Write APIs Message-ID: <9011f7c70802181511w4314d9adl49395c425f3388ae@mail.gmail.com> Hi Guys A post to this list seemed in order after a few discussions at SemanticCamp over the weekend. At this stage this is basically a pre-idea, floated to see if their is any general interest. The idea of using Microformats as a replacement for a seperate API layer has been mooted for a while*. But in general this has been a discussion about Read APIs (ie. asking for data) as apposed to Write APIs (ie. adding data). I'm interested in the idea of using microformats to auto-discover Write API functions. So a simple case might be: 1. Point a parser at a blog post page 2. Parser establishes that a form exists 3. Parser works out the method (GET, POST, PUT, DELETE, etc.) 4. Parser works out the form parameters, their input types and whether or not they are required 5. Parser can produce API docs So for instance taking Flickr as an example. Flickr allows comments on Photos from the photo page. eg. http://www.flickr.com/photos/garethr/2275608910/ Flickr also allows you to add comments via the API. http://www.flickr.com/services/api/flickr.photos.comments.addComment.html Standardisation might be interesting here as well. For instance back to blog comments. Comments from within aggregators would likely be simpler where comment form definitions can be established programmatically. Let me know what you think about the general idea. Gareth * http://allinthehead.com/retro/301/can-your-website-be-your-api -- Gareth Rushgrove garethrushgrove.com morethanseven.net getjobsin.com isitbirthday.com From lists at ben-ward.co.uk Mon Feb 18 15:43:53 2008 From: lists at ben-ward.co.uk (Ben Ward) Date: Mon Feb 18 15:44:16 2008 Subject: [uf-dev] Microformats for Write APIs In-Reply-To: <9011f7c70802181511w4314d9adl49395c425f3388ae@mail.gmail.com> References: <9011f7c70802181511w4314d9adl49395c425f3388ae@mail.gmail.com> Message-ID: <77ADB316-D7FC-4404-9211-FB4C36839DCB@ben-ward.co.uk> On 19 Feb 2008, at 00:11, gareth rushgrove wrote: > Let me know what you think about the general idea. I wondered once about using microformat class names on form fields (at the time motivated by the desire the desire for a less-appalling browser auto-complete). Something akin to this:
Author
1). A question that stays relevant to microformats-dev: Would the above mark-up, right now, cause a world of pain in parsers? 2). The rest of this discussion is probably best moved to microformats-discuss please, Gareth. ;-) Ben