LLUP XML format

[Uche Ogbuji]

I was reviewing

http://www.x2x2x.org/projects/wiki/doku.php?id=llup:spectemplate

With a mind to the keyword construct. Atom's category element may not
be exactly as I'd have designed it, but I still think we should follow
its precedent.

From RFC 4287:

4.2.2. The "atom:category" Element

The "atom:category" element conveys information about a category
associated with an entry or feed. This specification assigns no
meaning to the content (if any) of this element.

atomCategory =
element atom:category {
atomCommonAttributes,
attribute term { text },
attribute scheme { atomUri }?,
attribute label { text }?,
undefinedContent
}

This gives us all the hooks we need for folksonomy. Mark has discussed
further infrastructure for building on folksonomies intelligently, and
I'm definitely interested in that, but I just want to be sure the
underlying content supports this, and with a URI "scheme" hook, I think
we're set.

It can be a tad verbose, if one uses all the options, but worth it, I think.

I'll try to find the time to review the rest of the XML today. Some
samples placed directly in a Wiki page might help (and would be useful
to a later implementor who wants a quick flavor without reading the full
spec).

--
Uche Ogbuji http://uche.ogbuji.net
Linked-in profile: http://www.linkedin.com/in/ucheogbuji
Articles: http://uche.ogbuji.net/tech/publications/

[M. David Peterson]

Thanks for this, Uche!  I think I can speak for each of us when I state we're quite excited to see how you want to push this portion of the spec forward.

On 4/18/07, Uche Ogbuji <uc...@ogbuji.net> wrote:

I'll try to find the time to review the rest of the XML today.  Some
samples placed directly in a Wiki page might help (and would be useful
to a later implementor who wants a quick flavor without reading the full
spec).

On my TODO list for today.  Will update accordingly.

--
/M:D

M. David Peterson
http://mdavid.name | http://www.oreillynet.com/pub/au/2354 | http://dev.aol.com/blog/3155

[Don Demsak]

My thought from the beginning was to use the URI "scheme" hook as a RESTful webservice endpoint that would return XML of the PRISM Controlled Vocab spec.

Don

---

From: "M. David Peterson" <xmlh...@gmail.com>
Sent: Wednesday, April 18, 2007 1:06 PM
To: ll...@googlegroups.com
Subject: [llup] Re: LLUP XML format

[M. David Peterson]

Don Demsak is in the house! :D

How are things?

So yeah, you did place this smack dab center in the original focus of the spec.  I'm glad to see you take interest in this again... You are obviously tuned into the channel, so with this in mind: Let's kick some a$$ :D

[Russell Miles]

Thanks Uche!

I've created a page on the wiki that should provide just the sort of
collaborative editing work to support the development of the guidelines for
implementing blips here: http://dev.llup.org/wiki/reference/example/blips

I'm just in the process of putting the existing standard, with some changes
to refer to the Atom categories instead of keywords, up on the wiki now.

/Russ

[Russell Miles]

Nice one Don!

Is there any chance you could blurb a bit of a summary on how Prism will
inform the uri scheme for the spec, or is it enough to provide a simple
reference in the docs for now?

/Russ

On 4/18/07, Don Demsak <d...@donxml.com> wrote:

[M. David Peterson]

On 4/18/07, Uche Ogbuji <uc...@ogbuji.net> wrote:

Some samples placed directly in a Wiki page might help (and would be useful
to a later implementor who wants a quick flavor without reading the full
spec).

I've added a sample of one of the blip messages we are using as part of the Amplee/Amazon SQS/Xameleon combined solution that uses the high capacity message queue capabilities of SQS as a buffer between the creation/editing/deletion of content and the indexing and output of this same content into the various supported formats in the proper URI-based location on the system.

http://dev.llup.org/wiki/reference/example/blips#AtomandAPPIntegration

This makes heavy reuse of the Atom namespace/elements, something I believe we need to place significant focus and attention on to ensure that projects with existing Atom Syndication Format capabilities can reuse as much of their existing code base as possible while at the same time reducing the amount of time it takes to process a blip message into and Atom feed ( e.g. subscribing to the blip fed feed of a particular topic of interest) by reducing the amount of conversion necessary to go from blip format to Atom feed format.  This may not be a big deal if you're not processing a whole lot of messages, but when you begin to reach into the 100s of 1000s and upwards into the millions and even billions of messages**, it becomes pretty significant pretty quickly.

Also, from a recent conversation with Sylvain, I have a few things to add to this that I think present and interesting point of focus to ensure even greater levels of efficiency as well as accuracy in regards to auto-expiration of a blip message without any additional processing or user intervention required to ensure the message is no longer accessible past its expiration date.

Will create a separate use-case wiki entry to cover this topic in detail and update this thread accordingly.

** not an unlikely number when you consider how many billions of email messages are sent/received each day, and when you add the amount of text'ing that goes on and consider the fact that blip messaging and text'ing could very easily become synonymous at some point in the not too distant future, finding ways to ensure as easy of a 1-to-1 conversion ( e.g. converting from JSON to Atom without first having to map the JSON name to the associated Atom name)