Andrew, that's a key point, and it came up earlier, when Dan MacTough
made what has been a common request, that the spec list all the node
types. I said that I was reluctant to do that because the OPML Editor
has a very powerful extension mechanism that keys off the type
attribute, and that while the question comes up often, I was more
likely to add some text to the Extending OPML section than do anything
that would limit the number of types.

Your comment here, which I assume comes without knowledge of the
feature of the OPML Editor (please confirm) says the concept is
important and understandable even if you just know the format and not
the tool. The downside is that this presents a problem for the
validator, and it's going to be a FAQ, and may well be a "snipe
vector" but WTF, those are not impossible to overcome.

Dave


---------------
Andrew Grumet said: "Getting back to the spec, what weighs on my mind
most heavily is the Extending OPML section.   It would seem like the
OPMLish way to handle extension would be not through new elements (or
at least not primarily so), but rather through new node types, with
each specifying its required and optional attributes.  There may be
practical or cultural issues with this, I haven't considered it too
deeply.  Thoughts?"

Hi folks,

I sat down tonight with printouts of the version 1.0 and draft version
2.0 specs, and also read through the mails that have come through
since I started receiving them.  Here are a few comments.

The new version is looking great, a lot of richness and possibility
are apparent.  It's particularly gratifying to see the new include
type, which I think will open up distributed directories in a big way,
and also the documentation for subscription lists.  The latter is
particularly helpful to me because GigaDial is currently outputting
"link" types (!)

On that note, and referring back to

> 2. Interesting point about aggregators and directories with links (and
> now in 2.0 include's). Not sure what the spec should say here though,
> maybe it would make sense as a Note? What would the note say?

It should probably be a Note, perhaps covering approaches that others
have found workable.  iPodder/Juice accepts both "rss" and "link"
types according to the following rules:

   For type="link", take the outline's text attribute as the feed title and
   take the outline's url attribute as the rss link.

   For type="rss",  take the outline's title attribute as the feed title and
   take the outline's xmlUrl attribute as the rss link.

When handling "link", the code assumes, for better or worse, an
out-of-band understanding betweeen the publisher and consumer the OPML
file is a directory of RSS feeds.

Getting back to the spec, what weighs on my mind most heavily is the
Extending OPML section.   It would seem like the OPMLish way to handle
extension would be not through new elements (or at least not primarily
so), but rather through new node types, with each specifying its
required and optional attributes.  There may be practical or cultural
issues with this, I haven't considered it too deeply.  Thoughts?

Andrew

I'm going to post an edited version of the email I sent to you all and
open this mail list to the public tomorrow morning.

If you want to write about OPML 2.0 tonight or tomorrow, feel free to
do so. You can point to the draft spec as well.

I expect the review period to last a month or more. During that time
the word DRAFT will appear in the title and there will be a caveat at
the the top, and the Roadmap will say it's not a spec yet, and it's
not frozen.

Comments and feedback will be considered and thought about, and your
opinions will continue to be relevant all through teh review period.

Thanks to Dan, Brent, Nick, Bela and Sean for their comments duing the
early review.

Onward!

Dave

I've just made a bunch of changes in response to the feedback here,
especially in the area of subscription lists.

http://www.opml.org/stories/storyReader$270

The new text is in green, text that has been removed is striked through.

Comments, of course, are welcome.

Dave

Cool, I'll give this some more thought.

Maybe this time the encoding wonks, who may be tired of being drags on
progress (I'm getting the feeling that's what's happening) may decide
to help instead of taking shots from the cheap seats.

This time at least there is no competing format for them to slog.

(Actually not totally true, there is XOXO, but that doesn't seem to
have much traction these days.)

Dave


--- In opml2-review@yahoogroups.com, Brent Simmons <brents@...> wrote:
>
> I have a bias toward assuming plain text -- but there's nothing
specially
> compelling about that, it's just a personal bias.
>
> If assuming markup makes more sense, given the tools, that's cool by me.
> Being able to specify that it is or is not markup is the key -- so
that we
> can deal with "Go three miles and then turn west <right> at Idaho
route 27
> - don't <blink> or you'll miss it" properly.
>
> In other words, I think we agree.
>
> -Brent
>
> PS About being open to an attack -- that's why I mention the *type* of
> markup being a possible issue. I don't know if it is an issue. But I
don't
> want OPML 2.0 to have problems just because we don't distinguish
HTML from
> XHTML. (Somebody someday will want to know what to do with "<br>" in
text.)
>
> The pragmatic definition of markup -- that which you can pass to a
browser
> and expect it to render -- may not always make the grade with everybody.
> (Even though with me, for my purposes, the pragmatic definition is
fine.)
>
> On the other hand, I could be going too far, being too paranoid. But
I note
> that Atom specifies the type of markup.
>
> On 2/28/06 4:20 PM, "Dave Winer" <dave.winer@...> wrote:
>
> > Interesting, and that makes sense, but in my world, I have to assume
> > that text contains markup, because my users are using the outliner for
> > (among other things) a blogging tool.
> >
> > Let's understand the tradeoff. Suppose you guess wrong and some text
> > is not encoded but you treat it as if it were.
> >
> > Then suppose Uncle Joe includes in his directions to his hunting lodge
> > the following statement.
> >
> > "Go three miles and then turn west (right) at Idaho route 27."
> >
> > What's the harm? Nothing changed. A few cycles got wasted (maybe). Now
> > this might be a problem if Joe used some special encoding characters
> > in his directions, but unless Joe is writing documentation for HTML
> > technical users it's not very likely to appear in his directions to a
> > hunting lodge, or say his recipe for turnip pie, or Aunt Louisa's
> > NewsGator subscription list, for that matter.
> >
> > Maybe I'm missing soemthing horribly obvious and opening myself up to
> > an attack on some XML mail list somewhere, if so I apologize to
the gods.
> >
> > Comments?
> >
> >
> >
> >
> >
> > --- In opml2-review@yahoogroups.com, Brent Simmons <brents@> wrote:
> >>
> >> On 2/28/06 6:16 AM, "Dave Winer" <dave.winer@> wrote:
> >>> 4. I like the idea for the isMarkup attribute, but if we do it, it
> >>> would default the other way, to true, since that's what all the
> >>> outlines out there in the field are now, and further it will save a
> >>> space in OPML files down the road. Also I'd use a name that
indicates
> >>> that it applies to the text attribute, something like
textIsMarkup. To
> >>> everyone else, feedback is requested on this, it's new behavior in
> >>> OPML, and addresses the number one issue that people complain
about in
> >>> RSS. Here's our chance to not have that be an issue in OPML 2.0.
> >>
> >> I agree that textIsMarkup is a good idea. Will it matter that the
> > *type* of
> >> markup is not specified?
> >>
> >> I've always assumed that the text is *not* markup, as most every OPML
> >> processor that I use (whether an aggregator or outliner) displays
> > plain text
> >> rather than OPML.
> >>
> >> -Brent
>

I've just made a bunch of changes in response to the feedback here,
especially in the area of subscription lists.

http://www.opml.org/stories/storyReader$270

The new text is in green, text that has been removed is striked through.

Comments, of course, are welcome.

Dave

I have a bias toward assuming plain text -- but there's nothing specially
compelling about that, it's just a personal bias.

If assuming markup makes more sense, given the tools, that's cool by me.
Being able to specify that it is or is not markup is the key -- so that we
can deal with "Go three miles and then turn west <right> at Idaho route 27
- don't <blink> or you'll miss it" properly.

In other words, I think we agree.

-Brent

PS About being open to an attack -- that's why I mention the *type* of
markup being a possible issue. I don't know if it is an issue. But I don't
want OPML 2.0 to have problems just because we don't distinguish HTML from
XHTML. (Somebody someday will want to know what to do with "<br>" in text.)

The pragmatic definition of markup -- that which you can pass to a browser
and expect it to render -- may not always make the grade with everybody.
(Even though with me, for my purposes, the pragmatic definition is fine.)

On the other hand, I could be going too far, being too paranoid. But I note
that Atom specifies the type of markup.

On 2/28/06 4:20 PM, "Dave Winer" <dave.winer@...> wrote:

> Interesting, and that makes sense, but in my world, I have to assume
> that text contains markup, because my users are using the outliner for
> (among other things) a blogging tool.
>
> Let's understand the tradeoff. Suppose you guess wrong and some text
> is not encoded but you treat it as if it were.
>
> Then suppose Uncle Joe includes in his directions to his hunting lodge
> the following statement.
>
> "Go three miles and then turn west (right) at Idaho route 27."
>
> What's the harm? Nothing changed. A few cycles got wasted (maybe). Now
> this might be a problem if Joe used some special encoding characters
> in his directions, but unless Joe is writing documentation for HTML
> technical users it's not very likely to appear in his directions to a
> hunting lodge, or say his recipe for turnip pie, or Aunt Louisa's
> NewsGator subscription list, for that matter.
>
> Maybe I'm missing soemthing horribly obvious and opening myself up to
> an attack on some XML mail list somewhere, if so I apologize to the gods.
>
> Comments?
>
>
>
>
>
> --- In opml2-review@yahoogroups.com, Brent Simmons <brents@...> wrote:
>>
>> On 2/28/06 6:16 AM, "Dave Winer" <dave.winer@...> wrote:
>>> 4. I like the idea for the isMarkup attribute, but if we do it, it
>>> would default the other way, to true, since that's what all the
>>> outlines out there in the field are now, and further it will save a
>>> space in OPML files down the road. Also I'd use a name that indicates
>>> that it applies to the text attribute, something like textIsMarkup. To
>>> everyone else, feedback is requested on this, it's new behavior in
>>> OPML, and addresses the number one issue that people complain about in
>>> RSS. Here's our chance to not have that be an issue in OPML 2.0.
>>
>> I agree that textIsMarkup is a good idea. Will it matter that the
> *type* of
>> markup is not specified?
>>
>> I've always assumed that the text is *not* markup, as most every OPML
>> processor that I use (whether an aggregator or outliner) displays
> plain text
>> rather than OPML.
>>
>> -Brent

Interesting, and that makes sense, but in my world, I have to assume
that text contains markup, because my users are using the outliner for
(among other things) a blogging tool.

Let's understand the tradeoff. Suppose you guess wrong and some text
is not encoded but you treat it as if it were.

Then suppose Uncle Joe includes in his directions to his hunting lodge
the following statement.

"Go three miles and then turn west (right) at Idaho route 27."

What's the harm? Nothing changed. A few cycles got wasted (maybe). Now
this might be a problem if Joe used some special encoding characters
in his directions, but unless Joe is writing documentation for HTML
technical users it's not very likely to appear in his directions to a
hunting lodge, or say his recipe for turnip pie, or Aunt Louisa's
NewsGator subscription list, for that matter.

Maybe I'm missing soemthing horribly obvious and opening myself up to
an attack on some XML mail list somewhere, if so I apologize to the gods.

Comments?





--- In opml2-review@yahoogroups.com, Brent Simmons <brents@...> wrote:
>
> On 2/28/06 6:16 AM, "Dave Winer" <dave.winer@...> wrote:
> > 4. I like the idea for the isMarkup attribute, but if we do it, it
> > would default the other way, to true, since that's what all the
> > outlines out there in the field are now, and further it will save a
> > space in OPML files down the road. Also I'd use a name that indicates
> > that it applies to the text attribute, something like textIsMarkup. To
> > everyone else, feedback is requested on this, it's new behavior in
> > OPML, and addresses the number one issue that people complain about in
> > RSS. Here's our chance to not have that be an issue in OPML 2.0.
>
> I agree that textIsMarkup is a good idea. Will it matter that the
*type* of
> markup is not specified?
>
> I've always assumed that the text is *not* markup, as most every OPML
> processor that I use (whether an aggregator or outliner) displays
plain text
> rather than OPML.
>
> -Brent
>

Brent, thanks for the comments.

1. See my note to Bela about this case-sensitivity in names.

2. Interesting point about aggregators and directories with links (and
now in 2.0 include's). Not sure what the spec should say here though,
maybe it would make sense as a Note? What would the note say?

I got an email from Chris Pirillo (he's part of the early review
group) a few days ago about autodiscovery for OPML. That's something
we documented a number of years ago for Radio, and wonder if perhaps
that shouldn't also be included here. How to link from a HTML page to
an OPML file. Sean, do you think that would be useful?

Dave



--- In opml2-review@yahoogroups.com, Brent Simmons <brents@...> wrote:
>
> A couple notes...
>
> 1. In the final spec we might want to make a point that attribute
names are
> case-sensitive. This is just because there's some confusion in
subscription
> lists about xmlURL vs. xmlurl etc.
>
> 2. I'm wondering about OPML files that are not subscription lists
but that
> contain the URLs of websites -- OPML directory files, for instance.
Should
> there be guidelines for how aggregators import these?
>
> Users often expect them to "just work." For instance, the directory at
> iPodder.org is (or used to be) a collection of web page URLs rather
than RSS
> feed URLs. Last time I checked, BlogRolling.com OPML files didn't
contain
> xmlUrls either, but people expect them to be importable nonetheless.
>
> I bring this us just because standard behavior (use auto-discovery
or notify
> the user of an error or whatever) would be helpful.
>
> -Brent
>
>
> On 2/28/06 5:32 AM, "Dave Winer" <dave.winer@...> wrote:
>
> > Welcome to a bunch of new reviewers this morning.
> >
> > Here's the pointer to the draft spec.
> >
> > http://www.opml.org/stories/storyReader$270
> >
> > All the caveats and disclaimers apply.
> >
> > Dave
>

Bela, thanks for the comments. I'm working through these in reverse
order for some reason. Brent's are next. :-)

1. I agree that the subscription lists section is confusing. I plan to
work there.

2. Got it about url being required for link.

3. Interesting point about case-sensitivity in attribute names, but
names in XML are case-sensitive, so that's covered by saying that OPML
documents are XML.

Dave



--- In opml2-review@yahoogroups.com, Bela Labovitch <blabovitch@...>
wrote:
>
>
> The OPML 2.0 spec looks good - great to see ideas that have been
discussed this past year becoming part of a formal spec.
>
> There are three areas of the spec document that perhaps could be
more clear (esp. for a newbie who is seeing OPML for the first time)
>
>   a) Under Subscription Lists
>     The text "title is probably the same as text, it should not be
omitted" is confusing.
>       It is not in the required attributes listed above - so saying
'should not be omitted' is
>       a little ambiguous.
>
> b) It would be helpful to make it clear that type=link expects a url
attribute.
>
>   c) Clarifying that the attributes are case sensitive would be
helpful - especially the xmlUrl attribute.
>
>   I may have missed a few messages, so I hope this isn't redundant
feedback.
>
>   -Bela
>
>
>
>
> ---------------------------------
>  Yahoo! Mail
>  Use Photomail to share photos without annoying attachments.
>

Sean, see my response to Nick for an explanation of the purpose of
title. I think however, I should expand the section on subscription
lists, given that it's the largest application of OPML to date. Dave



--- In opml2-review@yahoogroups.com, Sean Lyndersay <seanlynd@...> wrote:
>
> I agree. This is good, especially formalizing Subscription Lists
into the OPML spec.
>
> One thought is that is to drop (deprecate) the title attribute,
since, as you note, it's often (always?) the same as text, and it's
not clear what a processor should do with it.
>
> ________________________________
>
> From: opml2-review@yahoogroups.com
[mailto:opml2-review@yahoogroups.com] On Behalf Of Bela Labovitch
> Sent: Tuesday, February 28, 2006 11:45 AM
> To: opml2-review@yahoogroups.com
> Subject: [opml2-review] Feedback on OPML 2.0 spec
>
>
> The OPML 2.0 spec looks good - great to see ideas that have been
discussed this past year becoming part of a formal spec.
>
> There are three areas of the spec document that perhaps could be
more clear (esp. for a newbie who is seeing OPML for the first time)
>
> a) Under Subscription Lists
>     The text "title is probably the same as text, it should not be
omitted" is confusing.
>     It is not in the required attributes listed above - so saying
'should not be omitted' is
>     a little ambiguous.
>
> b) It would be helpful to make it clear that type=link expects a url
attribute.
>
> c) Clarifying that the attributes are case sensitive would be
helpful - especially the xmlUrl attribute.
>
> I may have missed a few messages, so I hope this isn't redundant
feedback.
>
> -Bela
>
>
> ________________________________
>
> Yahoo! Mail
> Use Photomail to share photos without annoying attachments.
>
> SPONSORED LINKS
>
> Xml format
>
> Xml
>
> ________________________________
>
> YAHOO! GROUPS LINKS
>
>
>  Visit your group "opml2-review" on the web.
>
>  To unsubscribe from this group, send an email to:
>  opml2-review-unsubscribe@yahoogroups.com
>
>  Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
>
> ________________________________
>

First a disclaimer -- these are my thoughts, not spec text.

Unfortunately it's necessary for me to say that. :-(

Nick, you got it right, except I don't think of "text" as a title. It
could be thought of as notes or a description, just as easily.

Remember there's a dual purpose going on here, for which I apologize,
but it's real nonetheless. The O and the P in OPML stand for Outline
Processor, this is very much the file format for a productivity tool.
It's very useful to be able to edit, combine and organize subscription
lists in an outliner. When I do the demo in my OPML Roadshow that's
where I get the oooh's and ahhhh's -- when I open two subscription
lists and drag-drop between them.

When generating a subscription list algorithmically, the initial value
of "text" should e the title of the feed being described, but it's
user-editable and the value of text should be preserved and everything
should work if the user edits the text. You may still need to have the
feed title around. (Maybe not, that's why it's a should and not a must.)

Also, remember that in RSS, channel-level title is required. So you
pretty much always have it around. (Unless it's a malformed feed.)

Dave



--- In opml2-review@yahoogroups.com, "Nick Bradbury"
<nick.bradbury@...> wrote:
>
> I agree that the wording about 'title' is unclear.  My understanding
is that
> 'title' would be the actual title element from the feed, while
'text' would
> be the title the user gave to the feed (ie: they renamed the feed in
their
> subscriptions).  Is this correct?
>
> - Nick Bradbury
>
>
> On 2/28/06, Sean Lyndersay <seanlynd@...> wrote:
> >
> >  I agree. This is good, especially formalizing Subscription Lists
into the
> > OPML spec.
> >
> >
> >
> > One thought is that is to drop (deprecate) the title attribute,
since, as
> > you note, it's often (always?) the same as text, and it's not
clear what a
> > processor should do with it.
> >
> >
> >  ------------------------------
> >
> > *From:* opml2-review@yahoogroups.com
[mailto:opml2-review@yahoogroups.com]
> > *On Behalf Of *Bela Labovitch
> > *Sent:* Tuesday, February 28, 2006 11:45 AM
> > *To:* opml2-review@yahoogroups.com
> > *Subject:* [opml2-review] Feedback on OPML 2.0 spec
> >
> >
> >
> >
> > The OPML 2.0 spec looks good - great to see ideas that have been
discussed
> > this past year becoming part of a formal spec.
> >
> >
> > There are three areas of the spec document that perhaps could be more
> > clear (esp. for a newbie who is seeing OPML for the first time)
> >
> >
> >
> > a) Under *Subscription Lists**
> > *    The text "title is probably the same as text, it should not be
> > omitted" is confusing.
> >
> >     It is not in the required attributes listed above - so saying
'should
> > not be omitted' is
> >
> >     a little ambiguous.
> >
> >
> > b) It would be helpful to make it clear that *type*=link expects a
*url *
> > attribute.
> >
> >
> >
> > c) Clarifying that the attributes are case sensitive would be
helpful -
> > especially the *xmlUrl* attribute.
> >
> >
> >
> > I may have missed a few messages, so I hope this isn't redundant
feedback.
> >
> >
> >
> > -Bela
> >
> >
> >
> >
> >  ------------------------------
> >
> > Yahoo! Mail
> > Use
Photomail<http://us.rd.yahoo.com/mail_us/taglines/pmall2/*http:/photomail.mail.y\
ahoo.com>to
share photos without annoying attachments.
> >
> > SPONSORED LINKS
> >
> > Xml
format<http://groups.yahoo.com/gads?t=ms&k=Xml+format&w1=Xml+format&w2=Xml&c=2&s\
=25&.sig=qDgDBfeOngCTZLKc5M2LHQ>
> >
> >
Xml<http://groups.yahoo.com/gads?t=ms&k=Xml&w1=Xml+format&w2=Xml&c=2&s=25&.sig=g\
SMXWznWNzbN4rF1bSymYQ>
> >
> >
> >  ------------------------------
> >
> > YAHOO! GROUPS LINKS
> >
> >
> >
> >    -  Visit your group
"opml2-review<http://groups.yahoo.com/group/opml2-review>"
> >    on the web.
> >
> >    -  To unsubscribe from this group, send an email to:
> >
opml2-review-unsubscribe@yahoogroups.com<opml2-review-unsubscribe@...\
m?subject=Unsubscribe>
> >
> >    -  Your use of Yahoo! Groups is subject to the Yahoo! Terms of
> >    Service <http://docs.yahoo.com/info/terms/>.
> >
> >
> >  ------------------------------
> >
> >  ------------------------------
> > YAHOO! GROUPS LINKS
> >
> >
> >    -  Visit your group
"opml2-review<http://groups.yahoo.com/group/opml2-review>"
> >    on the web.
> >
> >    -  To unsubscribe from this group, send an email to:
> >
opml2-review-unsubscribe@yahoogroups.com<opml2-review-unsubscribe@...\
m?subject=Unsubscribe>
> >
> >    -  Your use of Yahoo! Groups is subject to the Yahoo! Terms of
> >    Service <http://docs.yahoo.com/info/terms/>.
> >
> >
> >  ------------------------------
> >
>
>
>
> --
> Nick Bradbury
> Architect, Client Products
> NewsGator Technologies, Inc.
> http://www.newsgator.com/
>

On 2/28/06 10:08 AM, "Brent Simmons" <brents@...> wrote:

> On 2/28/06 6:16 AM, "Dave Winer" <dave.winer@...> wrote:
>> 4. I like the idea for the isMarkup attribute, but if we do it, it
>> would default the other way, to true, since that's what all the
>> outlines out there in the field are now, and further it will save a
>> space in OPML files down the road. Also I'd use a name that indicates
>> that it applies to the text attribute, something like textIsMarkup. To
>> everyone else, feedback is requested on this, it's new behavior in
>> OPML, and addresses the number one issue that people complain about in
>> RSS. Here's our chance to not have that be an issue in OPML 2.0.
>
> I agree that textIsMarkup is a good idea. Will it matter that the *type* of
> markup is not specified?
>
> I've always assumed that the text is *not* markup, as most every OPML
> processor that I use (whether an aggregator or outliner) displays plain text
> rather than OPML.

In case that's confusing -- "rather than HTML" is what I meant.

-Brent

On 2/28/06 6:16 AM, "Dave Winer" <dave.winer@...> wrote:
> 4. I like the idea for the isMarkup attribute, but if we do it, it
> would default the other way, to true, since that's what all the
> outlines out there in the field are now, and further it will save a
> space in OPML files down the road. Also I'd use a name that indicates
> that it applies to the text attribute, something like textIsMarkup. To
> everyone else, feedback is requested on this, it's new behavior in
> OPML, and addresses the number one issue that people complain about in
> RSS. Here's our chance to not have that be an issue in OPML 2.0.

I agree that textIsMarkup is a good idea. Will it matter that the *type* of
markup is not specified?

I've always assumed that the text is *not* markup, as most every OPML
processor that I use (whether an aggregator or outliner) displays plain text
rather than OPML.

-Brent

A couple notes...

1. In the final spec we might want to make a point that attribute names are
case-sensitive. This is just because there's some confusion in subscription
lists about xmlURL vs. xmlurl etc.

2. I'm wondering about OPML files that are not subscription lists but that
contain the URLs of websites -- OPML directory files, for instance. Should
there be guidelines for how aggregators import these?

Users often expect them to "just work." For instance, the directory at
iPodder.org is (or used to be) a collection of web page URLs rather than RSS
feed URLs. Last time I checked, BlogRolling.com OPML files didn't contain
xmlUrls either, but people expect them to be importable nonetheless.

I bring this us just because standard behavior (use auto-discovery or notify
the user of an error or whatever) would be helpful.

-Brent


On 2/28/06 5:32 AM, "Dave Winer" <dave.winer@...> wrote:

> Welcome to a bunch of new reviewers this morning.
>
> Here's the pointer to the draft spec.
>
> http://www.opml.org/stories/storyReader$270
>
> All the caveats and disclaimers apply.
>
> Dave

Dan, thanks for your feedback. Very useful stuff.

1. Rather than make the initial statement in the head section more
complicated, I added a Note, number 7, that covers this. I also don't
like the term "child element" in re XML, I prefer "sub-element."

2. I want to do a much more detailed writeup of expansionState, but
probably linked to from the spec, not in the spec itself. Basically
the only people who would be interested are the very small number of
people who are working on outliners (an important group for sure).
I'll probably also supply sample code, to make sure it's clear. It's
very simple to code, not so simple to explain.

3. I used your revised text for <outline>.

4. I like the idea for the isMarkup attribute, but if we do it, it
would default the other way, to true, since that's what all the
outlines out there in the field are now, and further it will save a
space in OPML files down the road. Also I'd use a name that indicates
that it applies to the text attribute, something like textIsMarkup. To
everyone else, feedback is requested on this, it's new behavior in
OPML, and addresses the number one issue that people complain about in
RSS. Here's our chance to not have that be an issue in OPML 2.0.

5. When we're near done with this, let's have a look at the list of
types. It's a tricky question, and not one that I want to nail down
without (informed) discussion. In the OPML Editor type is the pivot
point of a powerful architecture. We're going to want to invent types
as we go along. So I'm inclined to say that that is open-ended, and
address that in the Extending OPML section. Brent, I'm sure, remembers
what I'm talking about.

6. Glad you like it. ;->

7. I don't understand.

8. We should ask the Atom people what they want to do here.

9. It's not just that I don't want to break people, I don't want to
break myself! I have been creating OPML files with inclusion since Y2K
and they all use that convention. I am a big evolution guy, I live
with my mistakes, with pride. It's much easier than trying to fix them
after so much time has passed. So you're right, I won't take you up on
this one.

Dave

Welcome to a bunch of new reviewers this morning.

Here's the pointer to the draft spec.

http://www.opml.org/stories/storyReader$270

All the caveats and disclaimers apply.

Dave

1.  A <head> contains zero or more optional elements, described below

A <head> contains zero or more optional elements, described below. No
child element of the <head> element may be repeated.

2.  <expansionState> is a comma-separated list of line numbers that are
expanded. The line numbers in the list tell you which headlines to
expand. The order is important. For each element in the list, X,
starting at the first summit, navigate flatdown X times and expand.
Repeat for each element in the list.

<expansionState> is a comma-separated list of line numbers that are
expanded. The line numbers in the list tell an OPML processor which
lines to expand. The list of line numbers must be in ascending order.
For each element in the list, X, starting at the first summit, navigate
flatdown (i.e., down among siblings and descendants of expanded
siblings) X times and expand. Repeat for each element in the list.

3. An <outline> is an XML element, possibly containing one or more
attributes, and containing any number of <outline> sub-elements. No
attribute may be repeated within the same <outline> element.

An <outline> is an XML element containing at least one required
attribute, text, and zero or more additional attributes. An <outline>
may contain zero or more <outline> sub-elements.

4. Text attributes may contain encoded HTML markup.

It looks like this is the only attribute that may contain markup.
However, there is no way for a processor to know whether text is markup
without making an educated guess based on the content of the text attribute.

I propose a new attribute, isMarkup, which if true would indicate that
the text attribute contains HTML markup. Otherwise, the text attribute
must contain plain text.

5. type is a string, it says how the other attributes of the <outline>
are interpreted

The valid values for type are ...

6. /description/ is the top-level description element from the feed

Sweet!

7. /title/ is probably the same as /text,/ it should not be omitted

/title/ is the top-level link element.

8. There are no known values for Atom feeds, but they certainly could be
provided.

Atom1 for Atom 0.3 or 1.0  (Would that work?)

9. Inclusion

I know you don't want to break things, but here's my 2 cents on this. In
OPML v. 2.0 forward, only nodes of type=include should be treated as
OPML. If the type=link in a 2.0 file, treat it like a web page -- maybe
that's what the author wants.
--
Dave, thank you for asking for my opinion.

Dan

An outliner may be able to do something with a \r or \n, in any case,
it can easily not display them, so I don't really want to make a
special provision for them in the spec.

I don't know if there's a maximum length in any particular piece of
software, but the spec says, in the Notes section, section 6, that
there is no limit on the length of any attribute.

--- In opml2-review@yahoogroups.com, "Kevin Burton" <burtonator@...>
wrote:
>
> > Welcome to Sean Lyndersay from Microsoft and Kevin Burton from
> > TailLink, the first to accept the invitation to this group (Niall
> > Kennedy has been helping me out before the invites went out). We might
> > as well get started right away.
>
>
> Hey Dave.
>
> Thanks for the invite.  This looks reallly good but I just have a few
> constructive thoughts:
>
> " Every outline element must have at least a *text* attribute, which
is what
> is displayed when an outliner
<http://support.opml.org/basicOutlining> opens
> the OPML file. To omit the text attribute would render the outline
useless
> in an outliner. This is what the user would
>
see<http://images.scripting.com/archiveScriptingCom/2005/10/14/badopml2.gif>--
> clearly an unacceptable user experience."
>
> You might want to specify that  \r or \n aren't allowed here since in an
> outliner it would be one row of text.  Also is there a max length here?
>
> " Required attributes: type, text, xmlUrl. For outline elements
whose type
> is *rss,* the *text* attribute should be the top-level title element
in the
> feed being pointed to. *xmlUrl* is the http address of the feed. '
>
> I'd note that the capitalization is important here.  NewsGator
actually uses
> 'xmlurl' in their OPML 1.0 feeds and this broke TailRank for a bit.
>
> "Optional attributes: description, htmlUrl, language, title,
version. These
> attributes are useful when presenting a list of subscriptions to a user,
> except for version, they are all derived from information in the feed
> itself."
>
> If the description from RSS 2.0 is HTML encoded does this mean it
should be
> HTML encoded in OPML 2.0?  Just throwing that out there...
>
> Also... Great idea to finally (and officially) add namespaces.
That's going
> to be a BIG win.! :-)
>
> One more note before I forget.  I assume I can have a full UTF-8 encoded
> OPML file with Farsi and Japanese content?
>
> Onward!
>
> Kevin
>
> --
> Kevin A. Burton, Location - San Francisco, CA
>       AIM/YIM - sfburtonator,  Web - http://www.feedblog.org/
> GPG fingerprint: 5FB2 F3E2 760E 70A8 6174 D393 E84D 8D04 99F1 4412
>

> http://www.opml.org/stories/storyReader$270

I don't know much about helping with the technical aspects, but the promise
of 2.0 is quite apparent with your examples. My only note is that you might
consider updating Scoble's blog URL in the SubscriptionList.opml file. :)

Oops. Second note. In the category.opml file, I noticed you had a comma
after Mets - was that intentional?

Chris

Here's the pointer to the draft spec.

http://www.opml.org/stories/storyReader$270

All the caveats and disclaimers apply.

Dave

Welcome to Sean Lyndersay from Microsoft and Kevin Burton from
TailLink, the first to accept the invitation to this group (Niall
Kennedy has been helping me out before the invites went out). We might
as well get started right away.

Here's the pointer to the draft spec.

http://www.opml.org/stories/storyReader$270

All the caveats apply, I am not a lawyer, my mother loves me, Praise
Murphy, etc.

Dave

Good morning!

First, I'd like to ask that the contents of this email be kept private
for now, I'm working on something new, that should be of interest, and
the period when it's private will be short, because of backchannel
issues. But if you can't participate in something private, please
don't read further. Thanks!

Late last year I wrote a series of RFCs and posted them on the main
OPML website, they were ideas for improvement of the format and the
documentation for OPML, and work revolving around the OPML Validator,
which was deployed in that period. All along I was planning that these
RFCs would be rolled into a new format and spec, called OPML 2.0.

It's a milestone, much like RSS 2.0 was in the summer of 2002. We now
know how OPML is being used, and where the problems are, and I think
are ready to produce a frozen and extensible format and spec. With the
OPML Editor approaching version 1.0, it's now time to get the ball
rolling on the format that comes after. The OPML Editor will likely
not ship with support for 2.0, it will be able to read 2.0 files, but
it will not write them. There's too much of a bootstrap in front of
that happening. But OPML 2.0 adds some important features, notably the
include node type, and support for namespaces, and a host of niceties,
and finally has a unified spec. I'm confident that this is the OPML
we'll all want to build on later in 2006, 2007, and beyond.

I believe the format is done, subject to your review, but the spec
certainly is not. I'm sure there are mistakes, oversights, missed
opportunities, things that require clarification. All the caveats
apply, esp Murphy's Law.

This initial review period will be very short, possibly as little as
24 hours. So I hope you can join the group, and help us get this spec
ready for broad public review. Thanks!

http://groups.yahoo.com/group/opml2-review/

Dave Winer
Scripting News