Re: [uf-discuss] Google Code microformat?

[Samuel Richter]

I will try this again giving a scenario...

Joe Cool, adept coder, releases a project, AlphaBUG, to the web on the
code hosting site, www.attaboy.com.  Every time Joe releases a new
update, he also publishes an RSS/Atom article describing.  The problem
for Joe, who wants to empower AlphaBUG's stakeholders, knows that his
program 1) doesn't exist in a vacuum-it's dependent on other libraries
2) isn't the only program his stakeholders use-they don't want to be
encumbered by having to manually install each update 3) will have
frequent updates as he is prone to releasing updates often.  What Joe
hasn't thought of but, what he *needs* is a microformat that will
markup all of this information in the vehicle of RSS/Atom.

So, when I read Joe's feed about the latest update of AlphaBUG on
www.attaboy.com, by a micromiracle I am looking at not only release
notes but library and version dependencies,  a hyperlink to download
the package and version information of this update (is it major,
minor, bugfix, etc.), etc.  All of this readily extractable from the
RSS/Atom feed because it has been tagged using a microformat.

Then, because this information can be extracted from the feed, I use a
platform installer, which I use to install all packages that have a
microformat-encoded RSS/Atom feed and have it install the update in a
predetermined directory selecting the version that I have specified by
an update policy.

In other words, Joe 's AlphaBUG has been steered onto the paved
highway of automated updates.  Windows has it, why can't there be a
generic installer/auto-updater for open-source.

Whew.

-mephtu

On Sat, Nov 22, 2008 at 1:19 PM, Scott Reynen <[EMAIL PROTECTED]> wrote:
> On [Nov 22], at [ Nov 22] 7:09 , Samuel Richter wrote:
>
>> It seems to me that both hAtom and hDOAP present limitations of a sort
>> when it comes to providing feeds for software updates.  On the one
>> hand with hAtom, you have a generic microformat with no way of
>> identifying any content beyond it merely being feed content and with
>> hDOAP, you have no mechanism for providing update information.  Do you
>> see the gap I'm trying to show?
>
>
> Microformats are made to be modular.  Using both together would seem to
> remove the gap you've described.  But as David said, because this is all
> very abstract, it's hard to tell if this would actually meet your needs.
>
> Peace,
> Scott
>
> ___
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
>
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Google Code microformat?

[Samuel Richter]

Dude, you are giving me a headache.

On Sat, Nov 22, 2008 at 9:55 AM, David Janes <[EMAIL PROTECTED]> wrote:
> On Sat, Nov 22, 2008 at 9:09 AM, Samuel Richter <[EMAIL PROTECTED]> wrote:
>> It seems to me that both hAtom and hDOAP present limitations of a sort
>> when it comes to providing feeds for software updates.  On the one
>> hand with hAtom, you have a generic microformat with no way of
>> identifying any content beyond it merely being feed content and with
>> hDOAP, you have no mechanism for providing update information.  Do you
>> see the gap I'm trying to show?
>
> It's rather difficult to discuss this in the abstract, without a real
> world example to pin it against.
>
> The utility of the markup is often as much defined by _it's use_ and
> _it's user_ as anything: if you know that http://projects.example.com
> lists has project information that's marked up in hAtom, then that's
> very different than if you don't care about projects or that page.
>
> Note that hAtom's purpose is not to provide "feeds" for anything: it's
> a way of semantically marking up certain types of data on pages.
>
> Regards, etc...
>
> --
> David Janes
> Mercenary Programmer
> http://code.davidjanes.com
> ___
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
>
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Google Code microformat?

[Scott Reynen]

On [Nov 22], at [ Nov 22] 7:09 , Samuel Richter wrote:


It seems to me that both hAtom and hDOAP present limitations of a sort
when it comes to providing feeds for software updates.  On the one
hand with hAtom, you have a generic microformat with no way of
identifying any content beyond it merely being feed content and with
hDOAP, you have no mechanism for providing update information.  Do you
see the gap I'm trying to show?



Microformats are made to be modular.  Using both together would seem  
to remove the gap you've described.  But as David said, because this  
is all very abstract, it's hard to tell if this would actually meet  
your needs.


Peace,
Scott

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Google Code microformat?

[David Janes]

On Sat, Nov 22, 2008 at 9:09 AM, Samuel Richter <[EMAIL PROTECTED]> wrote:
> It seems to me that both hAtom and hDOAP present limitations of a sort
> when it comes to providing feeds for software updates.  On the one
> hand with hAtom, you have a generic microformat with no way of
> identifying any content beyond it merely being feed content and with
> hDOAP, you have no mechanism for providing update information.  Do you
> see the gap I'm trying to show?

It's rather difficult to discuss this in the abstract, without a real
world example to pin it against.

The utility of the markup is often as much defined by _it's use_ and
_it's user_ as anything: if you know that http://projects.example.com
lists has project information that's marked up in hAtom, then that's
very different than if you don't care about projects or that page.

Note that hAtom's purpose is not to provide "feeds" for anything: it's
a way of semantically marking up certain types of data on pages.

Regards, etc...

-- 
David Janes
Mercenary Programmer
http://code.davidjanes.com
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Google Code microformat?

[Samuel Richter]

It seems to me that both hAtom and hDOAP present limitations of a sort
when it comes to providing feeds for software updates.  On the one
hand with hAtom, you have a generic microformat with no way of
identifying any content beyond it merely being feed content and with
hDOAP, you have no mechanism for providing update information.  Do you
see the gap I'm trying to show?

-Sam

On Sat, Nov 22, 2008 at 4:59 AM, Toby A Inkster <[EMAIL PROTECTED]> wrote:
> If you're talking about their use of class="ot-logmessage" etc, then no,
> that isn't a Microformat[1].
>
> It looks to me like the reason those particular classes are present in the
> project updates Atom feed is that the feed is generated by the same code
> that generates the project updates HTML file, where these classes seems to
> be mainly present as hooks for CSS and Javascript.
>
> If you're looking for a way to markup feeds, then use hAtom[2]. If you're
> looking for a way to markup software projects, then perhaps you should look
> at hDOAP[3].
>
> 
> 1. http://microformats.org/wiki/Category:Specifications
>   http://microformats.org/wiki/Category:Draft_Specifications
> 2. http://microformats.org/wiki/hAtom
> 3. http://purl.org/stuff/hdoap/profile
>
> --
> Toby A Inkster
> 
> 
>
>
>
> ___
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
>
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss