Subject: PaceMinimalVersioning

From: Tim Bray <[email-masked]>
Date: Thu, 16 Sep 2004 00:46:05 -0700

I tend to agree with most of PaceExtensibilityAndVersioning, but I 
found it unnecessarily long and complex and did not find its 
exploration of extension mechanisms convincing.  So I decided to try to 
create the Minimum Versioning Framework That Could Possibly Work, if 
only as a strawman.  -Tim

handy pointer: 
http://www.intertwingly.net/wiki/pie/PaceMinimalVersioning

---

From: Eric Scheid <[email-masked]>
Date: Thu, 16 Sep 2004 18:20:25 +1000

> create the Minimum Versioning Framework That Could Possibly Work, if

Is there any way to indicate in the feed that that particular feed will be
using elements with mU, even if a particular instance of the feed does not
contain mU?

I have another strawman I might write up as a pace ... very simply, the feed
has an @version attribute, and an @compatible attribute. The @version would
contain whatever version number the feed really is, while the @compatible
would contain the version number which this particular feed is backwardly
compatible to.

Thus, an Atom processor that only understands Atom 1.0 can happily consume
future versions, up until the point where it is told it cannot (eg. a
version change which restructures things drastically, or introduces elements
with a mU nature).

Further, if a 2.0 feed specification contains elements with mU nature, but
this particular publication of this feed does not contain any instances
(only works with optional elements, of course), then that feed would still
be backwardly compatible with 1.0.

If however the publisher is intending to use some optional mU elements, then
they can set @compatible to 2.0, and a 1.0 processor would know to back
away, even if a particular instance of the feed doesn't have any mU elements
(thus avoiding heisenbugs).

This would work if the mU things were attributes, not just elements, and
would also work with known elements which are ascribed some new/additional
semantics/meanings. Example: an Atom 2.0 processor might think it knows how
to handle <atom:author mustUnderstand="true"> because the 2.0 spec
introduced some mU aspect ... but the 3.0 spec introduced even more mU
aspects which of course the 2.0 processor wouldn't know how to handle. I
think is a failing with the binary mU mechanism, since it limits what
changes we can do to the spec in the future.

e.

---

From: Dare Obasanjo <[email-masked]>
Date: Thu, 16 Sep 2004 05:59:49 -0700 (PDT)

Four points 

1.) The Pace doesn't state how one determines if it is
a backwards incompatible version of Atom. For example,
if the semantics of <link> changes in a future spec.
The other Paces explicitly state that such changes
will involve reving the namespace name. 

2.) Your Pace implies that if a required element is
ever added in a future version of Atom it will have to
appear with atom:must-understand="true". Is this
intentional? 

3.) Unrecognized attributes are always ignored. So
this means any attributes added to core elements must
be optional. Is this also intentional?

If you want to create a true PaceMinimalVersioning I'd
eschew all the MustUnderstand crud and just state 

(i) Unknown elements and attributes can always be
ignored
(ii) Version number is split into major/minor version.
Atom is backwards compatible between minor versions.
So Atom 1.0 & Atom 1.1 are compatible but Atom 1.0 &
Atom 2.0 are not. 

=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #23
I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks.

__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail

---

From: Tim Bray <[email-masked]>
Date: Thu, 16 Sep 2004 09:31:51 -0700

> will involve reving the namespace name.

Right.  In the proposed scheme, you can't change the semantics of an 
element in place without changing its name.  Putting it in a different 
namespace would accomplish that.

> appear with atom:must-understand="true". Is this

Yes.  This seems fail-safe and furthermore has the desirable effect of 
discouraging the addition of required future elements.

> be optional. Is this also intentional?

Right.  I don't see any way around it.

> So Atom 1.0 & Atom 1.1 are compatible but Atom 1.0 &

I find the term "backwards compatible" horribly underspecified.  I want 
a deterministic, simple set of rules that specify what software can and 
can't be relied upon to do in the face of unrecognized and erroneous 
markup.  I claim that PaceMinimalVersioning provides that.  If you can 
translate the term "backwards compatible" into a set of RFC2119-style 
constraints we could compare them easily with PaceMinimalVersioning. 
-Tim

---

From: Graham Parks <[email-masked]>
Date: Sat, 18 Sep 2004 09:10:31 -0700

On Thursday, September 16, 2004, at 06:09AM, Dare Obasanjo <[email-masked]> wrote:

>eschew all the MustUnderstand crud

Agreed. UUse case for MustUnderstand?

Graham

---

From: Danny Ayers <[email-masked]>
Date: Sat, 18 Sep 2004 20:47:13 +0200

PaceExtensibilityAndVersioning    +0.5
PaceAltExtensibilityAndVersioning -1
PaceMinimalVersioning    +0.5

The reason for hesistation on the first is that I'm not entirely sure
how much it adds. I think it may be useful in terms of versioning, and
certain other cases where strict interpretation is essential - this
seems to be reflected to some extent in PaceMinimalVersioning. But for
extensibility the whole mU etc approach seems terribly limited. I
would prefer to see something that constrained extensions in such a
way as to enable shared interpretation of Atom Constructs. There's a
clear precedent with RSS 1.0, and though I personally think Atom
should take advantage of the RDF model, mapped to the current syntax +
constraining extensions, there are alternates. For example, just to
say that a child extension element defines in some way a relationship
to its immediate parent would help encourage compatibility between
extensions.

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Dare Obasanjo <[email-masked]>
Date: Sun, 19 Sep 2004 18:36:51 -0700 (PDT)

> Agreed. UUse case for MustUnderstand?

For syndication the scenarios I can come up with seem
pretty contrived. On the other hand, I can imagine
extensions of the ATOM API that would require that an
Atom server know how to process certain messages from
the client or else fail. 

I don't see it as much of a deal breaker if the
mustUnderstand stuff doesn't make it into Atom. 

=====

__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail

---

From: Robert Sayre <[email-masked]>
Date: Sun, 19 Sep 2004 21:52:52 -0400

> Atom server know how to process certain messages from

Can you give some examples of each (even if the syndication scenarios 
are sucky)? I don't see the distinction.

Robert Sayre

---

From: Dare Obasanjo <[email-masked]>
Date: Sun, 19 Sep 2004 19:01:40 -0700 (PDT)

> are sucky)? I don't see the distinction.

1.) Syndication Scenario: I have an Atom feed of my
recent transactions from my bank. Certain transacttion
specific information is placed in extension elements.
My bank would like to ensure that I don't use an RSS
reader which drops this information on the floor so it
uses mustUnderstand. 

2.) Atom API Scenario: I am posting a comment to an
Atom enabled blog and using a client which has the
ability to send an extension element that indicates
whether the users personal info (email & URL) should
be made visible in the post or not. As a user I may
want the client to fail if it cannot understand the
command. A similar problem exists for clients that can
post private/restricted blog posts which may only be
understood by some blogging software (e.g.
LiveJournal). 

=====

		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail

---

From: Antone Roundy <[email-masked]>
Date: Mon, 20 Sep 2004 09:12:50 -0600

> understood by some blogging software (e.g.
I think this has been suggested before, but as consensus appears to be 
moving away from @atom:mustUnderstand, I'll bring it up again.  We 
could have a feed-level statement about what extensions or extension 
elements/attributes must be supported rather than sprinkling 
@atom:mustUnderstand all throughout the feed.  For example:

<feed xmlns="atom's namespace name"
	xmlns:foo="foo's namespace name"
	xmlns:bar="bar's namespace name"
	xmlns:rebar="rebar's namespace name" >

followed by this to indicated that foo and rebar are required, but bar 
isn't:

<required-extension name="foo's namespace name" />
<required-extension name="rebar's namespace name" />

or this (trivially smaller, but probably not enough smaller to prefer 
it over the above):

<required-extensions prefixes="foo rebar" />

or, getting more fine grained (none of the element names are serious 
proposals of course):

<required-extension-things things="foo:myelement rebar:myattr" />

or:

<required-extension-thing thing="foo's namespace name:myelement" />
<required-extension-thing thing="rebar's namespace name:myattr" />

Rather than getting into listing every element and attribute that is 
required, perhaps it would be better for the spec to say that if a 
namespace is required, then a processing application MUST understand 
every element and attribute from that namespace that it encounters in 
the feed (rather than that the application MUST understand every 
element and attribute defined in the namespace, even if it doesn't 
appear in the feed, which doesn't add value and is impossible to be 
sure of, since something new could get added to the namespace at any 
time) or it must fail.

On the other hand, listing all required elements and attributes might 
occasionally have the virtue of saving time on attempting to process 
feeds that use extensions which an application only partially 
understands.  I don't expect that the added messyness would be worth 
the savings though.

---

From: Dare Obasanjo <[email-masked]>
Date: Mon, 20 Sep 2004 08:54:19 -0700 (PDT)

> @atom:mustUnderstand all throughout the feed.  For

I'd rather not turn this into a bike shed discussion.
The question is whether Atom should have a
mustUnderstand construct not what syntax should be
used to express it. Syntax is trivial and can always
be debated to death. 

=====

_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com

---

From: Antone Roundy <[email-masked]>
Date: Mon, 20 Sep 2004 10:41:36 -0600

> used to express it. Syntax is trivial and can always
Given that people's support or opposition to proposals in the past have 
turned on details as small as the names of elements[1], I think it's 
reasonable to assume that there might be people whose opinions on 
whether or not to have a mustUnderstand construct would turn on the 
difference between littering the entire feed with mustUnderstand 
attributes vs. stating it once at the top of the feed and being done 
with it.  As has been stated here from time to time, it's a 
cost-benefit question, we may not get the right answer if we haven't 
considered the lowest cost methods of getting the benefit.

That said, I agree that we should decide whether we want it first and 
hammer out the exact details of syntax later.  My intent was to say "if 
it was done something like this, instead of with an attribute on every 
required element, would it be worth it?"  Perhaps I rambled a little 
beyond that question, but only in the interest of not leaving out an 
idea that might have influenced someone's decision.

For those who've opposed @mustUnderstand, another question comes even 
before the one above: "Do you not want any such thing, no matter now 
'low-cost'?"  You've suggested a few scenarios where some sort of 
mustUnderstand mechanism would be useful.  That suggests to me that if 
the solution can be low-cost enough, it would be worth doing.

[1] http://www.imc.org/atom-syntax/mail-archive/msg09918.html

---

From: Robert Sayre <[email-masked]>
Date: Mon, 20 Sep 2004 12:54:41 -0400

> understood by some blogging software (e.g.

The syndication scenario is what I figured mustUnderstand would be used
for, both in readers and editing clients. Both protocol scenarios you
suggest are access control problems, right? I don't know if mU is the 
right answer for those.

I agree that the scenarios seem contrived right now, but what worries me 
about dropping mU is that we can't add it later. Inclusion would seem to 
be the choice that keeps our options open.

Robert Sayre

---

From: Tim Bray <[email-masked]>
Date: Mon, 20 Sep 2004 09:59:19 -0700

On Sep 20, 2004, at 9:54 AM, Robert Sayre wrote:

> I agree that the scenarios seem contrived right now, but what worries 
> me about dropping mU is that we can't add it later. Inclusion would 
> seem to be the choice that keeps our options open.

Actually, I didn't think the scenarios were contrived at all, I thought 
they were perfectly plausible.  As is your conclusion. -Tim

---

From: Danny Ayers <[email-masked]>
Date: Mon, 20 Sep 2004 23:24:27 +0200

> they were perfectly plausible.  As is your conclusion. -Tim

+1.

The mU approach is limited in it's applicability, but does seem a good
solution where strict (well, binary) levels of conformance are needed.

Dare rightly said, "Syntax is trivial and can always be debated to
death.", but because 1. so far we have no notion of anything else
(like a model) that extends beyond core elements, and 2. this is the
atom-syntax list, I don't feel too bad saying I like the general
approach suggested by Antone.

However there is at least one aspect a level beyond the bike shed in
Antone's suggestion - mU as @s can be applied in a more fine-grained
(per term) fashion than Antone's per-namespace approach (at the cost
of uglier syntax). So where's the best trade-off?  (Personally I think
that question should be deferred until richer extension mechanisms
have been properly discussed).

Bits o'er t'wire,
Danny.

-- 

http://dannyayers.com

---

From: Graham <[email-masked]>
Date: Mon, 20 Sep 2004 17:27:27 -0400

> <required-extension name="rebar's namespace name" />

I'm still not convinced mustUnderstand et al is useful or will be 
implemented on either end (ie if publishers will bother or readers will 
enforce it), but this syntax here is far preferable and less expensive 
than checking every element for attributes.

Graham

---

From: Robert Sayre <[email-masked]>
Date: Mon, 20 Sep 2004 19:04:51 -0400

> than checking every element for attributes.

Yep. I like it too. I would prefer

<feed mustUnderstandEverything="true" ...>

An unknown element, validity error, etc., would result in a Fatal Atom 
Error--aka "turfed." I don't think any somewhat socially intelligent 
person expects a malformed date to prevent the viewing of cat pictures, 
but what if the data is Important?

Fine-grained mU capabilities make me worry (I get so worried ;)) about 
forking. Imagine <blink mustUnderstand="true">this</blink>.

If your data is really important, your dates have to be correctly 
formatted, you have to have a valid id, etc.

This takes care of Bankers With Important Data, encourages perfectly 
compliant Atom generators to be developed, and prevents an extension 
arms race from starting before everyone has excellent Atom software.

If it turns out that mixing required/optional extensions is important, 
we can fix that later with a new value for the attribute. Thoughts?

Robert Sayre

---

From: Tim Bray <[email-masked]>
Date: Mon, 20 Sep 2004 16:14:18 -0700

Here's an argument against mustUnderstand: it is *highly* 
failure-prone.  Remember the ViewSourceClan, aka morons (see 
http://diveintomark.org/archives/2004/08/16/specs)?  The way the Atom 
design is proceeding, it's going to be *highly* moron-friendly; I 
suspect most people who looked at a few Atom feeds could implement by 
guess and by god and by feedvalidator and everything would just work.  
Furthermore, I bet that at least one substantial large-scale 
atom-reading spider gets built that way (just speaking from looking 
back at my own moronic behavior).  Then you start shipping bank-account 
balances around, feeling safe because they're protected with 
mustUnderstand.  Then Bad Things Happen.  -Tim

---

From: Sam Ruby <[email-masked]>
Date: Mon, 20 Sep 2004 19:24:20 -0400

Robert Sayre wrote:
>> implemented on either end (ie if publishers will bother or readers 
>> will enforce it), but this syntax here is far preferable and less 
>> expensive than checking every element for attributes.
> 

I like Antone's core idea (cluster the information in one place, 
independent of granularity), but i do NOT like the idea of making the 
granularity be the whole feed.

Example: the "LiveBookmarks" support in Firefox cares about exactly two 
concepts (title and link) and looks for it in various places (e.g., 
@href, guid).  I can see specing it so that firefox rejects anything 
which contains a <requires> element in it, but I DON'T see specing it so 
that FireFox must verify each of the possible dates, and if an author is 
present, which are the allowed child elements of author....

- Sam Ruby

---

From: Tim Bray <[email-masked]>
Date: Mon, 20 Sep 2004 16:53:10 -0700

On Sep 20, 2004, at 4:24 PM, Sam Ruby wrote:

> Example: the "LiveBookmarks" support in Firefox cares about exactly 
> two concepts (title and link) and looks for it in various places 
> (e.g., @href, guid).  I can see specing it so that firefox rejects 
> anything which contains a <requires> element in it, but I DON'T see 
> specing it so that FireFox must verify each of the possible dates, and 
> if an author is present, which are the allowed child elements of 
> author....

I don't think that quite necessarily follows.  Rob conflated detection 
of errors and unrecognized markup, which isn't necessary.  The global 
mustUnderstandEverything could be changed to 
failOnUnrecognizedMarkup="true|false"  -Tim

---

From: Martin Duerst <[email-masked]>
Date: Tue, 21 Sep 2004 09:00:18 +0900

I think having some mustunderstand stuff applying to the whole
feed may be helpful. But I'm not sure how that's supposed to
work across feed aggregators. Assuming that it's a feed level
element that must be understood, it would work. But assume
there is something in an entry or two that must be understood:

- It would be a bad idea to throw out the whole feed if all
   the other entries are okay.
- It would be unclear how to propagate the mustUndertstand:
   are all feeds that contain any entry from the original feed
   affected? Or just those feeds that contain entries that the
   aggregator deduces are affected by the 'required-extension'
   or so?
- It is rather easy for feed-level info applying to entries
   to get lost (this depends on whether we will have a general
   mechanism for info that applies to all entries from a feed
   level).

Regards,    Martin.

At 19:04 04/09/20 -0400, Robert Sayre wrote:

>compliant Atom generators to be developed, and prevents an extension arms 
>race from starting before everyone has excellent Atom software.
>
>If it turns out that mixing required/optional extensions is important, we 
>can fix that later with a new value for the attribute. Thoughts?
>
>Robert Sayre

---

From: Antone Roundy <[email-masked]>
Date: Mon, 20 Sep 2004 18:37:49 -0600

>   the other entries are okay.
Agreed.

>   aggregator deduces are affected by the 'required-extension'
If the original feed says "if you see anything in the xyz namespace 
that you don't understand, you must reject the entry (or feed, if it 
appears at the feed level)", then carrying that requirement into an 
aggregated feed along with entries that DON'T contain anything from xyz 
would have no effect...unless other entries in the aggregated feed DO 
contain things from xyz (but from feeds that didn't require it).  Which 
leads to either: a) it's best to drop the requirement since it never 
helps to keep it (but there would be a risk of it hurting--ie. causing 
rejection of entries which the publisher didn't want rejected by 
clients that don't understand xyz) or b) your next comment

>   mechanism for info that applies to all entries from a feed
Have we decided whether aggregate feeds can include atom:head inside 
entries?  That might be preferable to allowing mustUnderstand stuff in 
entries outside of atom:head.

---

From: Sam Ruby <[email-masked]>
Date: Mon, 20 Sep 2004 20:51:17 -0400

> failOnUnrecognizedMarkup="true|false"  -Tim

OK, let me rephrase my statement in the form of a question.

I know of an application which only looks for two elements: title and 
link.  What additional work would be required to support 
failOnUnrecongizedMarkup="true"?

- Sam Ruby

---

From: Ian Davis <[email-masked]>
Date: Tue, 21 Sep 2004 11:47:03 +0100

> guess and by god and by feedvalidator and everything would just work.  

Perhaps we could avoid this if we mandate that mustUnderstand properties 
cannot be included in the standard atom:feed and atom:entry elements but 
must derive new subtypes.

For example, a banking feed might include one entry that includes 
transaction information. The extension spec defines a new 
bank:transaction-entry which is a subtype of atom:entry. The feed then 
looks like this:

<atom:feed>
   <atom:entry>
     <atom:title>normal entry</atom:title>
   </atom:entry>
   <bank:transaction-entry>
     <atom:title>transaction</atom:title>
     <bank:deposit>200</bank:deposit>
   </bank:transaction-entry>
</atom:feed>

The result is that special effort is required by the feed consumer to 
parse the entries with mustUnderstand properties without affecting the 
98% of consumers who rely on feed/entry structure.

Ian

---

From: Brett Lindsley <[email-masked]>
Date: Tue, 21 Sep 2004 06:14:53 -0500

There is a trivial typo in the Publishing Protocol Spec.
Sec 3.3.1 Locating.
The "<link..." example should have a "/" before the closing ">".
Brett Lindsley, Motorola Labs

---

From: Danny Ayers <[email-masked]>
Date: Tue, 21 Sep 2004 13:40:18 +0200

> granularity be the whole feed.

Hmm, yep, this is many-to-many, which confuses matters a bit:

per term (bank:money)
per namespace (xmlns:bank="http://fatsods.org")

per feed (<feed> <mU>http://fatsods.org</mU>)
per entry
per term instance

---

From: Sam Ruby <[email-masked]>
Date: Tue, 21 Sep 2004 09:01:49 -0400

> 98% of consumers who rely on feed/entry structure.

If someone were to want to require more than one thing, things get 
messy, but with a slight adaptation, this can be addressed.  (Note: 
below is intentionally not expressed as well formed XML - I don't want 
to get mired in syntax discussions, I just want to explain an approach):

  <atom:feed>
    <atom:entry>
    <requires bank:deposit>
    </requires>
  </atom:feed>

With such an approach, individual entries could be so marked, or entire 
ranges of entries can be flagged.

Best of all, such an approach indicates that it *IS* possible to add a 
mustUnderstand semantic in a future release.

Finally, it is somewhat amusing to me to point out that the 
feedvalidator itself is a use case for ignoring mustUnderstand.

- Sam Ruby

---

From: Ian Davis <[email-masked]>
Date: Tue, 21 Sep 2004 14:17:35 +0100

> ranges of entries can be flagged.

Although with this approach, simplistic feed consumers using XPaths like 
//atom:entry/atom:title will still pick up the special entries which is 
what I was trying to avoid.

Ian

---

From: Norman Walsh <[email-masked]>
Date: Tue, 21 Sep 2004 12:22:38 -0400

/ Tim Bray <[email-masked]> was heard to say:
| Here's an argument against mustUnderstand: it is *highly*

Invoking the adjective "moron" seems somewhat inflamatory to me, but
I've been heads-down on something else for a week and haven't really
caught up on this thread yet. Perhaps it's warranted.

| failure-prone.  Remember the ViewSourceClan, aka morons (see
| http://diveintomark.org/archives/2004/08/16/specs)?  The way the Atom
| design is proceeding, it's going to be *highly* moron-friendly; I

I try not to use software written by morons. On those occasions when I
discover that I am a moron, I try to fix my code. The argument that
feature X shouldn't be included because morons are likely to get it
wrong is not inherently persuasive to me.

| suspect most people who looked at a few Atom feeds could implement by
| guess and by god and by feedvalidator and everything would just work.
| Furthermore, I bet that at least one substantial large-scale
| atom-reading spider gets built that way (just speaking from looking
| back at my own moronic behavior).  Then you start shipping
| bank-account balances around, feeling safe because they're protected
| with mustUnderstand.  Then Bad Things Happen.  -Tim

Broken software causes bad things to happen: sometimes rockets blow up
and I bet people have died. I suppose the tradeoff is between allowing
a new class of applications to arise (those that include elements
who's semantics a reader must understand in order to have any hope of
doing the right thing) and reducing the number of ways in which a
reader can be written incorrectly.

At the moment, the implementation cost (in the spec and in software)
of "must include" seems fairly small to me. But I suppose I could be a
moron.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <[email-masked]> | [They] say the Earth is flat, but I
http://nwalsh.com/            | know that it is round, for I have seen
                              | the shadow on the moon, and I have more
                              | faith in a shadow than in
                              | [them].--Ferdinand Magellan

---

From: Robert Sayre <[email-masked]>
Date: Tue, 21 Sep 2004 13:38:38 -0400

>      </bank:transaction-entry>
...
> mustUnderstand semantic in a future release.

...but only if we add a mustIgnore rule now, right?

Robert Sayre

---

From: Sam Ruby <[email-masked]>
Date: Wed, 22 Sep 2004 04:35:07 -0400

> ...but only if we add a mustIgnore rule now, right?

Yes.

- Sam Ruby

---

From: Sam Ruby <[email-masked]>
Date: Wed, 22 Sep 2004 04:45:35 -0400

Ian Davis wrote:
>> With such an approach, individual entries could be so marked, or 
>> entire ranges of entries can be flagged.
> 

 From that point of view, //atom:title remains problematic either way.

It ultimately comes down to a judgment call.  One one hand, it is 
impossible to make anything 100% moron proof.  On the other hand, I 
don't see that as an excuse to not even try to prevent honest 
misunderstandings.

One thing I would like to see in a syntax is something that makes the 
semantics (in this case mustUnderstand) explicit and in a declarative 
fashion.  That way, when there is a problem, people are more likely to 
start looking in the right direction.

- Sam Ruby

---

From: Ian Davis <[email-masked]>
Date: Wed, 22 Sep 2004 10:40:49 +0100

On 22/09/2004 09:45, Sam Ruby wrote:
> Ian Davis wrote:
>> Although with this approach, simplistic feed consumers using XPaths 
>> like //atom:entry/atom:title will still pick up the special entries 
>> which is what I was trying to avoid.
> 
> 
I don't understand this statement. If the entry element is called 
bank:transaction-entry as I suggested then the feed consumer has to 
write a special XPath to match the must understand entries.

> start looking in the right direction.
+1

Ian

---

From: Sam Ruby <[email-masked]>
Date: Wed, 22 Sep 2004 06:40:21 -0400

> write a special XPath to match the must understand entries.

<xsl:for-each select="//atom:title">
   <xsl:variable name="title" select="."/>
   <xsl:for-each select="../atom:link[@rel='alternate']">
     <a href="{@href}"><xsl:value-of select="$title"/></a>
   </xsl:for-each>
</xsl:for-each>

If all I am trying to do is to extract titles and their associated 
alternate links (which is essentially all the Mozilla LiveBookmarks 
feature needs), then entire bank:transaction-entry wrapper becomes 
transparent.

- Sam Ruby

---

From: Ian Davis <[email-masked]>
Date: Wed, 22 Sep 2004 11:41:22 +0100

> feature needs), then entire bank:transaction-entry wrapper becomes 
Apologies, you're correct of course. I misread atom:title for atom:entry.

Ian

---

From: Robert Sayre <[email-masked]>
Date: Thu, 23 Sep 2004 20:22:47 -0400

> Brett Lindsley, Motorola Labs

Thanks Brett. Errors in the examples can be tough for us to spot, since 
we think we know what they say. I've corrected the examples for the next 
draft.

Robert Sayre