OK, cool, just to be clear I was saying that Josh's assumptions were not
correct. We'll take a look. Dave


----- Original Message -----
From: <hpyle@...>
To: <opml-dev@egroups.com>
Sent: Wednesday, January 17, 2001 3:03 PM
Subject: Re: [opml-dev] Re: OPML and UNIX


>
> Dave,
> It may me just me (RU 7.0b34, Windows), but the RU parser does seem to be
> easily confused.
>
> For example, take any OPML file and insert a comment immediately after the
> XML declaration. Or, delete any whitespace between the XML declaration and
> the <opml> tag.  RU then displays the "raw" XML rather than the outline.
>
> -Hugh
> hpyle@...
>
>
>
> To unsubscribe from this group, send an email to:
> opml-dev-unsubscribe@egroups.com
>
>
>

Dave,
It may me just me (RU 7.0b34, Windows), but the RU parser does seem to be
easily confused.

For example, take any OPML file and insert a comment immediately after the
XML declaration. Or, delete any whitespace between the XML declaration and
the <opml> tag.  RU then displays the "raw" XML rather than the outline.

-Hugh
hpyle@...

Our groove-based "mindmap" outliner (http://www.agora.co.uk/groove/) reads
and writes OPML, and it suits our needs pretty well.  We've added some very
arbitrary fields, and RU doesn't complain about them.  I think OPML is a
good bet, and would encourage you to implement it

. o O (if only to wrest some control of the spec away from Dave and the
Userland gang)


-Hugh
hpyle@...

Radio does not do that. It has an XML parser, which produces a structure
that it then walks to build the outline.

I don't know exactly what fix you're looking for.

Dave


----- Original Message -----
From: "Ben " <mywin@...>
To: <opml-dev@egroups.com>
Sent: Wednesday, January 17, 2001 1:30 PM
Subject: [opml-dev] Re: OPML and UNIX


> Anyone have an update on this?
> Has there been a fix for this yet in RU?
> Tnx.
>
> --- In opml-dev@egroups.com, "Joshua Allen" <allenjs@h...> wrote:
> > I think that is correct about the line after the XML declaration.
> > I'm guessing that RU reads the second line of the file (the first
> > line after  the first CRLF) and looks for "<opml...>".  If it sees
> > OPML, it decides it's an OPML file, if not, it stops looking.. In
> > fact, that is probably how I would have implemented it, too, but now
> > that I want to add processing instructions I would probably be
> > figuring out the easiest way to change it :-)  I'm also guessing that
> > this is the behavior because if I add an extra XML processing
> > instruction at the top of the file, even if using PC linebreak
> > format, RU doesn't recognize it as being OPML...
> >
> >
> >
> >
> > --- In opml-dev@egroups.com, "Ben " <mywin@i...> wrote:
> > > I opened it by double clicking on the file from the desktop or by
> > > clicking an HREF to the (text/opml) file. In both instances if the
> > > file was saved for UNIX it would open as a text xml file, but if
> > > saved for PC (or MAC) it would open as expected in Radio.
> > >
>
>
>
> To unsubscribe from this group, send an email to:
> opml-dev-unsubscribe@egroups.com
>
>
>

Anyone have an update on this?
Has there been a fix for this yet in RU?
Tnx.

--- In opml-dev@egroups.com, "Joshua Allen" <allenjs@h...> wrote:
> I think that is correct about the line after the XML declaration.
> I'm guessing that RU reads the second line of the file (the first
> line after  the first CRLF) and looks for "<opml...>".  If it sees
> OPML, it decides it's an OPML file, if not, it stops looking.. In
> fact, that is probably how I would have implemented it, too, but now
> that I want to add processing instructions I would probably be
> figuring out the easiest way to change it :-)  I'm also guessing that
> this is the behavior because if I add an extra XML processing
> instruction at the top of the file, even if using PC linebreak
> format, RU doesn't recognize it as being OPML...
>
>
>
>
> --- In opml-dev@egroups.com, "Ben " <mywin@i...> wrote:
> > I opened it by double clicking on the file from the desktop or by
> > clicking an HREF to the (text/opml) file. In both instances if the
> > file was saved for UNIX it would open as a text xml file, but if
> > saved for PC (or MAC) it would open as expected in Radio.
> >

---------- Forwarded message ----------

> Can we keep the discussion on the mail list?

	 Sure; forwarded. Didn't want to go on about MORE in the ML.

----- Original Message -----

> > OPML is the native file format for Radio UserLand:
> > http://radio.userland.com/
>
> I'll take a look.
>
> > I've been doing outliners since the late 70s, I did ThinkTank, Ready and
> > MORE; and now Radio.
>
> Hey keen; people have been telling me about MORE for awhile.. they
> keep comparing my palm app to it. Mac people revere it ... good job!
>
> > It's a good format for outlines. We haven't found anything it couldn't
do
> > easily.
>
> Oh? Hopefully. Can I extend it arbitrsrily? (I have quite a bit of
> info, and palm specific and application specific data) Would an app
> reading it likely be able to use the format and ignore the specialty
> stuff? (I'm not on top of things as you can see)

OPML is the native file format for Radio UserLand:

http://radio.userland.com/

I've been doing outliners since the late 70s, I did ThinkTank, Ready and
MORE; and now Radio.

It's a good format for outlines. We haven't found anything it couldn't do
easily.

Dave


----- Original Message -----
From: <skeezix@...>
To: <opml-dev@egroups.com>
Sent: Tuesday, January 16, 2001 12:53 PM
Subject: [opml-dev] OPML ready for use? Arbitrary fields?


> I develop one of the premier outliner apps for Palm OS and friends.
> I'm building a conduit between the PDA and desktop now, and need a
> data format to syncronize too. Rather than spin something up, I'd like
> to sync to a common XML format so that I don't necessarily need to
> write my own desktop application, and so the users have their choice
> of app isolated from platform. A win win for all involved. (Assuming
> apps exist, which may not yet be the case)
>
> I would like to know if OPML is actualled used for any outliner apps
> yet, and if folks think it is ready for the primetime.
>
> I looked briefly at the spec a month or two back, and it didn't seem
> like it would easily accept arbitrary other fields yet, so it would
> perhaps be difficult to fit in time constraints and other non-spec
> items. (My outliner can do tasks, general outlines, whatever -- so I
> need to store fields indicating font and face, various times, attached
> note text, hiperlink type relations, etc etc). If OPML is easy
> extended without breaking future or existing apps, I may use it. If no
> apps exist yet, maybe I'll write one.. I just need to know if I should
> get into it or not.
>
> jeff
>
>
> To unsubscribe from this group, send an email to:
> opml-dev-unsubscribe@egroups.com
>
>
>

I develop one of the premier outliner apps for Palm OS and friends.
I'm building a conduit between the PDA and desktop now, and need a
data format to syncronize too. Rather than spin something up, I'd like
to sync to a common XML format so that I don't necessarily need to
write my own desktop application, and so the users have their choice
of app isolated from platform. A win win for all involved. (Assuming
apps exist, which may not yet be the case)

I would like to know if OPML is actualled used for any outliner apps
yet, and if folks think it is ready for the primetime.

I looked briefly at the spec a month or two back, and it didn't seem
like it would easily accept arbitrary other fields yet, so it would
perhaps be difficult to fit in time constraints and other non-spec
items. (My outliner can do tasks, general outlines, whatever -- so I
need to store fields indicating font and face, various times, attached
note text, hiperlink type relations, etc etc). If OPML is easy
extended without breaking future or existing apps, I may use it. If no
apps exist yet, maybe I'll write one.. I just need to know if I should
get into it or not.

jeff

Hi Hugh,

The OPML specification doesn't specify a character set requirement, other
than requiring that the OPML document is a valid XML 1.0 document.

What's meant by the statement you quoted, is that when Radio UserLand is
interacting with a Frontier server, the character set can be assumed to be
ISO-8859-1.

If some other application or scripting system is used to send and receive
OPML data to/from a Manila website, using ISO-8859-1 encoding will ensure
that the server will handle the data correctly.

-Jake

on 1/2/01 8:19 AM, hpyle@... at hpyle@... wrote:

>
> Apologies for the cross-posting; I also put this at
> http://www.opml.org/discuss/msgReader$7?mode=day
>
>
> Jake's posting 2000-12-30 says,
> "Since servers can assume that both incoming and outgoing OPML is
> encoded as ISO-8859-1 text,
> no translation is ever necessary on the server when OPML enters or
> exits the system."
>
> Isn't this too restrictive?  i.e.: do you mean that OPML mandates
> ISO-8859-1 encoding, rather than supporting any XML encoding scheme?
>
> Non-Userland systems might construct OPML which uses UTF-8, UTF-16 or a
> bunch of other well-known encodings, and surely a server (or client) would
> be responsible for translating these inbound encodings appropriately.
>
>
> -Hugh
> hpyle@...

Apologies for the cross-posting; I also put this at
http://www.opml.org/discuss/msgReader$7?mode=day


Jake's posting 2000-12-30 says,
      "Since servers can assume that both incoming and outgoing OPML is
encoded as ISO-8859-1 text,
      no translation is ever necessary on the server when OPML enters or
exits the system."

Isn't this too restrictive?  i.e.: do you mean that OPML mandates
ISO-8859-1 encoding, rather than supporting any XML encoding scheme?

Non-Userland systems might construct OPML which uses UTF-8, UTF-16 or a
bunch of other well-known encodings, and surely a server (or client) would
be responsible for translating these inbound encodings appropriately.


-Hugh
hpyle@...

We've been working on resolving some bugs in Radio UserLand and Manila,
which are related to the way characters in OPML documents are encoded and
decoded on Macintosh vs. Windows.

We've posted a page for review, which details how character
encoding/decoding will work:

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

Your comments are welcome.

Thanks!

-Jake

I think that is correct about the line after the XML declaration.
I'm guessing that RU reads the second line of the file (the first
line after  the first CRLF) and looks for "<opml...>".  If it sees
OPML, it decides it's an OPML file, if not, it stops looking.. In
fact, that is probably how I would have implemented it, too, but now
that I want to add processing instructions I would probably be
figuring out the easiest way to change it :-)  I'm also guessing that
this is the behavior because if I add an extra XML processing
instruction at the top of the file, even if using PC linebreak
format, RU doesn't recognize it as being OPML...




--- In opml-dev@egroups.com, "Ben " <mywin@i...> wrote:
> I opened it by double clicking on the file from the desktop or by
> clicking an HREF to the (text/opml) file. In both instances if the
> file was saved for UNIX it would open as a text xml file, but if
> saved for PC (or MAC) it would open as expected in Radio.
>
> You can try it here: http://www.keeptabs.com/ if you import some of
> your bookmarks there you can export them to OPML.
> (Embarrassing to link to because the site is very lame so far.)
>
> I seem to remember that the only line break that tripped it up was
> the one after the XML declaration (could be wrong).
>
> HTH,
> -Ben
>
>
>
> --- In opml-dev@egroups.com, Brent Simmons <brent@u...> wrote:
> > How did you import the file? Did you open it from the desktop,
use
> > the Open URL... command, or some other way?
> >
> > -Brent
> >
> > At 9:34 PM +0000 12/19/00, Ben  wrote:
> > >I am running into a strange problem. It seems that Userland Radio
> > >will not import an OPML file with UNIX line endings.
> > >
> > >I am exporting OPML bookmarks from www.keeptabs.com that doesn't
> > >import to Userland unless I save the file to PC or MAC new-lines.
> > >
> > >Could this be possible?
> > >
> > >
> > >
> > >
> > >To unsubscribe from this group, send an email to:
> > >opml-dev-unsubscribe@egroups.com

I opened it by double clicking on the file from the desktop or by
clicking an HREF to the (text/opml) file. In both instances if the
file was saved for UNIX it would open as a text xml file, but if
saved for PC (or MAC) it would open as expected in Radio.

You can try it here: http://www.keeptabs.com/ if you import some of
your bookmarks there you can export them to OPML.
(Embarrassing to link to because the site is very lame so far.)

I seem to remember that the only line break that tripped it up was
the one after the XML declaration (could be wrong).

HTH,
-Ben



--- In opml-dev@egroups.com, Brent Simmons <brent@u...> wrote:
> How did you import the file? Did you open it from the desktop, use
> the Open URL... command, or some other way?
>
> -Brent
>
> At 9:34 PM +0000 12/19/00, Ben  wrote:
> >I am running into a strange problem. It seems that Userland Radio
> >will not import an OPML file with UNIX line endings.
> >
> >I am exporting OPML bookmarks from www.keeptabs.com that doesn't
> >import to Userland unless I save the file to PC or MAC new-lines.
> >
> >Could this be possible?
> >
> >
> >
> >
> >To unsubscribe from this group, send an email to:
> >opml-dev-unsubscribe@egroups.com

How did you import the file? Did you open it from the desktop, use
the Open URL... command, or some other way?

-Brent

At 9:34 PM +0000 12/19/00, Ben  wrote:
>I am running into a strange problem. It seems that Userland Radio
>will not import an OPML file with UNIX line endings.
>
>I am exporting OPML bookmarks from www.keeptabs.com that doesn't
>import to Userland unless I save the file to PC or MAC new-lines.
>
>Could this be possible?
>
>
>
>
>To unsubscribe from this group, send an email to:
>opml-dev-unsubscribe@egroups.com

Yes, it could be possible, Radio is a new piece of software still in beta.
We'll get this taken care of asap. Dave


----- Original Message -----
From: "Ben " <mywin@...>
To: <opml-dev@egroups.com>
Sent: Tuesday, December 19, 2000 1:34 PM
Subject: [opml-dev] OPML and UNIX


> I am running into a strange problem. It seems that Userland Radio
> will not import an OPML file with UNIX line endings.
>
> I am exporting OPML bookmarks from www.keeptabs.com that doesn't
> import to Userland unless I save the file to PC or MAC new-lines.
>
> Could this be possible?
>
>
>
>
> To unsubscribe from this group, send an email to:
> opml-dev-unsubscribe@egroups.com
>
>
>

I am running into a strange problem. It seems that Userland Radio
will not import an OPML file with UNIX line endings.

I am exporting OPML bookmarks from www.keeptabs.com that doesn't
import to Userland unless I save the file to PC or MAC new-lines.

Could this be possible?

Well, I found something of a discussion of the issue at
http://radiodiscuss.userland.com/discuss/msgReader$2348.  HOWEVER, I
do not believe this is exactly the same issue.  In fact, I can see
certain benefits in the use of the text="" attribute and I certainly
think that adding "node" element items is wrong.  Allowing free-form
elements and content beneath an <outline/> will open up a whole new
can of worms.  The person complaining that the current scheme
disallows HTML is certainly not hoping to put "standard" HTML in a
sub-element, cause it won't work.  Forcing the content to be of the
sort that fits between double-quotes in valid XML is a great way to
prevent people from getting themselves stuck later, IMO.

So the idea that an <outline/> should be the same regardless of
whether it contains "heading" or "paragraph" content is totally
correct.  Heading vs. paragraph is a completely arbitrary way to look
at an outline and there are many other arbitrary ways that could be
conceived.  This distinction can and should be made by applications
without requiring spec mods that *all* apps would have to follow.
The only possible argument I might agree with is that to *eliminate*
the text="" and specify that that content be stored as entity-encoded
PCDATA as a child.  This keeps the current wisdom of having each
outline element only have one chunk of content (why specify text=""
AND PCDATA unless you're trying to force an arbitrary assumption
about what those mean?) but may perhaps allow easier editing, get
around limitations in size of attributes (are there any?).  But the
more I think about it, the more I emphatically agree that the use of
text="" is clearly a case where attributes are better than elements
in the age-old debate.

So my original question still is, has anyone come up with a
convention for differentiating between items they wanted treated like
normal outline headings vs. "content"?

-J

P.S. If the discussion ever opens up about making the text=""
something that can be semistructured to allow application of CSS,
namespaces stuck to type="" or anything I would love to be involved.
There are probably better/easier ways to solve those problems.  Also
interesting would be a discussion of how to associate attachments
(nothing stops you from base64-encoding an image in <outline
text="" /> you know...  But some samples and conventions for
associating data, attaching data (maybe mime?), etc. would be cool.
Good referenceable samples of how to attach and reference complex
data would probably go a long way to assuage the fears that the
text="" attribute is too cumbersome, and could silence the cries for
a structural change to OPML that wouldn't, IMO, work anyway..


--- In opml-dev@egroups.com, "Joshua Allen" <allenjs@h...> wrote:
> As far as I can tell, the <outline/> element doesn't allow
children,
> and the only text associated is in the text="" attribute.  My first
> intuition was that the text="" attribute would represent a heading,
> and not necessarily a block of content.  In some of the examples,
it
> is clear that you can put entire blocks of content in the text=""
> attribute.
>
> Is it useful to be able to distinguish between one <outline/>
element
> as having just "heading" content and another "paragraph" content?
Or
> is there a better way to represent paragraph content?  I'm thinking
> of cases where you have a full document but only want to look at
> the "heading" level items in the outliner.  I could easily handle
> this by putting an attribute "isTitle" (or something like that)
> without violating the simplicity of OPML; then in my app have a
> toggle like "Show All/Show only Titles".  This just seems like
> something others would want to do, and having a common convention
> makes sense.  So can anyone suggest a common convention for marking
> pieces of an outline as being atypical, hideable or whatever?
>
> Thanks!

As far as I can tell, the <outline/> element doesn't allow children,
and the only text associated is in the text="" attribute.  My first
intuition was that the text="" attribute would represent a heading,
and not necessarily a block of content.  In some of the examples, it
is clear that you can put entire blocks of content in the text=""
attribute.

Is it useful to be able to distinguish between one <outline/> element
as having just "heading" content and another "paragraph" content?  Or
is there a better way to represent paragraph content?  I'm thinking
of cases where you have a full document but only want to look at
the "heading" level items in the outliner.  I could easily handle
this by putting an attribute "isTitle" (or something like that)
without violating the simplicity of OPML; then in my app have a
toggle like "Show All/Show only Titles".  This just seems like
something others would want to do, and having a common convention
makes sense.  So can anyone suggest a common convention for marking
pieces of an outline as being atypical, hideable or whatever?

Thanks!

A few days ago I wrote,

> why not use the "type" attribute to
> define this [isComment] behaviour?  Especially if "type" could be
something truly
> extensible.

I've since re-thought, and there's a handy solution in XML itself:
namespaces.

Using a namespace to disambiguate "our" attributes from "your" and "common"
attributes seems to give plenty of flexibility without needing to construct
some byzantine structure for schemata.  If OPML defines a set of "common"
attributes (type, text, URL, few more) these are free to use in sharing
semantics;  our applications can define distinct names for our own
meaningful attributes.

So, for example,
<opml xmlns:a="urn:agora.co.uk:MindMapRecord">
   <head/>
   <body>
     <outline text="Outlines are great for all kinds of structured
documents"/>
     <outline text="new" type="urn:agora.co.uk:MindMapRecord" a:x="100" a:y
="200" a:color="#FF0A0A"/>
     <outline text="borrowed" type="link" URL
="http://www.agora.co.uk/groove/MMTool.htm" a:x="150" a:y="250"/>
   </body>
</opml>

Does this make sense?


Hugh
hpyle@...

----- Original Message -----
From: "Aaron Straup Cope" <asc@...>
To: <dave@...>
Sent: Sunday, December 10, 2000 9:17 AM
Subject: FYI : opml2ft


> "opml2ft is a Perl script that converts an OPML document into a JavaScript
> file suitable for parsing by Marcelino Martins' FolderTree DHTML outliner
> (v2.0)"
>
> http://aaronland.net/toys/opml2ft/
>

Thanks for the explanation, Lantz; that's clear.

But to me it raises the question: why not use the "type" attribute to
define this behaviour?  Especially if "type" could be something truly
extensible.

For example: our mindmap application has a record structure which includes
fields {x, y, text, body, color}.  We can export that to OPML, read into
RadioUserland.  We set type="urn:agora.co.uk:MindMapRecord" which happens
also to be the schema URI for this record structure in our host
application.

We also have a derived type of mindmap records which are hyperlinks;  they
have an additional field "URL".  When we put that into OPML it makes sense
to set type="link", because then RU will understand it.  But without an
extensible type mechanism we then lose knowledge of the original schema,
which makes round-tripping more problematical.

-Hugh
hpyle@...

To: opml-dev@egroups.com
--- In opml-dev@egroups.com, hpyle@a... asked:
> Are there any examples of "isComment"?
Hugh,

The Human Client documentation for Radio [1] includes a section about
the ability to have comments in your outline.  Please note the
programming presumption that the only human use for comments is within
program code and scripts, so there are only the two kinds of comments:
inlineComment and a CommentOutlineBranch.

An inlineComment ("end of non comment line comment") is simply a
string of two slashes ("//") within the text attribute of any outline
element as far as opml is concerned, it is completely independent of
the isComment attributes.  That pair of slashes in a line of script is
the syntax to assert to their parser that the rest of the line is a
comment.

The Radio OutlineMenuItem: 'Toggle Comment (/)' is the human interface
to the outline isComment attribute for what in Radio is a
"CommentOutlineBranch". The Human presentation for the
isComment="true" attribute is a left chevron "<<" as the bullet glyph
for that outline item.

     "And Then A Miracle Occurs"

Unfortunately Radio does not read or write the isComment attribute in
the manner specified in the opml xml dtd.

In Radio the isComment attribute is only set to true in the outline
element that is functioning as the top node of a CommentOutlineBranch,
the attribute is not set and is totally ignored in all children. Radio
does not either write or read the isComment attribute in any outline
element contained within that special magic outer element.

This human interface in Radio is used by programmers to transform an
_entire outline branch_ of code into a special CommentOutlineBranch.

The Human presentation is the left chevron "<<" bullets for every
child in the CommentOutlineBranch, which is fine, but when Radio
writes opml is does not bother to set the isComment attribute for
those children.

As a sketch of the way Radio reads and writes opml consider this:

   body ( outline* | CommentOutlineBranch* )

   outline ( outline* | CommentOutlineBranch*)
       outline isComment #implied 'false'

   CommentOutlineBranch (CommentOutlineItem*)
       outline isComment = 'true'

   CommentOutlineItem (CommentOutlineItem*)
       outline isComment #fixed 'true'

How you (and Userland) should use the outline isComment attribute is
as implied with a default value of 'false' . Set isComment='true' in
_every_ outline element that is a comment.

Cheers,
   Lantz

XRef
[1] - Radio HI Documentation - How to Use the Outlines
   http://radiodiscuss.userland.com/howToUseTheOutliner#comments

Are there any examples of "isComment"?  How does it work?

-Hugh
hpyle@...

Our groove brainstorm tool (http://www.agora.co.uk/groove/MMTool.htm) now
loads and saves OPML files to disk - at least, the version in development
does, you can't install the code just yet.  It'll roundtrip Radio Userland
playlists reasonably well.

Is there anything else which would be cool?  I'm not a big Userland junkie,
so need some help here.  Should we be able to load or save OPML to a
web/ftp site?  What sorts of integration would make this really useful?

-Hugh
hpyle@...

Yes, the type attribute is key.

We will not use namespaces to avoid collisions.

It's up to applications to document how they use types. If you want to be
compatible, go for it. If you like a different kind of type, define your
own. If you want to be certain you won't collide with others, put your
initials at the beginning of the name of the type. Later this might not be
adequate, but it surely is adequate now.

I want to get docs together for the types that UserLand is using. Lots of
stuff on the todo list.

Dave


----- Original Message -----
From: <hpyle@...>
To: <opml-dev@egroups.com>
Sent: Monday, November 27, 2000 1:06 AM
Subject: [opml-dev] Semantics & schemas?


> The "type" attribute on outline elements is obviously significant.  Will
> the OPML spec define
> - a namespace of types, so different applications can share semantics if
> they want, or avoid overlapping?
> - a schema associated with a type, to define the expected attributes?
>
>
> -Hugh
> hpyle@...
>
>
>
> To unsubscribe from this group, send an email to:
> opml-dev-unsubscribe@egroups.com
>
>
>

Good questions.

1. About XML comments, I haven't thought about this at all. I see OPML as
largely a machine-generated format, so I'd say XML comments do not have to
be preserved.

2. Element content is not allowed between <outline>..</outline>. I'm going
to make sure the spec is clear on this.

3. Yes, all attributes should be preserved, even those your application is
not interested in.

Hope this helps.

Dave


----- Original Message -----
From: <hpyle@...>
To: <opml-dev@egroups.com>
Sent: Monday, November 27, 2000 1:04 AM
Subject: [opml-dev] User-agent conformance criteria


> Hi folks,
>
> Are there any (will there be any) conformance criteria for OPML
> user-agents?  I'm particularly interested in round-tripping OPML between
> different applications, and the sort of constraints you might expect in
> that.
>
> For example:
> - Should XML comments be preserved?
> - Should element content (between <outline>...</outline>) be allowed? If
> so, preserved?
> - Should all attributes be preserved, even those your application is not
> interested in?
>
>
> -Hugh
> hpyle@...
>
>
>
>
> To unsubscribe from this group, send an email to:
> opml-dev-unsubscribe@egroups.com
>
>
>

The "type" attribute on outline elements is obviously significant.  Will
the OPML spec define
- a namespace of types, so different applications can share semantics if
they want, or avoid overlapping?
- a schema associated with a type, to define the expected attributes?


-Hugh
hpyle@...

Hi folks,

Are there any (will there be any) conformance criteria for OPML
user-agents?  I'm particularly interested in round-tripping OPML between
different applications, and the sort of constraints you might expect in
that.

For example:
- Should XML comments be preserved?
- Should element content (between <outline>...</outline>) be allowed? If
so, preserved?
- Should all attributes be preserved, even those your application is not
interested in?


-Hugh
hpyle@...