publishing DLF-ILS-DI records using AtomPub
Godmar Back
Jangle and ILS-DI will be successful only if there's agreement on the
bindings used by compliant implementations.
Ross and I have been brainstorming about the AtomPub binding. For
those ILS-DI functions that return records, each DLF record would be
returned in its own atom:entry element. There are (at least) two ways
to include foreign XML in an Atom document.
a) As a child of atom:entry. That's done by GData, see, for instance
[1]. In this way, many different foreign elements can be included. For
instance, the YouTube API returns GIS, Yahoo Media information,
YouTube statistics, and others.
b) As the child of the atom:content child of atom:entry. If the type
of an atom:content child is a mime type, its child is assumed to be
the root of an XML document that can be interpreted according to the
mime type.
Option a) would allow for coexistence with other information returned;
it would also open up content for a descriptive message that could be
displayed by feed readers. Clients would have to identify the DLF
records by looking for dlf:record with the correct dlf XML namespace.
Option b) would not require that a client perform namespace checking,
but it would "eat up" the atom:content slot.
Which option do you think is best? Are there other factors/customs we
haven't considered?
[ I understand that some feel that this is outside the scope of
ILS-DI, and that ILS-DI's first step is simply to say what
functionality should be provided. In my view, it really isn't too
early to hash out such details - now is the time to create ideas and
embody them in implementations. ]
- Godmar
[1] http://gdata.youtube.com/feeds/api/videos?vq=cats&racy=include&orderby=viewCount
[2] http://atompub.org/rfc4287.html#element.content
Richard Wallis
Technology Evangelist, Talis
Tel: +44 (0)870 400 5422 (Direct)
Tel: +44 (0)870 400 5000 (Switchboard)
Tel: +44 (0)7767 886 005 (Mobile)
Fax: +44 (0)870 400 5001
Skype: richard.wallis1
IM: rjw...@hotmail.com
I-Name: =Richard.Wallis
Godmar Back
<richard...@talis.com> wrote:
> Not being able to guarantee what the stream of AtomPub data will be used for
> after it has been output from a Jangle instance it would be short sighted to
> preclude a consuming application from augmenting that stream with other
> data. With option a) such an application would have the option
> of inserting things in the atom:content slot or preferably adding (using its
> own namespace) its data as sibling elements alongside the Jangle data.
Composability, good point.
> I don't think it is any accident that YouTube does it this way.
I might add that Atom is used by all APIs that belong to the GData
family, not just youtube - also blogs, docs, spreadsheets, health,
etc. see http://code.google.com/apis/gdata/ for details.
> I agree with your view that this kind of decision is not about the ILD-DI
> itself, but about how this reference implementation interprets it in to a
> service.
I had meant to imply the opposite, which is that the ILS-DI community
should provide input to and reach tentative agreement on which
representation should be chosen by ILS-DI implementations (Jangle and
others.) Right now, there is a lot of open ends, vagueness, and
speculation in the spec draft. As a result, created implementations
may not be interoperable with each other and with clients.
- Godmar
Ross Singer
The former makes an assumption that the only payload that the feed
would carry is XML, and I don't like that. Jangle (ILS-DIers, you can
skip ahead a couple of paragraphs) currently returns MARC8, MARC21,
text/x-vcard -- it also might include application/pdf, text/calendar,
etc.
I'm not sure I buy Richard's argument that an augment service might
want to put something in the atom:content field. After all, an
augment service is going to have to assume that the content field is
being used.
YouTube is, in fact, using the content field. That's where they put
the HTML to embed a video in a feed.
In my mind it gets to what the purpose of the feed is for. I think
the data found in Jangle (and, somewhat by extension, ILS-DI) is /not/
going to be something you just display in a public interface, unlike
YouTube or Google Calendar feeds. I think the majority of feeds are
going to be collections of things that will require some manipulation
to be presentable, and if that's more the rule than the exception, I
think it should be designed to reflect that.
GData's universe is pretty tightly contained and highly popular.
Jangle can be carrying any number of things (marc records, ISO ILL,
OpenURL SAP2, EAD, PREMIS, etc.) -- namespacing would require a priori
knowledge of what you're looking for in a given feed (although there'd
be no way to know via machine readable mechanisms what is there),
whereas using atom:content just allows you to consistently grab the
payload from a single place, without needing to know what it is
beforehand.
Namespacing is not without it's advantages, of course. The
atom:content approach only allows for one record to be sent at a time,
whereas as namespacing would (theoretically) allow for multiple
documents to be sent in a given entry. I just think it would be very
confusing to implement from a client perspective and the Atom clients
that exist wouldn't be able to do anything with it (whereas you can
just use an Atom client and grab the content attribute using the
latter approach).
Now, what _may_ be of interest to the ILS-DIers is a thread on the
VuFind-Tech list regarding the simpleAvailability schema:
http://sourceforge.net/mailarchive/forum.php?thread_name=4875C71B.20702%40gbv.de&forum_name=vufind-tech
Was Jakob's simple availability API considered when the
ExpandedRecords schema was being made?
http://www.gbv.de/wikis/cls/Document_Availability_Information_API
-Ross.
Godmar Back
>
> Let me go ahead and say that I prefer b).
>
> The former makes an assumption that the only payload that the feed
> would carry is XML, and I don't like that. Jangle (ILS-DIers, you can
> skip ahead a couple of paragraphs) currently returns MARC8, MARC21,
No, they should be reading it and chiming in. Otherwise, we'll end up
with a bunch of implementations, some vendor-provided (hopefully),
some homegrown, who won't interoperate with anything but their own
sibling projects.
>
> GData's universe is pretty tightly contained and highly popular.
> Jangle can be carrying any number of things (marc records, ISO ILL,
> OpenURL SAP2, EAD, PREMIS, etc.) -- namespacing would require a priori
> knowledge of what you're looking for in a given feed (although there'd
> be no way to know via machine readable mechanisms what is there),
> whereas using atom:content just allows you to consistently grab the
> payload from a single place, without needing to know what it is
> beforehand.
>
In version a), I'd be processing the feed by xpathing for
"/atom:feed/atom:entry/dlf:record".
Then I'd be looking at ./dlf:bibliographic/1. I look at the namespace
used (MARCXML, whatever) and know what's there.
In version b), I'd xpath for
/atom:feed/atom:entry/atom:content/dlf:record, then proceed as above.
In both cases I know where to look, and what to look for in the feed,
and in both cases will additional inspection be required to infer the
bibliographic record format if one is included. This inspection will
rely on an XML namespace, and that's not a problem.
I believe you're saying that Jangle will return other representations
of data that isn't wrapped in a ILS-DI DLF record, but, in my view,
that may be a separate discussion to have. <mild_sarcasm>You could
have this discussion with whoever will want to use Jangle, and Jangle
only and has all but given up hope that other systems will also
implement ILS-DI.</mild_sarcasm>. Ubiquity beats variety.
> Now, what _may_ be of interest to the ILS-DIers is a thread on the
> VuFind-Tech list regarding the simpleAvailability schema:
Start a new thread with a new subject?
- Godmar
Godmar Back
> would carry is XML, and I don't like that. Jangle (ILS-DIers, you can
> skip ahead a couple of paragraphs) currently returns MARC8, MARC21,
> text/x-vcard -- it also might include application/pdf, text/calendar,
> etc.
>
Could you clarify this --- are you assuming that the type of the
payload in each entry would be solely and sufficiently described by
the "type" attribute of the atom:content field?
Types such as application/pdf etc. would then be stored as base64
encoded CDATA children, and client conceivably would have to look only
at the type to know how to interpret the payload?
The problem with this is that there's mime type for a DLF record, and
finding/defining one would require agreeing on yet more thing.
An alternative approach for these extended (beyond ILS-DI) services
you're envisioning that also doesn't use up the atom:content child,
may be to have a atom:entry/jangle:content child that uses the "type"
convention just like RFC 4287 defines them for the atom:content child,
and which could be interpreted by Jangle-aware clients.
- Godmar
Ross Singer
>
> On Thu, Jul 10, 2008 at 12:50 PM, Ross Singer <rossf...@gmail.com> wrote:
>>
>> The former makes an assumption that the only payload that the feed
>> would carry is XML, and I don't like that. Jangle (ILS-DIers, you can
>> skip ahead a couple of paragraphs) currently returns MARC8, MARC21,
>> text/x-vcard -- it also might include application/pdf, text/calendar,
>> etc.
>>
>
> Could you clarify this --- are you assuming that the type of the
> payload in each entry would be solely and sufficiently described by
> the "type" attribute of the atom:content field?
>
Yes and no. For some things (application/marc, text/x-vcard,
application/pdf) this is perfectly satisfactory. For others
(application/xml, text/xml) it tells you nothing about the payload.
Arguably, the same heuristics that are applying to namespacing to work
here, though, right?
> Types such as application/pdf etc. would then be stored as base64
> encoded CDATA children, and client conceivably would have to look only
> at the type to know how to interpret the payload?
>
Well, for non-xml things, I think this is mostly true. Hopefully we
won't have too many multipart payloads.
> The problem with this is that there's mime type for a DLF record, and
> finding/defining one would require agreeing on yet more thing.
>
I assume it'd be application/xml.
Of course in the case of Jangle, one of the ways of advertising this
that I've been working with recently is that the Jangle core would
send the feed as:
application/atom+xml;record_type=dlf
Where "record_type" is some agreed upon argument and "dlf" (or
"marcxml" or "oai_dc" or "iso20775") is an agreed upon value. One of
the outcomes I hope for Jangle is some sort of SKOS vocabulary of
record types to unambiguously refer to what you are sending.
> An alternative approach for these extended (beyond ILS-DI) services
> you're envisioning that also doesn't use up the atom:content child,
> may be to have a atom:entry/jangle:content child that uses the "type"
> convention just like RFC 4287 defines them for the atom:content child,
> and which could be interpreted by Jangle-aware clients.
Well, what I don't like about this approach is the notion of a
'Jangle-aware client'. One of the real wins in how Jangle is
currently working is that a developer can use, say, Mark Pilgrim's
Universal Feed Parser to grab a Jangle feed, iterate over the entries
and grab the content attribute. They can take the content value and
shove it into a MARC parser or vCard parser or whatever and not have
to deal with XML structure at all.
If Jangle is an extension, that would be lost and would greatly
diminish its ease of use.
-Ross.
Godmar Back
> 'Jangle-aware client'. One of the real wins in how Jangle is
> currently working is that a developer can use, say, Mark Pilgrim's
> Universal Feed Parser to grab a Jangle feed, iterate over the entries
> and grab the content attribute. They can take the content value and
> shove it into a MARC parser or vCard parser or whatever and not have
> to deal with XML structure at all.
Now that, if true, would be a strong argument in favor of your
approach. The ability to process results without understanding the
AtomPub container using existing Atom processors would be great to
have.
Is it in fact the case that (some? most?) Atom processing software has
the ability to extract foreign XML content based on the mime type set
in a atom:content element? I tried to find the corresponding API for
UFP, but only saw this documentation [1] from which it's not clear
that what you describe is actually supported.
And in any event, since Atom is designed to carry foreign XML, and
since some processing will definitely require the extraction of such
(say <openSearch:totalResults>), it seems to me that such Atom
processors could presumably be configured to follow a different set of
instructions (via Xpath, for instance), when extracting information
from a feed. Plus, they couldn't handle GData.
I know too little about it --- share more information about what you
know Atom processors or libraries do.
- Godmar
[1] http://www.feedparser.org/docs/reference-entry-content.html
Ross Singer
launch a particular parser, but they *should* let you know what the
mime-type of the atom:content is and allow you to get at it just like
any other field.
Unfortunately, the reality is that most Atom parsers are of the
variety like parser either Atom or RSS 0.9/1.0/2.0. As such, their
viewpoint is very "let's syndicate a blog feed!" and tend to ignore
the ability to pass other things in atom:content or hard code them to
text/html, etc.
By way of analogy, the feed parser I'm using for the ILS-DI adapter
works fine for, say, vCard:
require 'feed_tools'
require 'vpim/vcard'
feed = FeedTools::Feed.open('http://demo.jangle.org/openbiblio/actors/')
vcard = Vpim::Vcard.decode(feed.entries.first.content).first
vcard.name.fullname
=> "Barbara Cubin"
Granted, there's some cheating there. I know actors are returned as
vCards in the content field. FeedTools is an example of not having
any convenience methods to determine the type of the content field.
FeedTools has a bit of a problem, however, when dealing with embedded
XML -- when calling entry.content, it encodes the XML entities so:
feed = FeedTools::Feed.open('http://demo.jangle.org/openbiblio/resources/')
feed.entries.first.content
=>"<record xmlns=\"http://www.loc.gov/MARC21/slim\"><leader>
Z 22 4500</leader><datafield tag=\"245\"
ind1=\"0\" ind2=\"0\"><subfield code=\"a\">Ohne den Vater
Erz\303\244hlung aus dem Kriege</subfield><subfield
code=\"b\"/><subfield code=\"c\">by Agnes
Sapper</subfield></datafield><datafield tag=\"100\"
ind1=\"0\" ind2=\"z\"><subfield code=\"a\">Sapper,
Agnes</subfield></datafield><datafield tag=\"650\"
ind1=\"z\" ind2=\"4\"><subfield
code=\"a\"/></datafield><datafield tag=\"650\" ind1=\"z\"
ind2=\"4\"><subfield
code=\"a\"/></datafield><datafield tag=\"650\" ind1=\"z\"
ind2=\"4\"><subfield
code=\"a\"/></datafield><datafield tag=\"650\" ind1=\"z\"
ind2=\"4\"><subfield
code=\"a\"/></datafield><datafield tag=\"650\" ind1=\"z\"
ind2=\"4\"><subfield
code=\"a\"/></datafield><datafield tag=\"42\" ind1=\"z\"
ind2=\"z\"><subfield
code=\"a\">dc</subfield></datafield><datafield
tag=\"245\" ind1=\"z\" ind2=\"z\"><subfield
code=\"h\">[electronic resource]
/</subfield></datafield><datafield tag=\"260\"
ind1=\"z\" ind2=\"z\"><subfield code=\"b\">Project
Gutenberg,</subfield><subfield
code=\"c\">2004</subfield></datafield><datafield
tag=\"500\" ind1=\"z\" ind2=\"z\"><subfield
code=\"a\">Project
Gutenberg</subfield></datafield><datafield tag=\"506\"
ind1=\"z\" ind2=\"z\"><subfield code=\"a\">Freely
available.</subfield></datafield><datafield tag=\"516\"
ind1=\"z\" ind2=\"z\"><subfield code=\"a\">Electronic
text</subfield></datafield><datafield tag=\"830\"
ind1=\"z\" ind2=\"z\"><subfield code=\"a\">Project
Gutenberg</subfield><subfield
code=\"v\">11677</subfield></datafield><datafield
tag=\"856\" ind1=\"z\" ind2=\"z\"><subfield
code=\"u\">http://www.gutenberg.org/etext/11677</subfield><subfield
code=\"3\">Rights</subfield></datafield><datafield
tag=\"856\" ind1=\"z\" ind2=\"z\"><subfield
code=\"u\">http://www.gutenberg.org/license</subfield></datafield></record>"
So, not only is it escaped (it shouldn't be), it's not even escaped
correctly (it doesn't double escape the already escaped XML, for
example).
So, to parse the MARCXML, I'd have to:
require 'feed_tools'
require 'marc'
feed = FeedTools::Feed.open('http://demo.jangle.org/openbiblio/resources/')
marc = MARC::XMLReader.new(StringIO.new(feed.entries.first.xml_document.elements['entry'].elements['content'].elements[1].to_s))
record = nil
marc.each { | rec | records = rec } # I know there's only one record in there.
record['245'].value
=> "Ohne den Vater Erz\303\244hlung aus dem Kriegeby Agnes Sapper"
record['100'].value
=> "Sapper, Agnes"
Granted. I have no idea if this is a compelling argument or not.
I'm just not sure how it would work if the MARC record was Entry child.
-Ross.
Richard Wallis
Mike Rylander
<richard...@talis.com> wrote:
> I still believe option a) is the way forward.
> The assumption that you would only be able to carry a non-XML payload in the
> atom:content is misleading. You could carry such a payload within
> any extension to atom.
> Godmar's suggestion of an atom:entry/jangle:content child that uses the
> "type" convention just like RFC 4287 sounds worth exploring.
Actually, IMO, this is definitely not the direction I'd want to go.
If atom has a mechanism for transporting arbitrary data (sufficiently
namespaced with a mime type) then it is my opinion that we should use
only that. Extending atom proper specifically for the purpose of
carrying Jangle data pushes content down into the transport format.
(Not to sound too glib, but ...) There's another spec that has
ossified into this position as well: MARC21. The preponderance of
bibliographic content is now (in practice) specified in terms of MARC
fields, instead of an abstract model, locking us into the transmission
format cum input/storage/indexing format. :(
So, I prefer to think of atom in Jangle as simply a way to leverage
some existing set of software libraries for the purpose of moving the
important bits from one process to the next. If the Jangle client has
to know anything special about how the data come to it then I consider
that a failure with regard to separation of content and protocol. If,
instead, we say "everything that the /data aware/ portion of the
Jangle client can come from atom:content" (with random bits of useful
markers and metadata -- author, dates, etc -- in well-defined,
standard atom-ish places) then the atom processor and the Jangle logic
can be completely separated and, as a happy side effect, simpler (and
reusable!).
The argument that XML precludes proprietary and/or non-interoperable
formats is a straw-man, in my opinion. Witness SOAP -- good
integration is only reasonable between clients and servers of the same
make and model.
So ... my vote is for option b.
</rant>
--
Mike Rylander
| VP, Research and Design
| Equinox Software, Inc. / The Evergreen Experts
| phone: 1-877-OPEN-ILS (673-6457)
| email: mi...@esilibrary.com
| web: http://www.esilibrary.com
Richard Wallis
So, I prefer to think of atom in Jangle as simply a way to leverage
some existing set of software libraries for the purpose of moving the
important bits from one process to the next. If the Jangle client has
to know anything special about how the data come to it then I consider
that a failure with regard to separation of content and protocol.
The argument that XML precludes proprietary and/or non-interoperable
formats is a straw-man, in my opinion. Witness SOAP -- good
integration is only reasonable between clients and servers of the same
make and model.
Mike Rylander
On Fri, Jul 11, 2008 at 12:25 PM, Richard Wallis
<richard...@talis.com> wrote:
>
> On 11 Jul 2008, at 16:21, Mike Rylander wrote:
>
> So, I prefer to think of atom in Jangle as simply a way to leverage
> some existing set of software libraries for the purpose of moving the
>
> important bits from one process to the next. If the Jangle client has
> to know anything special about how the data come to it then I consider
> that a failure with regard to separation of content and protocol.
>
*
> I couldn't agree more - hence my plea for XML by default (optionally ship
> other things if you want, but only by request) inside the AtomPub wrapper -
> regardless of us coming down on the a) or b) side of this discussion.
>
*
For the purposes of any particular API, I think the content format
should be decided on a case by case basis ... it's the introduction of
"somewhere else to look" when atom has a suitable location
(atom:content) that was my concern. If the API should use XML, sure,
but it's more about separation of content and delivery mechanism that
I care about here. And I could be getting it all wrong, but it seems
that atom:content is the prescribed way to handle arbitrary data. No?
> The argument that XML precludes proprietary and/or non-interoperable
> formats is a straw-man, in my opinion. Witness SOAP -- good
> integration is only reasonable between clients and servers of the same
>
> make and model.
>
*
> It wasn't XML that did that for SOAP - it was the fact that it was a
> tightly-coupled, heavily schema'd protocol that required the consumer to
> understand the business logic of the producer service that just so happened
> to use XML for its message exchange - unlike loosely-coupled REST based
> services. Amazon's AWS, uses both the SOAP and REST to transport the same
> XML for their message content but I believe there is only a few of the many
> thousands of AWS developers that use SOAP.
>
*
My view is a little different ... it's more about the type abmiguity
of SOAP that's the huge pain. The format itself leaves enough up to
the implementor to cause problems. The point, though, wasn't SOAP,
but that XML isn't /the/ answer. I would go along with the idea of
XML-as-best-practice for anything that doesn't already have a well
supported non-XML format AND open libraries in the preponderance of
languages for handling that format.
Ross Singer
> My view is a little different ... it's more about the type abmiguity
> of SOAP that's the huge pain. The format itself leaves enough up to
> the implementor to cause problems. The point, though, wasn't SOAP,
> but that XML isn't /the/ answer. I would go along with the idea of
> XML-as-best-practice for anything that doesn't already have a well
> supported non-XML format AND open libraries in the preponderance of
> languages for handling that format.
This, I think, is the core of the "debate".
Rather than being an XML format, I tend to view Jangle as an
interchange API that uses "cheap, commodity" standards as a means for
more easily meeting developers' needs. While it's an added bonus that
it happens to be serialized as XML, and can therefore be parsed with
DOM tools or XPath and transformed into other formats with XSLT, I'm
more inclined to lean towards a format that, by using a common client
library, can get a developer the data they are looking for without
having to care about Atom's schema.
I will happily concede to the fact that my Ruby background has made me
a sucker for domain specific languages, I don't *want* to know the
underlying data structures, I just want an object that has attributes
and methods that make sense from a Ruby perspective.
And this is why, ultimately, I don't care what Jangle is transporting.
If there is a format with broadly accepted client support, I would
prefer that over an XML document. If there isn't that, then,
definitely, give me XML (or JSON). In almost every case, I would
prefer the option of both, and since Atom is capable of that, this
shouldn't be a problem.
As far as the argument of "always send XML first", I don't really care
one way or the other as long as alternate feeds are the preferred
practice for implementation.
-Ross.
Godmar Back
>
> On Fri, Jul 11, 2008 at 5:18 AM, Richard Wallis
> <richard...@talis.com> wrote:
>> I still believe option a) is the way forward.
>> The assumption that you would only be able to carry a non-XML payload in the
>> atom:content is misleading. You could carry such a payload within
>> any extension to atom.
>> Godmar's suggestion of an atom:entry/jangle:content child that uses the
>> "type" convention just like RFC 4287 sounds worth exploring.
>
> Actually, IMO, this is definitely not the direction I'd want to go.
> If atom has a mechanism for transporting arbitrary data (sufficiently
> namespaced with a mime type) then it is my opinion that we should use
> only that.
Interestingly, you don't do that in Evergreen's atom-full output. You
place the <dc:identifier> element as a sibling of content, not a
child.
I also think the impression that the implication about Atom's
intention here is wrong.
I spent some time analyzing the GData Java and Python APIs. They
provide so-called extension profiles that provide a structured way of
describing the extended information that may be carried in an Atom
feed in a convenient manner. This approach clearly relies on the
namespace of foreign XML elements that are siblings of entry and
content, respectively. There is no support for customizing the
handling of content children based on their type.
>
> So, I prefer to think of atom in Jangle as simply a way to leverage
> some existing set of software libraries for the purpose of moving the
> important bits from one process to the next. If the Jangle client has
> to know anything special about how the data come to it then I consider
> that a failure with regard to separation of content and protocol. If,
> instead, we say "everything that the /data aware/ portion of the
> Jangle client can come from atom:content" (with random bits of useful
> markers and metadata -- author, dates, etc -- in well-defined,
> standard atom-ish places) then the atom processor and the Jangle logic
> can be completely separated and, as a happy side effect, simpler (and
> reusable!).
While I agree with your sentiment, after examining the gdata client
libraries, I do not share this concern. The amount of code/technique
that's required to decouple the transport mechanism from the carried
content is probably similar in either approach. This statement is
likely true for most Atom processing libraries. And at least in the
gdata client libraries, support for option b) is better.
- Godmar
Godmar Back
>
> On Fri, Jul 11, 2008 at 12:48 PM, Mike Rylander <mryl...@gmail.com> wrote:
>
>> My view is a little different ... it's more about the type abmiguity
>> of SOAP that's the huge pain. The format itself leaves enough up to
>> the implementor to cause problems. The point, though, wasn't SOAP,
>> but that XML isn't /the/ answer. I would go along with the idea of
>> XML-as-best-practice for anything that doesn't already have a well
>> supported non-XML format AND open libraries in the preponderance of
>> languages for handling that format.
>
> This, I think, is the core of the "debate".
>
No, not really. The question is what specific Atom embedding to choose
to facilitate our goal of transport-layer obliviousness. So far, we
have little indication that it would be significantly more difficult
to achieve the goal of hiding the XML embedding and the Atom transport
if choosing option b). But GData, at least, provides an extensible
and composable architecture to achieve this very goal for method a).
- Godmar
Mike Rylander
>
> On Fri, Jul 11, 2008 at 11:21 AM, Mike Rylander <mryl...@gmail.com> wrote:
>>
>> On Fri, Jul 11, 2008 at 5:18 AM, Richard Wallis
>> <richard...@talis.com> wrote:
>>> I still believe option a) is the way forward.
>>> The assumption that you would only be able to carry a non-XML payload in the
>>> atom:content is misleading. You could carry such a payload within
>>> any extension to atom.
>>> Godmar's suggestion of an atom:entry/jangle:content child that uses the
>>> "type" convention just like RFC 4287 sounds worth exploring.
>>
>> Actually, IMO, this is definitely not the direction I'd want to go.
>> If atom has a mechanism for transporting arbitrary data (sufficiently
>> namespaced with a mime type) then it is my opinion that we should use
>> only that.
>
> Interestingly, you don't do that in Evergreen's atom-full output. You
> place the <dc:identifier> element as a sibling of content, not a
> child.
>
There are two main differences:
1) The dc extensions are widely recognized -- I got those from atom
example documents linked from high-visibility "how to do this" sites
2) That atom feed generator is designed to be used for an explicit and
specific purpose -- to be able to build a "slim" OPAC on top of
OpenSearch results using pre-existing tools (my mantra in this thread,
it seems) with as little effort as possible. (The Amazon atom-to-html
XSLT from way back when, FWIW.)
> I also think the impression that the implication about Atom's
> intention here is wrong.
>
> I spent some time analyzing the GData Java and Python APIs. They
> provide so-called extension profiles that provide a structured way of
> describing the extended information that may be carried in an Atom
> feed in a convenient manner. This approach clearly relies on the
> namespace of foreign XML elements that are siblings of entry and
> content, respectively. There is no support for customizing the
> handling of content children based on their type.
>
I'm confused ... how does that relate to my argument that, for Jangle,
plain-vanilla atom (use atom:content, use pre-existing tools for the
atom part and new code for the jangle data) is better than extended
atom (augment atom:entry, and write one peice of (more complex) code
that has to know about both atom and the content), especially given
developer tools that explicitly know about atom:content and provide
convenience accessors for whatever happens to be in there?
>>
>> So, I prefer to think of atom in Jangle as simply a way to leverage
>> some existing set of software libraries for the purpose of moving the
>> important bits from one process to the next. If the Jangle client has
>> to know anything special about how the data come to it then I consider
>> that a failure with regard to separation of content and protocol. If,
>> instead, we say "everything that the /data aware/ portion of the
>> Jangle client can come from atom:content" (with random bits of useful
>> markers and metadata -- author, dates, etc -- in well-defined,
>> standard atom-ish places) then the atom processor and the Jangle logic
>> can be completely separated and, as a happy side effect, simpler (and
>> reusable!).
>
> While I agree with your sentiment, after examining the gdata client
> libraries, I do not share this concern. The amount of code/technique
> that's required to decouple the transport mechanism from the carried
> content is probably similar in either approach. This statement is
> likely true for most Atom processing libraries. And at least in the
> gdata client libraries, support for option b) is better.
>
So, if the gdata toolset is your library of choice, then you support
option b) as well, then? If that's the case, then all we need to do is
convince Richard. ;)
> - Godmar
Godmar Back
>
> There are two main differences:
>
> 1) The dc extensions are widely recognized -- I got those from atom
> example documents linked from high-visibility "how to do this" sites
Would you care to provide a reference?
> it seems) with as little effort as possible. (The Amazon atom-to-html
> XSLT from way back when, FWIW.)
Google doesn't show it --- do you have a reference.
>
> I'm confused ... how does that relate to my argument that, for Jangle,
> plain-vanilla atom (use atom:content, use pre-existing tools for the
> atom part and new code for the jangle data) is better than extended
> atom (augment atom:entry, and write one peice of (more complex) code
> that has to know about both atom and the content), especially given
> developer tools that explicitly know about atom:content and provide
> convenience accessors for whatever happens to be in there?
>
I do not think that there's such a thing a plain-vanilla atom, and I
have not seen enough evidence that the model Ross and you assume (in
which "plain-vanilla atom tools" process atom feeds and hand
atom:content children to clients) is in fact the dominant used by
preexisting tools.
I've shown an example of a significant system (gdata) which is clearly
designed with a different mode of using Atom - specifically, what we
referred to as option b); could you show examples of services and
software where your proposed mode is preferred and supported?
Also, could it be that there was a shift in how people are now
thinking about how to employ Atom? After all, the standard itself
allows foreign elements at both the feed and entry levels - maybe the
adopters of this standard wanted to be open to shifts in best
practices on how their design is being used. It wouldn't be the first
time that the dominant use of an application layer protocol changes.
- Godmar
Mike Rylander
>
> On Fri, Jul 11, 2008 at 4:47 PM, Mike Rylander <mryl...@gmail.com> wrote:
>>
>> There are two main differences:
>>
>> 1) The dc extensions are widely recognized -- I got those from atom
>> example documents linked from high-visibility "how to do this" sites
>
> Would you care to provide a reference?
>
I'd like to, but that was nearly three years ago so I don't have the
URLs handy. I'll dig around on the internets when I have a chance,
though.
>> it seems) with as little effort as possible. (The Amazon atom-to-html
>> XSLT from way back when, FWIW.)
>
> Google doesn't show it --- do you have a reference.
>
That one's easy, though: http://www.opensearch.org/Documentation/Stylesheet
>>
>> I'm confused ... how does that relate to my argument that, for Jangle,
>> plain-vanilla atom (use atom:content, use pre-existing tools for the
>> atom part and new code for the jangle data) is better than extended
>> atom (augment atom:entry, and write one peice of (more complex) code
>> that has to know about both atom and the content), especially given
>> developer tools that explicitly know about atom:content and provide
>> convenience accessors for whatever happens to be in there?
>>
>
> I do not think that there's such a thing a plain-vanilla atom, and I
> have not seen enough evidence that the model Ross and you assume (in
> which "plain-vanilla atom tools" process atom feeds and hand
> atom:content children to clients) is in fact the dominant used by
> preexisting tools.
>
As my rapid development language of choice is Perl:
http://search.cpan.org/~miyagawa/XML-Atom-0.28/lib/XML/Atom/Entry.pm
> I've shown an example of a significant system (gdata) which is clearly
> designed with a different mode of using Atom - specifically, what we
> referred to as option b); could you show examples of services and
> software where your proposed mode is preferred and supported?
>
Option b (use atom:content, from your original post) is what I'm
advocating! Some wires got crossed somewhere, I think.
Godmar Back
>
>> I've shown an example of a significant system (gdata) which is clearly
>> designed with a different mode of using Atom - specifically, what we
>> referred to as option b); could you show examples of services and
>> software where your proposed mode is preferred and supported?
>>
>
> Option b (use atom:content, from your original post) is what I'm
> advocating! Some wires got crossed somewhere, I think.
>
Sorry, I confused a) and b) ---- I mean to not restrict the content to
atom:entry/atom:content/1, I mean that it's likely better to use a
atom:entry/dlf:record or using a atom:entry/jangle:content child.
>
> As my rapid development language of choice is Perl:
>
> http://search.cpan.org/~miyagawa/XML-Atom-0.28/lib/XML/Atom/Entry.pm
That's not the proof I'm looking for. Perl makes retrieving a foreign
element as simple as getting the content, see further down on that
page:
http://search.cpan.org/~miyagawa/XML-Atom-0.28/lib/XML/Atom/Entry.pm#$entry-%3Eget($ns,_$element)
The question is how simple it is to get at the content inside using a
more suitable type, or passing it to a library that subsequently
processes it.
This is what the GData is designed for. See, for instance,
http://code.google.com/apis/gdata/javadoc/com/google/gdata/data/ExtensionProfile.html
- Godmar
Ross Singer
This is my main argument. Why extend something that has no need for extension?
Atom is /designed/ to transport other data whether it be HTML, inline
images or xml /in the atom:content field/.
What are we reserving it for?
-Ross.
Godmar Back
>
> Why is Atom:content not a suitable type?
>
It is an option, or else we wouldn't be having this discussion.
> This is my main argument. Why extend something that has no need for extension?
>
> Atom is /designed/ to transport other data whether it be HTML, inline
> images or xml /in the atom:content field/.
>
Atom is equally designed to transport other data in
atom:entry/foreign:fields. Neither choice would be "extending" Atom as
a protocol.
The question is which fits better into a) existing custom and b)
existing processing tools, if there is a significant difference.
> What are we reserving it for?
>
What's the last piece of cake that nobody wants to take reserved for?
Future use?
One answer is to carry human-readable information (you pointed out
that may not be an important concern, I tend to agree), but the
stronger answer is composability as Richard pointed out. It also
seems more conservative to not use that position in the feed.
In GData, btw, that stuff would arrive as "OtherContent" from which
you have to grab the XmlBlob explicitly, whereas you can define custom
classes for other foreign content and have the parser instantiate
those automatically when it sees the corresponding namespace.
- Godmar
Godmar Back
that it eliminates the need to define a "root" element when there is
no natural root element in the case where XML content is carried.
In fact, the Perl API to which Mike pointed even has a convenience
method retrieving multiple foreign elements at once:
http://search.cpan.org/~miyagawa/XML-Atom-0.28/lib/XML/Atom/Entry.pm#$entry-%3Egetlist($ns,_$element)
- Godmar
Mike Rylander
>
> On Fri, Jul 11, 2008 at 10:00 PM, Mike Rylander <mryl...@gmail.com> wrote:
[snip]
>>
>> http://search.cpan.org/~miyagawa/XML-Atom-0.28/lib/XML/Atom/Entry.pm
>
> That's not the proof I'm looking for. Perl makes retrieving a foreign
Then I've failed to explain the separation-of-powers point properly.
> element as simple as getting the content, see further down on that
> page:
>
> http://search.cpan.org/~miyagawa/XML-Atom-0.28/lib/XML/Atom/Entry.pm#$entry-%3Eget($ns,_$element)
>
> The question is how simple it is to get at the content inside using a
> more suitable type, or passing it to a library that subsequently
> processes it.
>
Because every library (that I've seen, though perhaps not the GData
API?) can say "give me the atom:content data," and the part that does
that does not have to know about a dlf:record element or whatever.
You can separate the "get some data from somewhere" logic out into an
atom parser and the "figure out how to process it" logic into
completely different, pluggable module. The atom parser deals with
atom (and could be replace with a Z parser or SRU parser or RSS parser
or file parser or ...) and the data handling logic can deal with the
data, instead of conflating the data with the transmission wrapper
format.
Godmar Back
>
> Because every library (that I've seen, though perhaps not the GData
> API?) can say "give me the atom:content data," and the part that does
> that does not have to know about a dlf:record element or whatever.
> You can separate the "get some data from somewhere" logic out into an
> atom parser and the "figure out how to process it" logic into
> completely different, pluggable module. The atom parser deals with
> atom (and could be replace with a Z parser or SRU parser or RSS parser
> or file parser or ...) and the data handling logic can deal with the
> data, instead of conflating the data with the transmission wrapper
> format.
>
Whichever approach we're using, it should be clear that the concerns
of interpreting the data and embedding the data in a container must be
separated to a sufficient degree. I agree with you on that.
In your approach, to separate these concerns, you require that the
transport logic create a data structure to carry single XML blobs and
pass instances of this structure to downstream processing code.
The downstream processing code then examines the content type, and
branches. The content type module then must maintain logic to know
which types it understands and which it doesn't.
Although your approach - by design - maintains this separation, it's
not the only approach that does so. You can also maintain separation
when using foreign elements by simply choosing a different interface
to your transport layer, one that allows the next layer to retrieve
only those elements in which it is interested. A more sophisticated
approach is to provide the transport layer in a generic way with the
necessary data structures and code to parse and reify the content in
which the next layer is interested in a manner that avoids coupling
these two modules. (That method is used, for instance, by some
networking stacks in which higher layers pass down opaque functions to
lower layers which perform the higher layer's protocol processing and
payload retrieval. It has a number of advantages, including
efficiency, better resource managements, and early discard of packets
you end up not wanting.)
So, a related question is which interface we expect the transport
container layer to provide. Do we want to restrict ourselves to a
simple iterator interface that requires the layer to pass identified
objects by copy in a generic, agreed-upon format, or are we prepared
to support models that are more flexible and (potentially) more
efficient and which, independently, in the case of Atom, also allows
composability and other uses of the container format.
Your approach wins on simplicity; but is it simplistic and would
prevent us from using Jangle in the way we'd want? GData, not to
overstress this example, decided to design for a container format that
does not assume this simple/simplistic use of Atom.
- Godmar
Godmar Back
> to support models that are more flexible and (potentially) more
> efficient and which, independently, in the case of Atom, also allows
> composability and other uses of the container format.
>
Another way to express this part of the argument is this: should we
restrict Jangle to container formats that are homogeneous, such as SRU
or a stream of atom:feed/atom:entry/atom:content elements, or should
we embrace and support the ability of AtomPub to support heterogeneous
streams of elements, even if it means that, for instance, we couldn't
use SRU instead of Atom? Do we envision that a Jangle feed is
processed only by a Jangle-aware client, and that's that, or do we
support other modes as well? For instance, imagine a service such as
LibraryThing or xISBN that enriches entries with additional
information and provides the results as an AtomPub.
- Godmar
Ross Singer
for a particular resource?
I have tried to reconcile this in the past, but I had a hard time
trying to figure out what any particular resource URI should
represent. This is an issue regardless of the approach we use; is the
intention of the URI the atom entity or the contained record format?
-Ross.
Godmar Back
>
> What would be the scenario where you get multiple record formats back
> for a particular resource?
>
> I have tried to reconcile this in the past, but I had a hard time
> trying to figure out what any particular resource URI should
> represent. This is an issue regardless of the approach we use; is the
> intention of the URI the atom entity or the contained record format?
>
I think a resource is whatever information is returned by a service
based on the resource's identifier. That's also in keeping with
Fielding's definition of REST [1], where he writes:
"The key abstraction of information in REST is a resource. Any
information that can be named can be a resource: a document or image,
a temporal service (e.g. "today's weather in Los Angeles"), a
collection of other resources, a non-virtual object (e.g. a person),
and so on. (...) A resource is a conceptual mapping to a set of
entities, not the entity that corresponds to the mapping at any
particular point in time."
More specifically, the resources provides by Jangle may be single
records or collection of records in one more formats.
The use of Atom, and the embodiment of those records in elements of
this protocol using the methods currently under discussion would not
be the resource itself, but a representation of this resource that
combines the resource's data and metadata.
- Godmar
[1] http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm
Richard Wallis
over the weekend I'm totally confused as to which one I'm replying to
and which one I'm supposed to be convinced by ;-)
So generalising a bit to clarify my thoughts....
Although AtomPub has taken on a life of it's own, it hasn't lost it's
RSS1.0 heritage and the ability to be handled by various end user tools
and developer libraries. When spending significant time a few years
back working in the RSS/Atom field (with the help of the excellent Java
library ROME https://rome.dev.java.net/), I used patterns for
transporting data within the Atom format that followed many examples and
seemed the most flexible.
Although the Atom:Entry/Atom:Content element could/can carry any
arbitrary data, the convention was that it would contain a human
readable text representation of the entry. A more structured machine
readable form of the data would then be transported in separately
namespaced child elements of Atom:Entry. The benefits of this approach
(which maps to option a) in this thread) is that even simple RSS tools
can have a stab at displaying something useful (great for debug if
nothing else). Then for seriously working with the data, you pull out
what is in the Atom:Entry/ils-di:content element. As [I think] indicated
in this thread, most XML processing libraries in most languages (not
forgetting good old XSLT) are capable of using namespaces to simply
isolate these structures for handling in the way that we are trying to
achieve here.
Both options are within the rules of XML & AtomPub so we are discussing
conventions here - will the 'will the new-line / end-of-line debate
about where you put the curly bracket debate *ever* be settled? - I
doubt it'. Having worked as I described above, I'm still pro option a).
~Richard.
Ross Singer
Anybody have anything else they want to throw in the ring?
-Ross.
Godmar Back
go the option b) route.
Has anybody looked at which option Microsoft is using in Live (which
also uses AtomPub)?
- Godmar
ps: The Python libraries for the Google App Engine, perhaps
unsurprisingly, also use the GData standard.
Matthias Steffens
I just joined the list so please forgive my ignorance if I'm stating
something obvious. I did read this thread with much interest, and I'd
like to support Richard's point of view:
Richard Wallis wrote on Mon, 14 Jul 2008 12:23:45 +0100:
> Although the Atom:Entry/Atom:Content element could/can carry any
> arbitrary data, the convention was that it would contain a human
> readable text representation of the entry. A more structured machine
> readable form of the data would then be transported in separately
> namespaced child elements of Atom:Entry. The benefits of this approach
> (which maps to option a) in this thread) is that even simple RSS tools
> can have a stab at displaying something useful (great for debug if
> nothing else).
consumed by simple feed readers, i.e. IMHO I'd prefer if the
'atom:content' element would contain a human-readable representation
of the entry.
> Then for seriously working with the data, you pull out what is in the
> Atom:Entry/ils-di:content element.
anything specific about what namespaces to expect (or which data to
request/extract), give them a common simple format within the standard
Atom elements. And for more knowledgable/capable clients, present more
detailed data within namespaced foreign elements.
I'm one of the refbase developers (refbase.net, a web-based reference
manager), and we did recently add support for OpenSearch + Atom XML.
There, we followed this approach:
- Each 'atom:entry' contains a single bibliographic resource.
- For each 'atom:entry', we include the formatted citation as HTML
within the 'atom:content' element, and also include the record's unAPI
identifier there.
- Next to the 'atom:content' element, the record's basic metadata are
included as Simple Dublin Core & PRISM elements. In addition we also
include a plain-text representation of the formatted citation within a
'dcterms:bibliographicCitation' element. And an appropriate OpenURL
context object is given within a 'dc:identifier' element.
- For each 'atom:entry', we include direct links to available export &
citation formats within the 'atom:link rel="alternate"' element, and
give the MIME type (e.g. 'application/x-bibtex') in the 'type'
attribute. By this we can advertise several different representations
of the same resource within the same entry (using a standard Atom
mechanism) but without the need to directly include them all (thus
saving some bandwidth). Btw, the same is done on 'atom:feed' level so
that all entries given in an Atom feed can be retrieved in a different
representation (say SRU + MODS XML) at once.
So, in other words, we opted to:
- give a human-readable representation of the resource in 'atom:entry'
- provide metadata as namespaced child elements of 'atom:entry' using
a rather simple & common metadata format (Simple DC)
- allow clients to easily add support for COinS & unAPI within their
own interfaces (which, in turn, allows for compatibility with tools
such as Zotero, LibX, etc)
- don't directly include the more specialized output formats but link
to them (on entry as well as feed level) in a standard way
The nice thing with this approach is that, by default, regular feed
readers will display them just fine. Here's an example screenshot that
shows how a popular feed reader for the Mac (NetNewsWire) displays the
feed data:
http://store.extracts.de/refbase-AtomFeed-NetNewsWire.png
Here's an example of such an OpenSearch Atom XML feed:
http://beta.refbase.net/opensearch.php?query=dc.title%3DBaltic&maximumRecords=15
Regards,
Matthias
Godmar Back
<matthias...@googlemail.com> wrote:
>
> - For each 'atom:entry', we include direct links to available export &
> citation formats within the 'atom:link rel="alternate"' element, and
> give the MIME type (e.g. 'application/x-bibtex') in the 'type'
> attribute. By this we can advertise several different representations
> of the same resource within the same entry (using a standard Atom
> mechanism) but without the need to directly include them all (thus
> saving some bandwidth).
>
> - don't directly include the more specialized output formats but link
> to them (on entry as well as feed level) in a standard way
>
As much as I like it when people agree with me, the two paragraphs I
quote above show that your consideration doesn't apply here in the
sense that we are looking to define how to carry specialized output
formats with the confines of the AtomPub publishing protocol.
In other words, this discussion is about how to use AtomPub to carry
the primary content, rather than how to use AtomPub as a way to make
public pointers/link to content or summarized representations that can
be read by feed readers.
I agree with Ross that the idea of compatibility with feed readers,
while nice, is becoming less and less important; and that AtomPub now
is no longer a syndication format that also carries additional data,
but instead a data format that was previously used for syndication.
- Godmar
Ross Singer
(even if it's for the "other proposal" :) ).
I understand the more general points about the desire to put human
readable content in the atom:content field and why, given the data
that BibRef deals with, you've gone this route.
Where I run into problems with this line of thought in the context of
Jangle is how the only real entity (of the 4 or to-be-decided 5:
Actors, Resources, Items, Collections and the possible Events) that
would have a consistent human readable representation would be
Resources. Even then it seems like a rather contrived use of html.
The atom feeds with the data they're currently carrying display fine
in feed readers, I should note. So far, everything I have tried
ignores the content tag.
I could possibly be talked into an atom extension for carrying the
Jangle payloads, but really only if:
A) the extension already exists and is used often enough to have a
good client support base (i.e. GData or OpenSearch). I will ride
somebody else's coattails, happily, but I'm not terribly interested in
creating an extension that will be largely ignored and unknown by the
world at large. Since there will be both Jangle consumers and
producers, being able to simply point developers at tools that can
easily create/parse the content, without the user needing to be
completely familiar with Jangle is a must, IMO, if Jangle is to get
anywhere.
- or -
B) Awareness of Jangle raises a few orders of magnitude (ok, many many
orders of magnitude) to justify its own atom extension.
I have been fighting for the better part of 15 years to have library
services incorporated outside of the library walls (or other
libraries). The conversation always derails when an external
developer has to deal with something library specific, whether it's
Z39.50, OpenURL or whatever we throw at them.
I have no confidence that a Jangle atom extension wouldn't suffer the same fate.
However, in the interest of "getting to yes" on this issue I'll propose this:
1) Everyone pitches in proposals of an existing extension that could
suffice for this purpose.
2) Failing an acceptable existing extension, we create a
jangle:content extension that, for all intents and purposes, behaves
like atom:content.
3) A mechanism still exists to replace the atom:content field with the
payload in the jangle:content field to support non-jangle aware
clients with jangle-enabled feeds.
Godmar and Richard are still free to include namespaced data as
children of atom:entry, as well on top of what's directly being
transported by the Jangle request.
-Ross.
On Mon, Jul 14, 2008 at 10:07 AM, Matthias Steffens
<matthias...@googlemail.com> wrote:
>
Matthias Steffens
thanks for your detailed replies.
On 14 Jul., 16:53, "Godmar Back" <god...@gmail.com> wrote:
> your consideration doesn't apply here in the sense that we are
> looking to define how to carry specialized output formats with
> the confines of the AtomPub publishing protocol.
>
> In other words, this discussion is about how to use AtomPub to carry
> the primary content, rather than how to use AtomPub as a way to make
> public pointers/link to content or summarized representations that can
> be read by feed readers.
that you need to account for more complex (or manifold) data. My
example was not intended to make a real proposal for Jangle. Instead,
I mainly wanted to illustrate my point that I consider it a big bonus
if the Atom feed (although being considered as a data format) still
works reasonably well with regular feed readers. This seems to be the
case anyways as Ross pointed out. So never mind.
Matthias
Godmar Back
http://visitmix.com/blogs/2008Sessions/T19/
In summary, Microsoft appears to be
- using the atom:content child for data
- encourage carrying different representations by reference using
atom:content src elements
- freely adds metadata using atom:entry siblings.
Castro drew a distinction between data and metadata in his discussion,
with the data carried in atom:content.
Overall, they seem to be more in the option a) camp.
- Godmar
ps: note the nice way in which they allow access to elements within
the feed by adjusting the URL.
See, for instance:
https://cumulus.services.live.com/pabl...@live.com/AtomSpacesPhotos/Folders
https://cumulus.services.live.com/pabl...@live.com/AtomSpacesPhotos/Folders(144)
https://cumulus.services.live.com/pabl...@live.com/AtomSpacesPhotos/Folders(144)/title/$value
Ross Singer
Anyway, yes, this is a good find, Godmar, thanks.
I *think* MS is doing this in a similar way to how I have been
perceiving Jangle and I like the way that they are using their
extension: rather than it being a child element, they are putting
some LiveSpaces-specific information as namespaced attributes which, I
guess, is giving some context about how the atom:content field is
being used. If you client implementation can make assumptions about
what those attributes might say, you can ignore them and just use any
atom parser, as is.
I also like their use of categories, which I have considering a
proposal for defining distinctions between resources.
-Ross.
Peter Murray
Hash: SHA1
On Jul 14, 2008, at 1:16 PM, Ross Singer wrote:
> Well, now I can't remember which option is a or b :)
I've lost a view of the forest for looking at the trees. If someone
could summarize the discussion of two options, I would be most
appreciative.
Peter
- --
Peter Murray http://www.pandc.org/peter/work/
Assistant Director, New Service Development tel:+1-614-728-3600;ext=338
OhioLINK: the Ohio Library and Information Network Columbus, Ohio
The Disruptive Library Technology Jester http://dltj.org/
Attrib-Noncomm-Share http://creativecommons.org/licenses/by-nc-sa/2.5/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)
iD8DBQFIe44A4+t4qSfPIHIRAts6AJ9hMwrim3Bj8t3sDyTqSEqFb/aaowCeNXoy
hzPkT/mQYo8G+CZdSggkOTE=
=gPQ2
-----END PGP SIGNATURE-----
Ross Singer
Ok, it's basically about whether:
A) Jangle should transport its contents in a namespaced child of
atom:entry via an extension so:
feed/entry/jangle:content/oai_dc:dc(for example)
or
B) Jangle should transport its contents in the normal atom:content field:
feed/entry/content/oai_dc:dc
Either way the functionality is basically the same, it's just a debate
over whether to use vanilla atom or atom extensions.
-Ross.
Peter Murray
Hash: SHA1
Yeah, but you forgot to mention who is advocating which side. That
way I'll know in advance who thinks I'm an idiot for making the wrong
choice. ;-)
That said, and realizing that this is coming from a new and somewhat
timid yet convert to Atom, I'm in favor of 'b'. Vanilla Atom is good
from an interoperability standpoint because of the clean break between
Atom as a transport and the actual content appearing in the document.
Since the chances that the resulting content would appear unmodified
in-the-wild (e.g. through a feed reader or unparsed on an HTML page),
it would seem more important to stick with clean break rather than
introducing an Atom extension.
Peter
On Jul 14, 2008, at 1:44 PM, Ross Singer wrote:
> Ha!
>
> Ok, it's basically about whether:
>
> A) Jangle should transport its contents in a namespaced child of
> atom:entry via an extension so:
> feed/entry/jangle:content/oai_dc:dc(for example)
>
> or
>
> B) Jangle should transport its contents in the normal atom:content
> field:
> feed/entry/content/oai_dc:dc
>
> Either way the functionality is basically the same, it's just a debate
> over whether to use vanilla atom or atom extensions.
>
> -Ross.
>
> On Mon, Jul 14, 2008 at 1:33 PM, Peter Murray <pe...@ohiolink.edu>
> wrote:
>>
>> On Jul 14, 2008, at 1:16 PM, Ross Singer wrote:
>>> Well, now I can't remember which option is a or b :)
>>
>>
>> I've lost a view of the forest for looking at the trees. If someone
>> could summarize the discussion of two options, I would be most
>> appreciative.
- --
Peter Murray http://www.pandc.org/peter/work/
Assistant Director, New Service Development tel:+1-614-728-3600;ext=338
OhioLINK: the Ohio Library and Information Network Columbus, Ohio
The Disruptive Library Technology Jester http://dltj.org/
Attrib-Noncomm-Share http://creativecommons.org/licenses/by-nc-sa/2.5/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)
iD8DBQFIe5334+t4qSfPIHIRAphlAJ9EVWELwLxE9rkMLYxo4y5hvTaQ7QCfczR/
0srZp6eNWoka0Ntj4lD7emc=
=wcaH
-----END PGP SIGNATURE-----
Godmar Back
> it would seem more important to stick with clean break rather than
> introducing an Atom extension.
>
No, no, no. It's not an Atom extension.
Atom allows foreign content inside atom:content just as it allows
foreign content in atom:entry/jangle:feed. Why would we call one an
"extension" and the other "vanilla"?
Only Ross called it "an extension" and the other variant "plain
vanilla", but that's his (biased) opinion, and not necessarily
undisputed.
If we use mediatypes for atom:content we are also "extending" the Atom
protocol by the types we'll introduce.
I grant that option b) is closed to whatever "vanilla" may mean, but
this potential advantage may be wiped out by the inability to extend
and combine.
- Godmar
Mike Rylander
On Mon, Jul 14, 2008 at 8:00 PM, Godmar Back <god...@gmail.com> wrote:
>
> On Mon, Jul 14, 2008 at 2:41 PM, Peter Murray <pe...@ohiolink.edu> wrote:
>> it would seem more important to stick with clean break rather than
>> introducing an Atom extension.
>>
>
> No, no, no. It's not an Atom extension.
>
> Atom allows foreign content inside atom:content just as it allows
> foreign content in atom:entry/jangle:feed. Why would we call one an
> "extension" and the other "vanilla"?
Because Atom prescribes atom:content for the explicit use of carrying
arbitrary, mime type namespaced data, and adding a brand new element
elsewhere (whether "legal" or not) to serve the same exact purpose is
reasonably labeled "extending" the atom documents coming from your
server?
>
> Only Ross called it "an extension" and the other variant "plain
> vanilla", but that's his (biased) opinion, and not necessarily
> undisputed.
>
No, not only Ross. I call it an extension, too.
> If we use mediatypes for atom:content we are also "extending" the Atom
> protocol by the types we'll introduce.
>
No, because that's /exactly what you're supposed to do/ with atom:content.
> I grant that option b) is closed to whatever "vanilla" may mean, but
> this potential advantage may be wiped out by the inability to extend
> and combine.
>
How do you figure? Microsoft, as mentioned before, has managed to
work around this "impossibility", and I fail to see how putting
something in box X now precludes us from adding a new box Y later, as
a peer to atom:content.
Let us make the simplest thing that could possibly work now, and worry
about vague edge cases with now examples requiring "more
sophisticated" approaches later, eh?
(As an aside, the collection "example" is not one. The collection
itself, and not the records it contains, is what would be RESTfully
passed back for a collection GET. Otherwise, how would you page
through the collection?)
Ross Singer
> No, no, no. It's not an Atom extension.
Yes, yes, yes. It is! We're introducing a foreign element to an Atom feed!
>
> If we use mediatypes for atom:content we are also "extending" the Atom
> protocol by the types we'll introduce.
>
We aren't in the slightest! See:
http://atomenabled.org/developers/syndication/#contentElement
To quote:
"<content> either contains, or links to, the complete content of the entry.
In the most common case, the type attribute is either text, html,
xhtml, in which case the content element is defined identically to
other text constructs, which are described here.
Otherwise, if the src attribute is present, it represents the URI of
where the content can be found. The type attribute, if present, is the
media type of the content.
Otherwise, if the type attribute ends in +xml or /xml, then an xml
document of this type is contained inline.
Otherwise, if the type attribute starts with text, then an escaped
document of this type is contained inline.
Otherwise, a base64 encoded document of the indicated media type is
contained inline."
This is, in fact, exactly how atom was designed to be used, even if
99% of all implementations (thanks blogosphere!) only use text/html.
> I grant that option b) is closed to whatever "vanilla" may mean, but
> this potential advantage may be wiped out by the inability to extend
> and combine.
>
I'm not sure I buy this. What "extender and combinatorial service"
would overwrite what is already existing in an atom:content tag?
Wouldn't it first have to assume that it's carrying a non-semantic
blob of HTML first?
Isn't it recommended that every Atom feed have a content tag?
What service or mashup is this that clobbers data in an existing XML
document? It seems if it's extending or augmenting my feed, I feel
like will most like add a namespaced child element to my entry or
feed.
-Ross.
Godmar Back
first inkling, too), but let's not hardwire it and keep the code
modular so we can switch away should we change our mind or realize
we've designed ourselves into a corner.
Let's not invest too much into defining mime types (e.g., the
type="application/xml;whatever") to describe the content carried in
the content element, either, as none of this is likely going to be
standardized (unlike the XML namespaces defining, say, ILS-DI
records).
I note that even though Microsoft decided to carry data in the content
element, no APP framework we've looked at so far seems to provide any
sophisticated way of associated mime-types inside a content element
with custom data types. (*)
So, can we leave this as a loosely-bound variable?
- Godmar
(*) Another datapoint: Apache's Abdera Java library [1].
The interface to access foreign XML [3] and the interface to access an
XML content child [2] are again almost identical. No case here that
Atom processors would treat vanilla Atom without foreign XML namespace
significantly different or somehow more straightforward or convenient.
[1] http://incubator.apache.org/abdera/docs/api/index.html
[2] http://incubator.apache.org/abdera/docs/api/org/apache/abdera/model/Content.html#getValueElement()
[3] http://incubator.apache.org/abdera/docs/api/org/apache/abdera/model/ExtensibleElement.html#getExtension(javax.xml.namespace.QName)
Ross Singer
application/xml can be nearly anything). This is why I wanted to
define a SKOS vocabulary to provide identifiers for data types.
OAI-PMH relies on namespace and schema location to disambiguate
metadata formats, but this has its own issues, such as requiring some
mechanism to announce the namespace and schema and that it's got no
capacity to deal with non-xml datatypes.
Like I mentioned to Peter, I don't think the functionality changes
either way we implement this. I wouldn't feel the spec is wildly off
track if we implement an extension. It just wouldn't cater to lazy
developers (and I'm looking in the mirror as I type that) quite as
much.
-Ross.
On 7/14/08, Godmar Back <god...@gmail.com> wrote:
>