Comments on OPML 2 expanded Attribute

In response to Dave's proposal to add an expanded attribute to the OPML 2.0 spec, I have the following thoughts.

  1. Typo: "Its optional" should be "It's optional"
  2. 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 expansionState element 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)?
  3. If the expanded attribute is added to the OPML spec, I suppose there will be a forumlaic relationship between it and the expansionState element. In other words, given a certain expansionState state, I will be able to calculate the expanded attribute for each node, and vice versa. Query:
    • If expansionState is given, may a processor ignore the expanded attributes?
    • If expanded attributes are given, may (or must) expansionState be given?
    • Is it a validation error if both expansionState and expanded attributes are given, but they are inconsistent with one another?

My 2 cents.

Published By
Categorized as post Tagged

3 comments

  1. Pingback: Scripting News for 8/31/07 « Scripting News Annex

  2. Dan, thanks for the comments, and they are given extra weight because you’ve developed in this area.

    You’re right, if this makes it into the spec, confusion wiht expansionState must be addressed, and we must say what is to happen when the two disagree. That argues strongly in favor of not including it. (Truth be told, I’m leaning toward not including it myself, but I wanted to have a thorough discussion of it and sensed that we could have one at this point.)

    The only reason to include it is so that there’s a greater chance of compatibility between the tools that depend on its existence. But that’s the reason for having a spec in the first place. 😆

Comments are closed.