Talk:OPML

From Wikipedia, the free encyclopedia

Is there a reason, other than a flipside to the proponents of OPML, that there is a link to troll blog post about OPML? Unless someone can argue for it, I'm going to recommend removing it from the list of external links. DClifton 07:48, 4 March 2006 (UTC)

"Crappy Crappy format", not a very encyclopaedic reference, and a bit vulgar. I concur. --Skoorb 22:26, 10 March 2006 (UTC)

Removed. DClifton 06:04, 22 March 2006 (UTC)

With the discussion about RFC 2822 / RFC 822, what about RFC 3339 and ISO 8601?



This article seems to violate NPOV and advocate a specific approach to XML design (tags vs. attributes). Attributes are pretty widely used in data-style formats (as opposed to narrative and template doctypes). They are also useful to limit format bloat by restricting a value to simple character data (or other scalar values that may be serialized as such). If RSS had used attributes for titles, for example, the tendency to use inconsistently-encoded HTML titles might have been limited. HTML uses "title" attributes to provide simple character information available only upon request that should not interrupt the normal text flow. There is a rational balance between "elements and attributes. Brianiac 15:58, 31 May 2006 (UTC)


Completely agree. Attributes are marginally harder to process in XPATH (one extra character is involved) but there is no real difference in the data structure beyond that: if an XML element is terminal then the same data can be isomorphically represented either as elements or as attributes. I vote this is removed as it is generic criticism of XML that there are two ways to encode the same thing, not a specific criticism of OPML (and there are many good reasons why attributes were chosen.) I'm adding this to my watch list and the attribute criticism will be removed if I don't see any counter arguments.

The criticism that is valid is that the decision to encode data as attributes limits the ability to enforce common semantics on attributes like "type". Presumably the author of the criticism feels that an opml entry should read something like

<outline>
   <link>htpp://www.example.com/example.rss</link>
</outline>

Why the type attribute is replaced by an explicit list of alternate element names. If that's what they feel, could they say so more clearly?

Even if the criticism stands, could we at least tone down the language? I don't really see how you violate a design principle. A design principle is just a principle, it is not a rule. You can ignore a design principle, but it has no force in the spec.

NB, I've just noted the same element/attribute trolling in criticism of OML. Please keep your religious war off of wikipedia. It may be that the author is not a particularly experienced user of XML as claims such as "the use of attributes limits hierarchical markup" and "makes it harder to see in a web browser" are nonsensical (because a: a well defined DTD would preclude you from adding arbitrary hierarchical information anyway and b: it's only a difference in the way you choose to render the content and which browser you use)

--Jim68000 17:24, 16 January 2007 (UTC)


Wish I hadn't started reading this now. This is also technically incorrect:

"OPML stores data in XML attributes, which violates a common XML design principle. Due to that, it's not possible to reliably store data with multiple lines or consecutive spaces, because XML parsers may normalize whitespace in attributes."

XML Parsers may also normalise whitespace in XML elements if no instruction is given: see http://www.w3.org/TR/2006/REC-xml-20060816/#sec-white-space - OPML 1.0 provides no instruction, and the data types stored also do not permit sequential spaces or end-of-line markers (URLs for example). It's hard to see what the data the author wants to see in OPML thart would require this


--Jim68000 17:33, 16 January 2007 (UTC)

Actually, sod it, I'm just pulling it out. The two links that purpot to demonstrate that OPML should have used elements actually do no such thing. The perfectxml.com just presents a list of ways you can encode data in either way without really providing a conclusion, while the IBM link actually contains the line ("If the information is intended to be read and understood by a person, use elements. In general this guideline places prose in element content. If the information is most readily understood and digested by a machine, use attributes. In general this guideline means that information tokens that are not natural language go in attributes.") which would mean that by these lights OPML is entirely correct.

--Jim68000 17:40, 16 January 2007 (UTC)