In 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 eliminating
expansionState. 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 the
expansionStateelement. In other words, given a certain
expansionStatestate, I will be able to calculate the
expandedattribute for each node, and vice versa. Query:
expansionStateis given, may a processor ignore the
expandedattributes are given, may (or must)
- Is it a validation error if both
expandedattributes are given, but they are inconsistent with one another?
My 2 cents.