RE: [uf-discuss] Microformats vs XML
Well XML isn't really supported by all browsers. If I markup some data like: calendar xmlns=http://example.org/myformat/; date1/23/2005/date eventBlah/event /calendar A browser can't by default render that as it could if that was (x)html markup. That's one benefit of Microformats is that it is designed for humans first, unlike XML languages. Where the redundancy comes in is in the form of XML feeds such as RSS and ATOM. These type of feeds are separate from your main content (i.e. your website) but they contain duplicate content from your website. I guess what I'm looking for is discussion on why would one choose Microformats over XML languages or any other popular means of embedding data. Perhaps I should look at how Microformats contrast with Dublin Core/RDF. My article discusses the principles and benefits of Microformats, but I haven't had a really strong discussion of why not use XML or RDF as well as the weaknesses of Microformats. Thanks for the feedback! Phil -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steven Livingstone Sent: Wednesday, April 26, 2006 10:53 PM To: microformats-discuss@microformats.org Subject: [uf-discuss] Microformats vs XML I'm not wholly convinced they compete to be honest. Xml is very easily authored as well, is supported by all browsers i believe, as well as most applications now - not sure where the redundancy comes from - you use what you want. Xml is far better supported in terms of toolset and validation. It also has powerful technologies around it and i find it hard to know what i would use Microformats over Xml - i'd always go with Xml - unless i was embedding certain data within an XHTML document, but that's because there is now support for Microformats, not because Xml wouln't do it (remembering that XHTML and co. are Xml in any case). Just to be clear, the Xml communities have been creating standards for a number of years and there has been literally hundreds of effors and many standards are in use today - commercial and non-commercial. I'd say the cooo thing about Microformats is they are a look at something in a new way (not replacing anything as such). If anything it competes perhaps against Dublin Core/RDF when embedded in XHTML documents, however, i do believe Microformats are something entirly new (maybe an argument agsinst Smart Tags and so on could be made). Regards, Steven Steven Livingstone http://stevenR2.com -- Original Message -- From: Phil Haack [EMAIL PROTECTED] Reply-To: Microformats Discuss microformats-discuss@microformats.org Date: Wed, 26 Apr 2006 17:35:25 -0700 I am writing an article for an online development magazine on Microformats and I'm looking for some good online discussions on the benefits of Microformats over XML. So far I have: Reduced Redundancy (ex. RSS) Browser Support for Microformats since it builds on HTML. Ease of authorship Are there any others I am missing? Is there a good discussion you could point me to? I searched and didn't find a whole lot. I may be using the wrong search terms. ;) Phil ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats vs XML
Le 06-04-27 à 15:08, Phil Haack a écrit : My article discusses the principles and benefits of Microformats, but I haven't had a really strong discussion of why not use XML or RDF as well as the weaknesses of Microformats. There are benefits and weaknesses and sometimes with the same argument. Though it's not necessary specific to microformats, but more about nature of information and authoring. For example, * ease of authoring * abbr class=dtstart title=19970903T163000ZSeptember 3, 1997, 16:30/abbr attribute content Here there is a redundancy of information, one which is easily accessible, the content part of the element, and one which is not easily accessible the title attribute part. A simple user will easily change the content part but will most of the time forget the title attribute, which makes the processing wrong. Human editing factor unfortunately. I had already the problem for some pages. And I repeat, it's not specific to microformats. The only solution to cope with that is to have an authoring tool which knows about the synchronization, but then it means that the authoring tool can produce other formats as well (ics, rdf, txt, etc.) * management issue and legacy data * It's very easy to create information in a specific page. That's cool. It means that anyone can enrich one page with explicit data more than implicit data. But it's also easy to forget to update data and create then legacy content. * The specific weaknesses of microformats are seen as benefits by others depending on how you look at them. Nobody is wrong or right, it's more a question of context and what you want to achieve. Crawl the archive of the list and you will find many discussions (or ratholes depending on how you want to see them) I have only one strong concern with my W3C hat is that the semantics of title attributes has been abused (here you will have different opinions too on that topic). For your article, maybe more on comparing things, you could say what are the different ways to achieve certain things with microformats, XML, RDF and then talk about the things you can do or not do with each parts. More than the bad or good dichotomy which increases bitterness and doesn't achieve much. -- Karl Dubost - http://www.w3.org/People/karl/ W3C Conformance Manager, QA Activity Lead QA Weblog - http://www.w3.org/QA/ *** Be Strict To Be Cool *** ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Microformats vs XML
For your article, maybe more on comparing things, you could say what are the different ways to achieve certain things with microformats, XML, RDF and then talk about the things you can do or not do with each parts. More than the bad or good dichotomy which increases bitterness and doesn't achieve much. That's a great point. I didn't intend to portray things in a good/bad or better/worse light. The question that was posed to me is Why do we need Microformats when we have XML schemas and languages? So what I'm looking for are various discussions on what microformats accomplish that XML language formats don't do as well given the goals of microformats. Then I hope to contrast this by pointing out situations in which XML may be much better suited than microformats. The obvious example when your audience really aren't humans (machine data interchange). Phil ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats vs XML
So what I'm looking for are various discussions on what microformats accomplish that XML language formats don't do as well given the goals of microformats. It's worth considering that microformats can be embedded in any XML document where (X)HTML can be used... From: http://microformats.org/wiki/ quote Semantic HTML Design Principles XHTML is built on XML, and thus XHTML based formats can be used not only for convenient display presentation, but also for general purpose data exchange. In many ways, XHTML based formats exemplify the best of both HTML and XML worlds. /quote As far as I can tell, it's a whole lot easier to embed HTML in content enclosed by XML formats like Atom or RDF/RSS, rather than the other way round. Also, with regards to the earlier point about Dublin Core - the DC standard is mostly about specifying an set of metadata elements to record information about items in a large collection of content. So it is similar to Microformats like hReview in some respects, though more general, and more complex. But DC elements are not specifically tied to XML syntax, they could be serialized in any number of ways (same goes for RDF too). I see the main contrast being in terms of generality vs specificity. Each Microformat is targeted at a single specific problem, and attempts to solve it in a simple way focusing on common use cases. Many other formats (RDF in particular) are designed to solve general and much broader problems across a range of domains. Hope this helps. /Mark ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Microformats vs XML
Phil - I had some thoughts. In the past i have been involved in a number of efforts on Xml and the one thing that always seemed to happen was that a 2500 page spec emerged. Less formal creations such as RSS never suffered from that as much (in constrast to say NewsML which had a much more specific goal - the XSD is around 30 pages long). Look at the contrast of something like XML-RPC versus SOAP/WSDL and so on. The former does a nice job for online services without too much effort - the latter can require a LOT of work (although tool support is getting better) and is better suited in formal environments. Don't get me wrong, there is sometimes a need for detailed specs and so on, but there is also a need for simple, effective formats, which Microformats do very well. Another thing, if you are constrasting with Xml, is that Microformats already have job in mind when the format is created. With Xml it it very flexible and no-one has adopted a single way of doing some of the things the Microformats community seem to have. Some time back i wanted to create xfrag.org which was to have the intention of small schema fragments (name, addres etc) that could be re-used in Xml compliant documents. But then we had a baby :) Also, RDF, OWL and so on can be very abstract and tricky to understand, whereas Microformats have a very specific task in mind, making it easy for the user (and consumer) to know what the intention is. Steven Livingstone http://stevenR2.com ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Microformats vs XML
Phil - I had some thoughts. In the past i have been involved in a number of efforts on Xml and the one thing that always seemed to happen was that a 2500 page spec emerged. Less formal creations such as RSS never suffered from that as much (in constrast to say NewsML which had a much more specific goal - the XSD is around 30 pages long). Look at the contrast of something like XML-RPC versus SOAP/WSDL and so on. The former does a nice job for online services without too much effort - the latter can require a LOT of work (although tool support is getting better) and is better suited in formal environments. Don't get me wrong, there is sometimes a need for detailed specs and so on, but there is also a need for simple, effective formats, which Microformats do very well. Another thing, if you are constrasting with Xml, is that Microformats already have job in mind when the format is created. With Xml it it very flexible and no-one has adopted a single way of doing some of the things the Microformats community seem to have. Some time back i wanted to create xfrag.org which was to have the intention of small schema fragments (name, addres etc) that could be re-used in Xml compliant documents. But then we had a baby :) Also, RDF, OWL and so on can be very abstract and tricky to understand, whereas Microformats have a very specific task in mind, making it easy for the user (and consumer) to know what the intention is. Steven Livingstone http://stevenR2.com ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats vs XML
For example, * ease of authoring * abbr class=dtstart title=19970903T163000ZSeptember 3, 1997, 16:30/abbr attribute content Here there is a redundancy of information, one which is easily accessible, the content part of the element, and one which is not easily accessible the title attribute part. A simple user will easily change the content part but will most of the time forget the title attribute, which makes the processing wrong. Human editing factor unfortunately. I had already the problem for some pages. And I repeat, it's not specific to microformats. I think there needs to be editing software that can detect an attempt to edit the content part and present the appropriate form for entering the date The only solution to cope with that is to have an authoring tool which knows about the synchronization, but then it means that the authoring tool can produce other formats as well (ics, rdf, txt, etc.) I think we must start thinking about how to implement all this. (maybe I need to look at the microformats-dev list?) I'm actually here looking for practical ideas for building tools for embedding/syndicating data that can be used by people such as events promoters without requiring them to have prior knowledge of html/xml/etc. I have not yet seen anything out there that is even remotely suitable for this - I think I need to write my own - and using microformats to embed such data in html looks like a nice way to do it. Here is an example of the sort of thing I could use it for: - I run a busy nightlife/events listings website. ( http://www.spraci.com/ ) The normal way for people to add events to the listings is via forms on the website. Some events promoters are lazy and just add my email address to their mailing lists assuming there is someone with the time to enter their event for them (this is not the case at all! ... they are used to dealing with street press for publicity - street press usually have sufficient advertising revenue to hire data entry staff - not the case with most websites - definately not the case with any sites run in a long-term sustainable way that are not associated with print media) Most of those emails are html emails often with little more than an image of the flyer for their next event. (so presently most such emails received here are simply trashed - I tell them they must use the forms or provide automated means to update their listings such as data feeds) Wouldn't it be nice if there was a tool they could use to easily embed vevent data (combined with location data like hcard for the venue and a list of category tags) into their html emails so that listings sites they send it to can extract the data? ... or they could use hcalendar markup on their own website and submit their events page as a feed... ... either way authoring tools for the masses are needed and if none exist I will have to build them... ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Microformats vs XML
Yes - I was tempted to add such a comment, but don't know Microformats well enough yet. I'm certainly not knocking standards or modularization, but practical experience has show to me that simple can also be effective. RSS (as an example) has remained very simple ever since it was created and XML-RPC has also remained so along with many others. Sure, there have been additions on top of RSS, but fundamentally it is easy to get your head around what is required to get started. Hence they have remained popular even longer than 5 years after being created. In contrast if you consider RDF, OWL etc - they are not particularly easy to get running with. There is quite a learning curve, but having used them for a number of years I appreciate what they can do and why the specs make them so powerful. However, there have also been a number of efforts that have disappeared off the map because of over engineering (over-modularization). The first paragraph of Uche Ogbuji's IBM article sums it up for me: http://www-128.ibm.com/developerworks/xml/library/x-stand2.html It's certainly nothing specific to Microformats, but more a web 2.0 view on things where simplicity is being particularly effective. Regards, Steven http://stevenR2.com -Original Message- From: Karl Dubost [mailto:[EMAIL PROTECTED] Sent: 27 April 2006 11:08 To: [EMAIL PROTECTED]; Microformats Discuss Subject: Re: [uf-discuss] Microformats vs XML Le 06-04-27 à 16:50, Steven Livingstone a écrit : Less formal creations such as RSS never suffered from that as much (in constrast to say NewsML which had a much more specific goal - the XSD is around 30 pages long). Look at the contrast of something like XML-RPC versus SOAP/WSDL and so on. The former does a nice job for online services without too much effort - the latter can require a LOT of work (although tool support is getting better) and is better suited in formal environments. Don't get me wrong, there is sometimes a need for detailed specs and so on, but there is also a need for simple, effective formats, which Microformats do very well. That is called Modularization and has nothing to do with microformats but the choice of structural organization of a technology. What you said is valid for *any* specifications. Take the microformats in 5 years, add all the modules (hcard, hreview, ) etc. And you will have a huge specification too. -- Karl Dubost - http://www.w3.org/People/karl/ W3C Conformance Manager, QA Activity Lead QA Weblog - http://www.w3.org/QA/ *** Be Strict To Be Cool *** ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats vs XML
Off List because off topic Le 06-04-27 à 20:16, Steven Livingstone a écrit : RSS (as an example) has remained very simple ever since it was created and XML-RPC has also remained so along with many others. Sure, there have been and In contrast if you consider RDF, OWL etc - they are not particularly easy to get running with. There is quite a learning curve, but having used them for Unrelated. You do not compare the same thing at all :) You could compare an application of RDF Ex: FOAF, SKOS, RSS 1.0 with an application of XML Ex: XHTML, RSS 2.0, Atom The first paragraph of Uche Ogbuji's IBM article sums it up for me: http://www-128.ibm.com/developerworks/xml/library/x-stand2.html Put this first paragraph in the SGML community, and you will see the answers. Everything is a question of context. It's certainly nothing specific to Microformats, but more a web 2.0 view on things where simplicity is being particularly effective. Web 2.0 is a marketing which became a social phenomenon. Not a technology. Microformats are good for particular things. I didn't say the opposite. They have their issues and their benefits depending on the context. -- Karl Dubost - http://www.w3.org/People/karl/ W3C Conformance Manager, QA Activity Lead QA Weblog - http://www.w3.org/QA/ *** Be Strict To Be Cool *** ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Microformats vs XML
We may just be seeing this differently Karl, it's topical because it's all about data formats (sure RDF can be much more). But maybe this is not the place :) Unrelated. I can't see why. The fundamental point is about ease of usage, not technologies. You could compare an I agree. But a Microformat is what it is. You are unlikely to have an application of hCard creating a new standard. Hence the simplicity. I agree. Context is the key. I'm not arguing anything else. Hence why I do also like standards. Web 2.0 is a marketing Yes I know. But the first thing non-techhies will ask it what is it really useful for and marketing it is the key. Web 2.0 seems to have worked somewhat. This could be recursive, but I do understand your viewpoint and think we are maybe talking about different aspects of the same thing. Steven http://stevenR2.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Karl Dubost Sent: 27 April 2006 12:26 To: [EMAIL PROTECTED] Cc: 'Microformats Discuss' Subject: Re: [uf-discuss] Microformats vs XML Off List because off topic Le 06-04-27 à 20:16, Steven Livingstone a écrit : RSS (as an example) has remained very simple ever since it was created and XML-RPC has also remained so along with many others. Sure, there have been and In contrast if you consider RDF, OWL etc - they are not particularly easy to get running with. There is quite a learning curve, but having used them for Unrelated. You do not compare the same thing at all :) You could compare an application of RDF Ex: FOAF, SKOS, RSS 1.0 with an application of XML Ex: XHTML, RSS 2.0, Atom The first paragraph of Uche Ogbuji's IBM article sums it up for me: http://www-128.ibm.com/developerworks/xml/library/x-stand2.html Put this first paragraph in the SGML community, and you will see the answers. Everything is a question of context. It's certainly nothing specific to Microformats, but more a web 2.0 view on things where simplicity is being particularly effective. Web 2.0 is a marketing which became a social phenomenon. Not a technology. Microformats are good for particular things. I didn't say the opposite. They have their issues and their benefits depending on the context. -- Karl Dubost - http://www.w3.org/People/karl/ W3C Conformance Manager, QA Activity Lead QA Weblog - http://www.w3.org/QA/ *** Be Strict To Be Cool *** ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats for everyone!
Agreed. In some ways, that's the kind of information that I want to start compiling on the Practical Microformats wiki: http://microformats.pbwiki.com. Though I intend for this information to eventually be gathered on the main wiki, for now, having a separate place to concentrate solely on this effort means that we can focus, develop a better format for expressing this information as well as talk in terms that are more friendly to regular web designers and bloggers... folks who are familiar with HTML and can learn by example -- even if at first they don't quite understand the microformat concept deeply. I'm currently working with Drew McClellan, Vera Horiuchi (who is an instructional designer) and Tara Hunt (horsepigcow.com). That doesn't mean that we're necessarily creating a WYSIWYG tool ourselves (although I have some designs that I intend to mock up soon) but it does create both the context and preconditions for other parties to build these tools for us. I invite you and anyone else who's interested in the this task in barrelling through it between now and June 20, the 1-year anniversary of Microformats -- where I would like to have compiled enough solid information so that anyone -- with an iota of interest -- can come and discover what the heck it is we're talking about -- and beyond that -- begin using our tools *immediately* to add microformats to whatever project they're working on. Sound good? Chris On 4/26/06, Michael MD [EMAIL PROTECTED] wrote: Ease of authorship that is an area I want to do something about... I want to put together some tools for people to easily create content with microformats for use on anything - their own websites and feeds, html posts on other websites, clients for webservices, desktop applications, whatever... I'm talking about stuff the general public can use.. not just people who actually know about or care how its being done at the back end. I'm thinking it would be nice if there was some kind of wysiwyg html editor (like htmlarea/tinymce/etc) that could automatically detect and make available options for editing microformat content ... something that could easily be put on any website or bundled with any application. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats vs XML, redundancy
On 4/26/06 10:52 PM, Steven Livingstone [EMAIL PROTECTED] wrote: not sure where the redundancy comes from - you use what you want. The redundancy in XML (and other formats as well) comes from the fact that an element can have only one element name. Since microformats use attributes which take space separated sets (class, rel, rev), more than one element name can be given to the same piece of data, thus avoiding the need to repeat that data just because of a limitation of the syntax of the underlying metaformat. Enough gibberish - the most easy example that illustrates this is the hCard Example 1 derivation: http://microformats.org/wiki/hcard-example1-steps snipped from that page (for more context, just read the page) in vCard: N:Çelik;Tantek FN:Tantek Çelik Note the redundant data, violating DRY. As this is in vCard's syntax, it shows that the problem is not just an XML problem, however XML/RDF versions of vCard have the exact same problem. in fully spelled-out hCard: span class=fn n span class=given-nameTantek/span span class=family-nameÇelik/span /span Note that the *data* is there only once, and also matches typical publishing behavior (rarely (if ever) do people state things like: I'm going to lunch with my co-worker Ryan King (King,Ryan) in actual content on the Web). The more I switch back and forth between marking things up with microformats, and using POX (plain old XML) practices, the more I have found this problem, and am convinced that the whole one name per element was actually a mistake in XML (or perhaps SGML), but I'm certainly not going to attempt to fix either of those, preferring to instead just Get Things Done(tm) with microformats. Thanks, Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats vs XML
Scott, I wouldn't be so sure. http://msdn.microsoft.com/workshop/author/behaviors/library/calendar/calendar.asp Take a look at the example at the bottom. In my pre-semantic markup days, I've used CSS to style xml (namespaces and all) tags quite a bit. :DG On 4/27/06, Scott Reynen [EMAIL PROTECTED] wrote: On Apr 27, 2006, at 1:41 AM, Steven Livingstone wrote: Xml could be substituted for Microformats with no real side effect - render done via CSS or Xslt Really? How do I make this blue with CSS in IE: dc:creatorScott/ dc:creator? I believe the most popular web browser doesn't support selectors on namespaced tags. I'd call that a real side effect. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats vs XML
On Apr 27, 2006, at 8:06 AM, Dimitri Glazkov wrote: Scott, I wouldn't be so sure. http://msdn.microsoft.com/workshop/author/behaviors/library/ calendar/calendar.asp Take a look at the example at the bottom. In my pre-semantic markup days, I've used CSS to style xml (namespaces and all) tags quite a bit. My mistake. Apparently it's just namedspaced attributes that IE doesn't support. At least that's what I see when I try this test in IE6: http://lyceum.open.ac.uk/temp/cssns.html Or is there a workaround for this too? Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats for everyone!
On Apr 27, 2006, at 8:36 AM, Christopher St John wrote: Do you see this as being related to the uf zen garden effort? (which seems to have stalled a bit) Here's a working implementation that applies CSS and/or JS to sample microformat template pages: http://randomchaos.com/microformats/zen/ I made this a long time ago, and was at the time expecting that someone else more experienced with the formats would want to be in charge of administering this, reviewing submissions, setting up templates, etc. but that never happened. If no one is interested in maintaining a zen garden, I'll do it, but right now it looks to me like something people like to discuss in the abstract, but wouldn't actually use in practice. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats for everyone!
On 27 Apr 2006, at 1:59 PM, Michael MD wrote: Ease of authorship that is an area I want to do something about... I want to put together some tools for people to easily create content with microformats for use on anything - their own websites and feeds, html posts on other websites, clients for webservices, desktop applications, whatever... Here, here. I'm no Mozilla hacker, but if you're ambitious you could write a XPI plug-in for NVu[1]. I also know that Dreamweaver has some kind of extension architecture, but wouldn't even know where to begin with that one. If you're looking to create Joe User tools, these are two programs which would be a good starting point. [1]: http://www.nvu.com/ -- Ryan Cannon Interactive Developer MSI Student, School of Information University of Michigan http://RyanCannon.com/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Microformats vs XML, redundancy
Tantek, I really need to catch up on reading this stuff, but I'll go with my thoughts as I'll learn more about Microformats that way :) The real benefit as I see it is that with some fairly simple CSS formatting you can have different views on your hCard. It is great for people who want to avoid Xml and JavaScript. The DRY bit I miss a little - I understand your example but why couldn't it be done within Xml or RDF using the ID and IDREF or even using Xslt. In fact CSS (and a little JavaScript XPath) could render it pretty good just as Xml using DRY principles. In fact if I wanted to stay Very DRY, I'd optionally assign a hCard URI to each component and allow them to be universally referenced maybe through the Xslt document() function. Btw - the Microformats WIKI works well. Probably the most effective use of Wiki tech I've seen. Steven http://stevenR2.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tantek Ç elik Sent: 27 April 2006 14:00 To: microformats-discuss Subject: Re: [uf-discuss] Microformats vs XML, redundancy On 4/26/06 10:52 PM, Steven Livingstone [EMAIL PROTECTED] wrote: not sure where the redundancy comes from - you use what you want. The redundancy in XML (and other formats as well) comes from the fact that an element can have only one element name. Since microformats use attributes which take space separated sets (class, rel, rev), more than one element name can be given to the same piece of data, thus avoiding the need to repeat that data just because of a limitation of the syntax of the underlying metaformat. Enough gibberish - the most easy example that illustrates this is the hCard Example 1 derivation: http://microformats.org/wiki/hcard-example1-steps snipped from that page (for more context, just read the page) in vCard: N:Çelik;Tantek FN:Tantek Çelik Note the redundant data, violating DRY. As this is in vCard's syntax, it shows that the problem is not just an XML problem, however XML/RDF versions of vCard have the exact same problem. in fully spelled-out hCard: span class=fn n span class=given-nameTantek/span span class=family-nameÇelik/span /span Note that the *data* is there only once, and also matches typical publishing behavior (rarely (if ever) do people state things like: I'm going to lunch with my co-worker Ryan King (King,Ryan) in actual content on the Web). The more I switch back and forth between marking things up with microformats, and using POX (plain old XML) practices, the more I have found this problem, and am convinced that the whole one name per element was actually a mistake in XML (or perhaps SGML), but I'm certainly not going to attempt to fix either of those, preferring to instead just Get Things Done(tm) with microformats. Thanks, Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats for everyone!
In fact there already is a Dreamweaver extension: http://www.webstandards.org/action/dwtf/microformats/ Also, I'm posting all the useful links I come across to a Ma.gnolia group (delicious competitor): http://ma.gnolia.com/groups/microformats Anyone is welcome to join. Chris On 4/27/06, Ryan Cannon [EMAIL PROTECTED] wrote: On 27 Apr 2006, at 1:59 PM, Michael MD wrote: Ease of authorship that is an area I want to do something about... I want to put together some tools for people to easily create content with microformats for use on anything - their own websites and feeds, html posts on other websites, clients for webservices, desktop applications, whatever... Here, here. I'm no Mozilla hacker, but if you're ambitious you could write a XPI plug-in for NVu[1]. I also know that Dreamweaver has some kind of extension architecture, but wouldn't even know where to begin with that one. If you're looking to create Joe User tools, these are two programs which would be a good starting point. [1]: http://www.nvu.com/ -- Ryan Cannon Interactive Developer MSI Student, School of Information University of Michigan http://RyanCannon.com/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats for everyone!
I do, though perhaps orthogonally, as in someone would use Practical Microformats as a resource for both understanding microformats and applying them to their existing work... At the same time, I'd love to see styled examples of hCard, hCalendar and the like be linked to from the PM wiki. Do we have an SVN repository posted anywhere for this kind of thing? I'd love to offer my TextDrive SVN account for this -- but I've never successfully set up or configured such a thing. Chris On 4/27/06, Christopher St John [EMAIL PROTECTED] wrote: On 4/27/06, Chris Messina [EMAIL PROTECTED] wrote: Agreed. In some ways, that's the kind of information that I want to start compiling on the Practical Microformats wiki: http://microformats.pbwiki.com folks who are familiar with Chris, Do you see this as being related to the uf zen garden effort? (which seems to have stalled a bit) -cks -- Christopher St. John http://eventmirror.com http://artofsystems.blogspot.com ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] admin question
Tantek =?ISO-8859-1?B?xw==?=elik [EMAIL PROTECTED] writes: Welcome Nic! First take a look at the FAQ: http://microformats.org/wiki/faq then, if you're still having problems, follow-up here and indicate what specific username you are trying to create. whoops! But in my defence the username requirement are unusual. Perhaps the link to the FAQ entry should come up more prominently on login error? Thanks for your help. Nic ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
question about client-side xslt rendering (was Re: [uf-discuss] Microformats vs XML, redundancy)
while we are on this topic, I saw real world examples of generating microformat (well, sort of) by client-side xslt rendering. To put it concrete: - The server generates XML page with link to xslt file. - xslt file includes instructions of generating Microformats. - modern browser happily render the XML page with xslt. - however greasemonkey script or some other tools don't do dynamic rendering by default. So on the positive side, both XML and Microformats are avaiable; on the negative side, this pattern may not be well supported by some tools. My questions are : (1) is this a solved problem? does Microformats encourage (allow) this practice? (2) how well is it supported by Microformats tools? thanks, xiaoming ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: question about client-side xslt rendering (was Re: [uf-discuss] Microformats vs XML, redundancy)
Microformats can be built on HTML 4.0 and newer, because of this there are a few minor issues that make it difficult to depend on client-side XSLT. The simplest issues are well-formedness and validity, but simpler things like br being br/ and img being img/ are all important to XSLT processors. The Microsoft Live Clipboard uses XPATH, but not XSLT on the client-side with javascript. All other implementations that are using XSLT are doing so server side, for several reasons. 1) you can clean-up the input 2) you can manage errors better So to answer your questions: (1) is this a solved problem? does Microformats encourage (allow) this practice? --- i don't think this is a solved problem (althought i'm not sure what the problem really is?) There are several client-side implementations such as Tails[1]. I think a combination of client-side and server-side options are important. Server-side options are important for content developers, by using these web services, site owners can link to them and have their vCard/iCal/AtomFeeds all created for a user no matter what their browser. Client-side options are important because they can be used to find encoded data, and have the ability to extract data that is behind authentication - something server-side implementations can not really do. The downside to client-side options is adoption of the tools to do so. Tails is great for Firefox, but there currently isn't that support for IE (i don't think IE applies XSLT transformations either? partly because they do not use the application/xml mime-type - someone will correct me if i am wrong) (2) how well is it supported by Microformats tools? Well if it is client-side then the biggest tool at the moment is Tails[1], there are also XSLT files available for download for hCalendar[4]/hCard[3]/hAtom[5] which can be used client-side. I hope that helps answer your questions, or at least starts down the right path. -brian [1] - http://blog.codeeg.com/tails-firefox-extension [2] - http://spaces.msn.com/editorial/rayozzie/demo/liveclip/liveclipsample/clipboardexample.html [3] - http://suda.co.uk/projects/X2V/xhtml2vcard.xsl [4] - http://suda.co.uk/projects/X2V/xhtml2vcal.xsl [5] - http://rbach.priv.at/hAtom2Atom/ Xiaoming Liu wrote: while we are on this topic, I saw real world examples of generating microformat (well, sort of) by client-side xslt rendering. To put it concrete: - The server generates XML page with link to xslt file. - xslt file includes instructions of generating Microformats. - modern browser happily render the XML page with xslt. - however greasemonkey script or some other tools don't do dynamic rendering by default. So on the positive side, both XML and Microformats are avaiable; on the negative side, this pattern may not be well supported by some tools. My questions are : (1) is this a solved problem? does Microformats encourage (allow) this practice? (2) how well is it supported by Microformats tools? thanks, xiaoming ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats vs XML
My mistake. Apparently it's just namedspaced attributes that IE doesn't support. At least that's what I see when I try this test in IE6: http://lyceum.open.ac.uk/temp/cssns.html Or is there a workaround for this too? Nope (or yep, if you don't mind using JS). But not because of the namespaces -- IE (IE6, that is) doesn't support attribute selectors. :DG ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Microformats vs XML
Neither it seems does IE 7 (beta 2) - again, without JS. Would be nice to add for completeness. Steven http://stevenR2.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dimitri Glazkov Sent: 27 April 2006 16:55 To: Microformats Discuss Subject: Re: [uf-discuss] Microformats vs XML My mistake. Apparently it's just namedspaced attributes that IE doesn't support. At least that's what I see when I try this test in IE6: http://lyceum.open.ac.uk/temp/cssns.html Or is there a workaround for this too? Nope (or yep, if you don't mind using JS). But not because of the namespaces -- IE (IE6, that is) doesn't support attribute selectors. :DG ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats for everyone!
On Apr 27, 2006, at 7:19 AM, Chris Messina wrote: Do we have an SVN repository posted anywhere for this kind of thing? I'd love to offer my TextDrive SVN account for this -- but I've never successfully set up or configured such a thing. We have a mercurial sever at http://hg.microformats.org/. -ryan ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: question about client-side xslt rendering (was Re: [uf-discuss] Microformats vs XML, redundancy)
This helps a lot, and I still have remaining issues: say I have an xml file personfnfoo/fnlnbar/ln/person In order to use client-side xslt to render this xml file, and make sure the result is Microformats-compliant, I wrote an xslt file microformats.xsl, and insert a link to xslt in xml file: ?xml version=1.0 encoding=UTF-8 standalone=yes? ?xml-stylesheet href=microformat.xsl type=text/xsl? personfnfoo/fnlnbar/ln/person This file can be rendered in IE and Firefox, because they do xslt client-side rendering, so the display is correct, but when I check page source, it's still the raw xml file. And when writing a script to fetch Microformats fragments, I have to do XSLT rendering first to get HTML back. So I am wondering if the above scenario is a good practice, and how well it's supported by current Microformats tools. thanks, xiaoming On Thu, 27 Apr 2006, brian suda wrote: Microformats can be built on HTML 4.0 and newer, because of this there are a few minor issues that make it difficult to depend on client-side XSLT. The simplest issues are well-formedness and validity, but simpler things like br being br/ and img being img/ are all important to XSLT processors. The Microsoft Live Clipboard uses XPATH, but not XSLT on the client-side with javascript. All other implementations that are using XSLT are doing so server side, for several reasons. 1) you can clean-up the input 2) you can manage errors better So to answer your questions: (1) is this a solved problem? does Microformats encourage (allow) this practice? --- i don't think this is a solved problem (althought i'm not sure what the problem really is?) There are several client-side implementations such as Tails[1]. I think a combination of client-side and server-side options are important. Server-side options are important for content developers, by using these web services, site owners can link to them and have their vCard/iCal/AtomFeeds all created for a user no matter what their browser. Client-side options are important because they can be used to find encoded data, and have the ability to extract data that is behind authentication - something server-side implementations can not really do. The downside to client-side options is adoption of the tools to do so. Tails is great for Firefox, but there currently isn't that support for IE (i don't think IE applies XSLT transformations either? partly because they do not use the application/xml mime-type - someone will correct me if i am wrong) (2) how well is it supported by Microformats tools? Well if it is client-side then the biggest tool at the moment is Tails[1], there are also XSLT files available for download for hCalendar[4]/hCard[3]/hAtom[5] which can be used client-side. I hope that helps answer your questions, or at least starts down the right path. -brian [1] - http://blog.codeeg.com/tails-firefox-extension [2] - http://spaces.msn.com/editorial/rayozzie/demo/liveclip/liveclipsample/clipboardexample.html [3] - http://suda.co.uk/projects/X2V/xhtml2vcard.xsl [4] - http://suda.co.uk/projects/X2V/xhtml2vcal.xsl [5] - http://rbach.priv.at/hAtom2Atom/ Xiaoming Liu wrote: while we are on this topic, I saw real world examples of generating microformat (well, sort of) by client-side xslt rendering. To put it concrete: - The server generates XML page with link to xslt file. - xslt file includes instructions of generating Microformats. - modern browser happily render the XML page with xslt. - however greasemonkey script or some other tools don't do dynamic rendering by default. So on the positive side, both XML and Microformats are avaiable; on the negative side, this pattern may not be well supported by some tools. My questions are : (1) is this a solved problem? does Microformats encourage (allow) this practice? (2) how well is it supported by Microformats tools? thanks, xiaoming ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: question about client-side xslt rendering (was Re: [uf-discuss] Microformats vs XML, redundancy)
Xiaoming Liu wrote: This helps a lot, and I still have remaining issues: say I have an xml file personfnfoo/fnlnbar/ln/person In order to use client-side xslt to render this xml file, and make sure the result is Microformats-compliant, I wrote an xslt file microformats.xsl, and insert a link to xslt in xml file: ?xml version=1.0 encoding=UTF-8 standalone=yes? ?xml-stylesheet href=microformat.xsl type=text/xsl? personfnfoo/fnlnbar/ln/person This file can be rendered in IE and Firefox, because they do xslt client-side rendering, so the display is correct, but when I check page source, it's still the raw xml file. And when writing a script to fetch Microformats fragments, I have to do XSLT rendering first to get HTML back. So I am wondering if the above scenario is a good practice, and how well it's supported by current Microformats tools. --- Well, the above scenario isn't really supported because Microformats are in HTML as class values, not as XML Node names. You have just taken the Property Names we used in hCard, which we derived from vCard and made an XML file with corresponding node names. So this really isn't a microformat at all, and therefore not supported by our tools. The tools right now are looking for microformats within HTML, not an XML file. Now you said that you are converting the XML to HTML with microformats. Since this is done on the client-side, you are at the mercy of each client. IE and Firefox, as you have noted, are just DISPLAYING the rendered HTML, but the underlying file is still the XML. -brian ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: question about client-side xslt rendering (was Re: [uf-discuss] Microformats vs XML, redundancy)
On Apr 27, 2006, at 12:03 PM, Xiaoming Liu wrote: This file can be rendered in IE and Firefox, because they do xslt client-side rendering, so the display is correct, but when I check page source, it's still the raw xml file. And when writing a script to fetch Microformats fragments, I have to do XSLT rendering first to get HTML back. So I am wondering if the above scenario is a good practice You might want to look at this site: http://w3future.com/ I vaguely recall Sjoerd tried to run his entire site as you've described and it lasted a few weeks before he ran into enough problems that he now does server-side XSLT to HTML 4 unless you click the Try XHTML 2.0 button, which turns off the server-side XSLT. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
