Learning ActionScript 3.0: A Beginner's Guide
Amazon Price: $26.39
Average Customer Rating: 4.5
First, please note that many of the 5-star reviews are written by experience Flash professionals, who already have experience with actionscript concepts -- and that makes them poor judges of how clea...

Head First HTML with CSS & XHTML
Amazon Price: $26.39
Average Customer Rating: 4.5
This is the first "head first" book I've read, and unfortunately it will probably be my last.

I actually don't have a problem with the material covered in the book. It seems pretty complete. But...

HTML, XHTML, and CSS, Sixth Edition (Visual Quickstart Guide)
Amazon Price: $23.09
Average Customer Rating: 4.5
Ok, I must admit I haven't even cracked this book. I am relying on everyone else's reviews that say that it is easy to follow this book. I am not a computer junkie, although I'm not terrible with b...

Head First C# (Brain-Friendly Guides)
Amazon Price: $31.49
Average Customer Rating: 4.5
Head First C# is exactly what I was looking for in a programming book --- minimal technobabble and light on the concepts. I wanted to see what the language can do and that's what this book delivers. ...

Learning Web Design: A Beginner's Guide to (X)HTML, StyleSheets, and Web Grap...
Amazon Price: $29.69
Average Customer Rating: 4.5
The book is in excellent condition. The shipment was quick.
Thank you very much for it


An issue that always seems to arise when adding an element (whether core or extension) to a feed format is whether the element appearing at the feed level applies to the entries. The reason to want it to apply is obvious–avoiding having to repeat identical data over and over in each entry. But allowing inheritance can create problems. For example, if an entry needs to override the inherited value, that’s easy enough, but what if you simply want to make the value undefined for a particular entry? Generally, no can do.

An idea I proposed while working on Atom 1.0 was to create a mechanism for specifying data in one place in a document and then simply referring to it from other places. The idea was voted down (it is admittedly more work for implementors…though it shouldn’t be THAT much work–and compression does a good job of minimizing the impact of redunant data on he amount of data that has to be transmitted), but over and over again, I see cases where I’d really like to be able to do it.

So now I’m thinking of proposing a general XML extension for reducing redundancy in XML documents. Here’s my current thinking:

  • The extension would define three attributes (I’ll use “xref” as the prefix here): xref:id, xref:ref and xref:here.
  • xref:id would be a document-unique ID for the containing element (and any child elements–they come as a package)
  • It would be recommended that xref:id be a very short value–since it only needs to be unique in the scope of the document, it needn’t be anything fancy.
  • xref:ref would point to the element whose xref:id had the same value (example below).
  • xref:here would only appear on elements with an xref:id. It would have a boolean value indicating whether the element applied the the document at the position where it appeared, or whether it was just there in order to be referred to from elsewhere in the document. The default would be “true” (ie., the element applies where it exists).
  • Elements referred to by xref:ref MUST appear earlier in the document than elements referring to them. It might be good to specify that the element referred to has to be “in scope” (ie. the child of an ancestor or the referring element), but maybe that should just be a best practice.
  • The extension could only be used in conjunction with elements whose specifications explicitly state that they are compatible with this extension. So for example, since the Atom specification doesn’t know about this extension, these attributes could not be used on core Atom elements. (I’d be tempted to mint a namespace for “Atom plus xref” which would make documents looking exactly like Atom documents, but with xref support…and a different namespace for all the elements).
  • The extension would not be recommended for use with digitally signed data unless it is intended that data never be excerpted from it and that it never be combined with data from other documents that might use xref. The reason for this is that combining data could result in duplicate xref:ids in one document, and substituting in the full data to avoid that problem would break the digital signature.
  • (I’m not sure about this one): Items containing xref:ref must be empty and have no other attributes–they can’t override values from the referenced element. Being able to do so would be nice for compactness, but would make processing more difficult. Which is more important?

A quick example:

<foo xmlns=”http://example.com/foo” xmlns:xref=”http://example.com/xref”>

<title>The title of the document</title>
<title xref:id=”1″ xref:here=”0″>No title</title>
<author xref:id=”2″>Antone Roundy</author>

<item>
<title>The title of one item</title>
<author xref:ref=”2″ />
<content>foo</content>
</item>

<item>
<title xref:id=”1″>
<author xref:ref=”2″ />
<content>bar</content>
</item>

</foo>

  • Bookmark This Post: