Comments on OPML 2 expanded Attribute
31 August 2007In response to Dave's proposal to add an expanded attribute to the OPML 2.0 spec, I have the following thoughts.
Typo: "Its optional" should be "It's optional"- As a general matter, I'm not convinced that this belongs in the spec. It seems to me that display properties are the application's problem, not the file format's. Others have complained about the
expansionStateelement for the same reason -- of course, that's a spec legacy and eliminating it would cause breakage so I'm not suggesting eliminatingexpansionState. But why further muddle the OPML spec? If a particular application needs to store the expansion state on a per node level, then why not create a new namespace attribute (or use an existing one)? - If the
expandedattribute is added to the OPML spec, I suppose there will be a forumlaic relationship between it and theexpansionStateelement. In other words, given a certainexpansionStatestate, I will be able to calculate theexpandedattribute for each node, and vice versa. Query:- If
expansionStateis given, may a processor ignore theexpandedattributes? - If
expandedattributes are given, may (or must)expansionStatebe given? - Is it a validation error if both
expansionStateandexpandedattributes are given, but they are inconsistent with one another?
- If
My 2 cents.

