On 10/27/05, James M Snell <[EMAIL PROTECTED]> wrote: > > Luke Arno wrote: > > >Visible data. > >Principle of least invention. > >Layered semantics. > >Maintain fewer documents. > >Learn less new syntax. > >Fewest possible constraints. > > > > > > > We can achieve these goals things WITHOUT using a XHTML microformat. > What are the benefits specific to using XHTML for APP versus some other > XML schema? (Note that I did not say "versus some other XML schema > *that we invent*" ) For instance, suppose I wanted to argue that OPML > could be used for this... why is an XHTML format the better approach? > And don't just tell me "because XHTML is better than OPML", relate the > benefits back to core requirements of the Atom Publihing Protocol and > we'll be making progress. >
*Some* of those benefits would apply to any existing XML format such as OPML to varying degrees. 1. Visible data. More clients understand (X)HTML than any other format. 2. Principle of least invention. (X)HTML is the lingua franka of the web. 3. Layered semantics. XHTML has a built in facility for layered semantics through class, id, rel and other attributes. Rob's document, if he converted it to use my profile, could be seen as XML, XHTML, XOXO, and APP introspection all at once. Many parsers could use it and many systems could find meaning in it (including human beings). 4. Maintain fewer documents. Would you use OPML to publish your blog or would you also have to maintain an XHTML version (or an XSLT to produce it or whatever)? 5. Learn less new syntax. Again XHTML is the lingua franka. I would have to use references to work with OPML. It is simple but I don't use it every day. I can sit down and write XHTML from memory. 6. Fewest possible constraints. XHTML is a very flexible and if our profile just sprinkles on the extra semantics we need then the possibilities are endless *without resorting to namespace etc.* This is a shortcoming of using XOXO. Notice how in order to add seek, Rob had to throw in a namespaced attribute, and is not just using XHTML anymore. By using our own profile, we allow further extension to be done in the same way: using XHTML. The benefits do not have to apply specifically to APP to be worth considering. APP is a subset to many other broad problem domains such as representing data on the web. Atom makes sense to me but I am very conservative about inventing/using specialized XML these days. You have to have a really huge case like publishing / syndication to justify it. Tower of babel problem. > >>The first definitely deserves some strong consideration but is not, in > >>and of itself, enough of a justification. The second is questionable as > >>it has not yet been established that browser displayability is a core > >>requirement; from where I'm sitting, it's not. > >> > >> > >> > > > >You are listing benefits then jump to stating that they > >are not enough without enumerating the costs. > > > > > > > I said that reuse of an existing format, taken by itself, is not enough > of a justification to use that format. If is was, one could argue that > we shouldn't be working on Atom at all. The question hinges on whether > or not the format meets the minimum requirements without introducing too > much overhead or pain. You're proposing that we should just use XHTML > before we fully understand all of the requirements and you're touting > benefits before we fully understand whether or not those benefits are > relevant. > Lets talk turkey then. What are the pros and cons of using a microformat? We have gone over many benefits. The only real cons I have heard are parsing concerns and I think that those concerns have been shown to be unfounded. What requirement can a microformat not meet? What overhead or pain are you concerned about? How are the benefits we have covered not relevant? You can wave your hands and say general meaningless things like "that is not enough" but that leads nowhere. Please be specific. - Luke
