From lists at hubmed.org Wed Mar 1 00:04:17 2006 From: lists at hubmed.org (Alf Eaton) Date: Wed Mar 1 00:07:34 2006 Subject: [gcs-pcs-list] on using URIs In-Reply-To: <1edaf10337ff1de9cd3c6a0f27f5b57a@library.gatech.edu> References: <20060301011736.GB6692@sildin.med.yale.edu> <20060301035708.GC6692@sildin.med.yale.edu> <1edaf10337ff1de9cd3c6a0f27f5b57a@library.gatech.edu> Message-ID: On 28 Feb 2006, at 23:18, Ross Singer wrote: > I don't understand how URIs would work on something like a blog > posting, honestly. > > Can you elaborate on that? All my weblog posts have tag: URIs, it's what's recommended for Atom: . All my weblog posts also have permalinks, so the http: URL for each post could also be used as the URI. alf. From lists at hubmed.org Wed Mar 1 00:24:58 2006 From: lists at hubmed.org (Alf Eaton) Date: Wed Mar 1 00:25:07 2006 Subject: [gcs-pcs-list] on using URIs In-Reply-To: References: <20060301011736.GB6692@sildin.med.yale.edu> <20060301035708.GC6692@sildin.med.yale.edu> <1edaf10337ff1de9cd3c6a0f27f5b57a@library.gatech.edu> Message-ID: <7CE11043-0D8A-43E9-BEEC-AE9BBBAE2075@hubmed.org> On 01 Mar 2006, at 00:04, Alf Eaton wrote: > On 28 Feb 2006, at 23:18, Ross Singer wrote: > >> I don't understand how URIs would work on something like a blog >> posting, honestly. >> >> Can you elaborate on that? > > All my weblog posts have tag: URIs, it's what's recommended for > Atom: . > > All my weblog posts also have permalinks, so the http: URL for each > post could also be used as the URI. > > alf. And while we're on the subject, two things I wanted to say... My weblog post available in HTML at is also available in RDF/XML at . As on the desktop (file:// URLs) file extensions aren't the best way of determining the format of a file's contents, the same is true of HTTP URLs. What should happen is that I could call and set the Accept headers of the request to the MIME type that I'd prefer to receive, for example "text/html" or "application/ rdf+xml". The fact that this is very rarely available is why we need unAPI. Which also makes me think... If Apple decided that file extensions and MIME types are all suboptimal ways of identifying a file's content, and used Uniform Type Identifiers instead , maybe UTIs are something we could use for unAPI? It is after all how OS X determines the types of data that can be passed through its copy-paste manager. alf. From azaroth at liverpool.ac.uk Wed Mar 1 07:00:33 2006 From: azaroth at liverpool.ac.uk (Robert Sanderson) Date: Wed Mar 1 07:03:51 2006 Subject: [gcs-pcs-list] on using URIs In-Reply-To: <20060301011736.GB6692@sildin.med.yale.edu> References: <20060301011736.GB6692@sildin.med.yale.edu> Message-ID: On Tue, 28 Feb 2006, Daniel Chudnov wrote: >The case for URIs includes: > - they refer to the same thing across applications Which is great, but not interesting for unapi surely where the use case is 'I want this that I see now' not 'I want the thing identified by X' > - they imply some measure of identifier persistence Which is a disadvantage because it means that dynamic content which is not persistent is less appropriate for unapi. If the use case is 'I want what I see now' (copy), not 'I want to refer back to this in the future' (citation), then this means that we're adding hindrances. > - where objects might be copied around using unAPI there is probably > already some sort of implication of object+id persistence Why? >Fwiw, we're getting to the point where we should be weighing decisions >more and more w/r/to implemented code. So, from the point of view of >the projects for which I'm using unAPI... Well, my code says that it's more complicated to put record identifier into a fake URI, and I think that Mike's code says the same thing. > - it is easy to map specific identifier patterns to specific webapps > - without the standard URI prefix patterns, it might be impossible > to efficiently assign a handler to a particular arbitrary identifier Isn't that a resolver, rather than a copy/paste format? > - having full URI patterns makes it easy to use a library like OPA > to resolve ids Which is acting as a resolver, effectively. > - using full URIs makes it more likely that different pasted-in > stuff can refer to the same thing consistently, e.g. if user1 writes > about a book in a blog, user2 saves an amazon book link, and user3 > saves an OPAC record for the book, unalog can collate all three around > the URI (as opposed to randomly differing variants on ISBNs) In the 'I want this thing I see' mode, this isn't important. As soon as you get past that, then you're reinventing openURL. > - unalog itself referring to an object by its URI allows potentially > better precision in service/content resolution, e.g. queries for > object "12345" might return wildly different things with (unlike > w/tagging) zero potential value to be derived from overlaps across > disparate objects You even use the word resolution here. I won't restate the obvious :) >Another good reason to require URIs is that bridging other protocols >(APP, OpenURL, OpenSearch/SRU) might be easier if implementers already >have fully-specified URIs. Ditto. >As for the Evergreen blog post: Mike, I'd suggest that what you want >there isn't some tag or other made-up URI for your internal record >identifier, but rather the ISBN URI (e.g. urn:isbn:123456789X) relevant >for the item in your catalog (or an ISSN, etc.), unless an item in the >catalog has no known public identifier already. Not only is ISBN not consistently available, it's also not consistently unique. > - content identifiers represent publicly-known identifiers that are > independent of system implementations. all systems dealing with > the same content item would use the same content identifier. some > examples would be ISBNs, PMIDs, flickr photo ids, blog post numbers, > etc. these are probably at least "precious" or "normal", to use > Xiaoming's formulation. But you're dealing with one system. > - package and datastream identifiers represent specific-to-an- > application identifiers that aren't necessarily public or known > outside of the system itself. maybe they are, maybe they aren't. > some examples would be unalog entry ids, flickr image file URLs, > repository bitstream uuids, etc. >imho unAPI is all about content identifiers. Or, rather, you could use >the other kinds of identifiers with it, but if it really takes off as >an cross-application spec, it will be through the common use of content >identifiers, most of which can be usefully rendered as URIs. Then my claim (and Jeff's claim, I think) is that you're reinventing OpenURL. Rob From ross.singer at library.gatech.edu Wed Mar 1 07:48:02 2006 From: ross.singer at library.gatech.edu (Ross Singer) Date: Wed Mar 1 07:50:21 2006 Subject: [gcs-pcs-list] on using URIs In-Reply-To: References: <20060301011736.GB6692@sildin.med.yale.edu> Message-ID: There's something else to note here... In the Evergreen scenario, the suggestion is to use ISxN or some other standard identifier rather than local identifier, but, frankly, this is much more complicated on, say, /my/ opac. So, are tag uris to be discouraged? Is it functionally any different than just using a local identifier? Also, I'm still not sure I'm buying Evergreen using urn:isbn:123456789X in this case. It's /not/ referring to 123456789X, it's (possibly) referring to 123456789X /or something sort of like it/. urn:isbn:123456789X seems pretty explicit. /Maybe/ I am just looking for the title/author, but maybe I'm looking for publisher city or date. ISBN concordance is /bad/ in this case. It's early, though, it's probable that I read that wrong. Anyway, I need some clarity on the tag v. info uri v. url issue... Basically, I don't want to waste my time w/r/t code either over-analyzing the problem or undoing 'under-analyzing' it. -Ross. On Mar 1, 2006, at 7:00 AM, Robert Sanderson wrote: > > On Tue, 28 Feb 2006, Daniel Chudnov wrote: >> The case for URIs includes: > >> - they refer to the same thing across applications > > Which is great, but not interesting for unapi surely where the use case > is 'I want this that I see now' not 'I want the thing identified by X' > >> - they imply some measure of identifier persistence > > Which is a disadvantage because it means that dynamic content which is > not persistent is less appropriate for unapi. If the use case is 'I > want what I see now' (copy), not 'I want to refer back to this in the > future' (citation), then this means that we're adding hindrances. > >> - where objects might be copied around using unAPI there is probably >> already some sort of implication of object+id persistence > > Why? > >> Fwiw, we're getting to the point where we should be weighing decisions >> more and more w/r/to implemented code. So, from the point of view of >> the projects for which I'm using unAPI... > > Well, my code says that it's more complicated to put record identifier > into a fake URI, and I think that Mike's code says the same thing. > > >> - it is easy to map specific identifier patterns to specific webapps >> - without the standard URI prefix patterns, it might be impossible >> to efficiently assign a handler to a particular arbitrary identifier > > Isn't that a resolver, rather than a copy/paste format? > >> - having full URI patterns makes it easy to use a library like OPA >> to resolve ids > Which is acting as a resolver, effectively. > >> - using full URIs makes it more likely that different pasted-in >> stuff can refer to the same thing consistently, e.g. if user1 writes >> about a book in a blog, user2 saves an amazon book link, and user3 >> saves an OPAC record for the book, unalog can collate all three >> around >> the URI (as opposed to randomly differing variants on ISBNs) > > In the 'I want this thing I see' mode, this isn't important. As soon > as > you get past that, then you're reinventing openURL. > >> - unalog itself referring to an object by its URI allows potentially >> better precision in service/content resolution, e.g. queries for >> object "12345" might return wildly different things with (unlike >> w/tagging) zero potential value to be derived from overlaps across >> disparate objects > > You even use the word resolution here. I won't restate the obvious :) > >> Another good reason to require URIs is that bridging other protocols >> (APP, OpenURL, OpenSearch/SRU) might be easier if implementers already >> have fully-specified URIs. > > Ditto. > >> As for the Evergreen blog post: Mike, I'd suggest that what you want >> there isn't some tag or other made-up URI for your internal record >> identifier, but rather the ISBN URI (e.g. urn:isbn:123456789X) >> relevant >> for the item in your catalog (or an ISSN, etc.), unless an item in the >> catalog has no known public identifier already. > > Not only is ISBN not consistently available, it's also not consistently > unique. > >> - content identifiers represent publicly-known identifiers that are >> independent of system implementations. all systems dealing with >> the same content item would use the same content identifier. some >> examples would be ISBNs, PMIDs, flickr photo ids, blog post numbers, >> etc. these are probably at least "precious" or "normal", to use >> Xiaoming's formulation. > > But you're dealing with one system. > >> - package and datastream identifiers represent specific-to-an- >> application identifiers that aren't necessarily public or known >> outside of the system itself. maybe they are, maybe they aren't. >> some examples would be unalog entry ids, flickr image file URLs, >> repository bitstream uuids, etc. > >> imho unAPI is all about content identifiers. Or, rather, you could >> use >> the other kinds of identifiers with it, but if it really takes off as >> an cross-application spec, it will be through the common use of >> content >> identifiers, most of which can be usefully rendered as URIs. > > Then my claim (and Jeff's claim, I think) is that you're reinventing > OpenURL. > > Rob > _______________________________________________ > gcs-pcs-list mailing list > gcs-pcs-list@cipolo.med.yale.edu > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list > From ross.singer at library.gatech.edu Wed Mar 1 08:00:39 2006 From: ross.singer at library.gatech.edu (Ross Singer) Date: Wed Mar 1 08:01:46 2006 Subject: [gcs-pcs-list] on using URIs In-Reply-To: References: <20060301011736.GB6692@sildin.med.yale.edu> Message-ID: One more thing... couldn't the standard identifier be gleaned from the unAPIed data? Also, I remembered how my boss pronounced it: You-un-appy. -Ross. On Mar 1, 2006, at 7:48 AM, Ross Singer wrote: > There's something else to note here... In the Evergreen scenario, the > suggestion is to use ISxN or some other standard identifier rather > than local identifier, but, frankly, this is much more complicated on, > say, /my/ opac. > > So, are tag uris to be discouraged? Is it functionally any different > than just using a local identifier? > > Also, I'm still not sure I'm buying Evergreen using > urn:isbn:123456789X in this case. It's /not/ referring to 123456789X, > it's (possibly) referring to 123456789X /or something sort of like > it/. urn:isbn:123456789X seems pretty explicit. /Maybe/ I am just > looking for the title/author, but maybe I'm looking for publisher city > or date. ISBN concordance is /bad/ in this case. > > It's early, though, it's probable that I read that wrong. > > Anyway, I need some clarity on the tag v. info uri v. url issue... > Basically, I don't want to waste my time w/r/t code either > over-analyzing the problem or undoing 'under-analyzing' it. > > -Ross. > > On Mar 1, 2006, at 7:00 AM, Robert Sanderson wrote: > >> >> On Tue, 28 Feb 2006, Daniel Chudnov wrote: >>> The case for URIs includes: >> >>> - they refer to the same thing across applications >> >> Which is great, but not interesting for unapi surely where the use >> case >> is 'I want this that I see now' not 'I want the thing identified by X' >> >>> - they imply some measure of identifier persistence >> >> Which is a disadvantage because it means that dynamic content which is >> not persistent is less appropriate for unapi. If the use case is 'I >> want what I see now' (copy), not 'I want to refer back to this in the >> future' (citation), then this means that we're adding hindrances. >> >>> - where objects might be copied around using unAPI there is probably >>> already some sort of implication of object+id persistence >> >> Why? >> >>> Fwiw, we're getting to the point where we should be weighing >>> decisions >>> more and more w/r/to implemented code. So, from the point of view of >>> the projects for which I'm using unAPI... >> >> Well, my code says that it's more complicated to put record identifier >> into a fake URI, and I think that Mike's code says the same thing. >> >> >>> - it is easy to map specific identifier patterns to specific webapps >>> - without the standard URI prefix patterns, it might be impossible >>> to efficiently assign a handler to a particular arbitrary >>> identifier >> >> Isn't that a resolver, rather than a copy/paste format? >> >>> - having full URI patterns makes it easy to use a library like OPA >>> to resolve ids >> Which is acting as a resolver, effectively. >> >>> - using full URIs makes it more likely that different pasted-in >>> stuff can refer to the same thing consistently, e.g. if user1 >>> writes >>> about a book in a blog, user2 saves an amazon book link, and user3 >>> saves an OPAC record for the book, unalog can collate all three >>> around >>> the URI (as opposed to randomly differing variants on ISBNs) >> >> In the 'I want this thing I see' mode, this isn't important. As soon >> as >> you get past that, then you're reinventing openURL. >> >>> - unalog itself referring to an object by its URI allows potentially >>> better precision in service/content resolution, e.g. queries for >>> object "12345" might return wildly different things with (unlike >>> w/tagging) zero potential value to be derived from overlaps across >>> disparate objects >> >> You even use the word resolution here. I won't restate the obvious :) >> >>> Another good reason to require URIs is that bridging other protocols >>> (APP, OpenURL, OpenSearch/SRU) might be easier if implementers >>> already >>> have fully-specified URIs. >> >> Ditto. >> >>> As for the Evergreen blog post: Mike, I'd suggest that what you want >>> there isn't some tag or other made-up URI for your internal record >>> identifier, but rather the ISBN URI (e.g. urn:isbn:123456789X) >>> relevant >>> for the item in your catalog (or an ISSN, etc.), unless an item in >>> the >>> catalog has no known public identifier already. >> >> Not only is ISBN not consistently available, it's also not >> consistently >> unique. >> >>> - content identifiers represent publicly-known identifiers that are >>> independent of system implementations. all systems dealing with >>> the same content item would use the same content identifier. some >>> examples would be ISBNs, PMIDs, flickr photo ids, blog post >>> numbers, >>> etc. these are probably at least "precious" or "normal", to use >>> Xiaoming's formulation. >> >> But you're dealing with one system. >> >>> - package and datastream identifiers represent specific-to-an- >>> application identifiers that aren't necessarily public or known >>> outside of the system itself. maybe they are, maybe they aren't. >>> some examples would be unalog entry ids, flickr image file URLs, >>> repository bitstream uuids, etc. >> >>> imho unAPI is all about content identifiers. Or, rather, you could >>> use >>> the other kinds of identifiers with it, but if it really takes off as >>> an cross-application spec, it will be through the common use of >>> content >>> identifiers, most of which can be usefully rendered as URIs. >> >> Then my claim (and Jeff's claim, I think) is that you're reinventing >> OpenURL. >> >> Rob >> _______________________________________________ >> gcs-pcs-list mailing list >> gcs-pcs-list@cipolo.med.yale.edu >> http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list >> > > _______________________________________________ > gcs-pcs-list mailing list > gcs-pcs-list@cipolo.med.yale.edu > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list > From ehs at pobox.com Wed Mar 1 08:31:12 2006 From: ehs at pobox.com (Edward Summers) Date: Wed Mar 1 08:31:49 2006 Subject: [gcs-pcs-list] app was: on using URIs In-Reply-To: <7CE11043-0D8A-43E9-BEEC-AE9BBBAE2075@hubmed.org> References: <20060301011736.GB6692@sildin.med.yale.edu> <20060301035708.GC6692@sildin.med.yale.edu> <1edaf10337ff1de9cd3c6a0f27f5b57a@library.gatech.edu> <7CE11043-0D8A-43E9-BEEC-AE9BBBAE2075@hubmed.org> Message-ID: On Feb 28, 2006, at 11:24 PM, Alf Eaton wrote: > My weblog post available in HTML at archives/001314.html> is also available in RDF/XML at hublog.hubmed.org/archives/001314.rdf>. That's a neat hack, it almost seems like a prelude to APP support. /me stirs the cauldron... I know that you all have considered the Atom Publishing Protocol as possible alternative, as have I. One sticking point for me was that it wasn't clear how APP could deliver up different flavors of a particular resource (json/mods/dc/etc). I happened to mention this in #code4lib and Brian Cassidy suggested that it could be as simple as including elements in an Atom entry: Combined with hAtom [1] (which allows you to express atom in html, and was just blessed by tantek^wthe microformats people) I think that all the pieces are there for full on copy/paste. But as Dan says, working code wins...so until I have time to mock up an example this is simply a vapor-idea :-) //Ed [1] http://microformats.org/wiki/hatom From jyoung at oclc.org Wed Mar 1 09:03:15 2006 From: jyoung at oclc.org (Young,Jeff (OR)) Date: Wed Mar 1 09:03:50 2006 Subject: [gcs-pcs-list] on using URIs Message-ID: > Then my claim (and Jeff's claim, I think) is that you're reinventing > OpenURL. I agree. The intention that someone might take a unAPI identifier and apply it outside the context of the corresponding meta link or vice versa crossed the line, IMO. It also strikes me that unAPI could easily be defined in terms of COinS in conjunction with a meta link pointing at an OpenURL resolver. Using this approach, a server could describe the referent any way it sees fit. Given these considerations, it seems clear to me that the current mechanism does ultimately constitute a flavor of OpenURL Lite. Jeff From jeremy.frumkin at oregonstate.edu Wed Mar 1 10:18:06 2006 From: jeremy.frumkin at oregonstate.edu (Jeremy Frumkin) Date: Wed Mar 1 10:18:42 2006 Subject: [gcs-pcs-list] on using URIs In-Reply-To: Message-ID: I believe Rob hits on an important base decision point for unAPI: Should the idea of identifier-to-resource persistence be accommodated in the spec? If so, I don?t think the current spec accomplishes that, because resources may change over time, even if their identifiers remain the same. I was of the mindset that unAPI accomplished a copy-by-value function, not a copy-by-reference, but maybe I?m wrong about the intent. If we are looking at a copy-by-reference, then the spec needs to include a more complicated identifier scheme, and I think that?s opening up a can of worms. That being said, there may be overlaying applications, which, used on top of unAPI, provide additional functions, such as identifier-to-resource persistence. If we look at how unAPI might be extended through the additional layering of applications, as opposed to extending the spec itself, we can keep it simple and clean. -- jaf On 3/1/06 4:00 AM, "Robert Sanderson" wrote: > > > On Tue, 28 Feb 2006, Daniel Chudnov wrote: >> >The case for URIs includes: > >> > - they refer to the same thing across applications > > Which is great, but not interesting for unapi surely where the use case > is 'I want this that I see now' not 'I want the thing identified by X' > >> > - they imply some measure of identifier persistence > > Which is a disadvantage because it means that dynamic content which is > not persistent is less appropriate for unapi. If the use case is 'I > want what I see now' (copy), not 'I want to refer back to this in the > future' (citation), then this means that we're adding hindrances. > >> > - where objects might be copied around using unAPI there is probably >> > already some sort of implication of object+id persistence > > Why? > >> >Fwiw, we're getting to the point where we should be weighing decisions >> >more and more w/r/to implemented code. So, from the point of view of >> >the projects for which I'm using unAPI... > > Well, my code says that it's more complicated to put record identifier > into a fake URI, and I think that Mike's code says the same thing. > > >> > - it is easy to map specific identifier patterns to specific webapps >> > - without the standard URI prefix patterns, it might be impossible >> > to efficiently assign a handler to a particular arbitrary identifier > > Isn't that a resolver, rather than a copy/paste format? > >> > - having full URI patterns makes it easy to use a library like OPA >> > to resolve ids > Which is acting as a resolver, effectively. > >> > - using full URIs makes it more likely that different pasted-in >> > stuff can refer to the same thing consistently, e.g. if user1 writes >> > about a book in a blog, user2 saves an amazon book link, and user3 >> > saves an OPAC record for the book, unalog can collate all three around >> > the URI (as opposed to randomly differing variants on ISBNs) > > In the 'I want this thing I see' mode, this isn't important. As soon as > you get past that, then you're reinventing openURL. > >> > - unalog itself referring to an object by its URI allows potentially >> > better precision in service/content resolution, e.g. queries for >> > object "12345" might return wildly different things with (unlike >> > w/tagging) zero potential value to be derived from overlaps across >> > disparate objects > > You even use the word resolution here. I won't restate the obvious :) > >> >Another good reason to require URIs is that bridging other protocols >> >(APP, OpenURL, OpenSearch/SRU) might be easier if implementers already >> >have fully-specified URIs. > > Ditto. > >> >As for the Evergreen blog post: Mike, I'd suggest that what you want >> >there isn't some tag or other made-up URI for your internal record >> >identifier, but rather the ISBN URI (e.g. urn:isbn:123456789X) relevant >> >for the item in your catalog (or an ISSN, etc.), unless an item in the >> >catalog has no known public identifier already. > > Not only is ISBN not consistently available, it's also not consistently > unique. > >> > - content identifiers represent publicly-known identifiers that are >> > independent of system implementations. all systems dealing with >> > the same content item would use the same content identifier. some >> > examples would be ISBNs, PMIDs, flickr photo ids, blog post numbers, >> > etc. these are probably at least "precious" or "normal", to use >> > Xiaoming's formulation. > > But you're dealing with one system. > >> > - package and datastream identifiers represent specific-to-an- >> > application identifiers that aren't necessarily public or known >> > outside of the system itself. maybe they are, maybe they aren't. >> > some examples would be unalog entry ids, flickr image file URLs, >> > repository bitstream uuids, etc. > >> >imho unAPI is all about content identifiers. Or, rather, you could use >> >the other kinds of identifiers with it, but if it really takes off as >> >an cross-application spec, it will be through the common use of content >> >identifiers, most of which can be usefully rendered as URIs. > > Then my claim (and Jeff's claim, I think) is that you're reinventing > OpenURL. > > Rob > _______________________________________________ > gcs-pcs-list mailing list > gcs-pcs-list@cipolo.med.yale.edu > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list > -- jaf =============================================== Jeremy Frumkin The Gray Chair for Innovative Library Services 121 The Valley Library, Oregon State University Corvallis OR 97331-4501 Jeremy.Frumkin@oregonstate.edu 541.737.9928 541.737.3453 (Fax) 541.230.4483 (Cell) =============================================== " Without ambition one starts nothing. Without work one finishes nothing. " - Emerson -------------- next part -------------- An HTML attachment was scrubbed... URL: http://cipolo.med.yale.edu/pipermail/gcs-pcs-list/attachments/20060301/c5329d1b/attachment.htm From mrylander at gmail.com Wed Mar 1 10:44:11 2006 From: mrylander at gmail.com (Mike Rylander) Date: Wed Mar 1 10:45:17 2006 Subject: [gcs-pcs-list] on using URIs In-Reply-To: References: <20060301011736.GB6692@sildin.med.yale.edu> Message-ID: On 3/1/06, Robert Sanderson wrote: > > On Tue, 28 Feb 2006, Daniel Chudnov wrote: > >The case for URIs includes: > > > - they refer to the same thing across applications > > Which is great, but not interesting for unapi surely where the use case > is 'I want this that I see now' not 'I want the thing identified by X' > > > - they imply some measure of identifier persistence > > Which is a disadvantage because it means that dynamic content which is > not persistent is less appropriate for unapi. If the use case is 'I > want what I see now' (copy), not 'I want to refer back to this in the > future' (citation), then this means that we're adding hindrances. Well, they don't have to though. If Alf's blog posts use day granular tag URIs, then the persistence is valid for that one day. If my catalog uses year granular tags then I should do my best to make sure that the records are available for the entire year (or use a more granular time specifier). To put it another way, the time specifier defines the "horizontal (temporal) persistence", the sub-URI at the end defines the "vertical (cross-app) persistence", and as an added bonus, the "authority identifier" can tell us where to go looking for an unapi server It seems like tags allow the structure of URIs, require (at least a hint for finding) the original unAPI server, a time range for encoding the "persistence" of URIs and the ability to use things like "urn:isbn:...." at the end, for purposes that Dan is advocating (core to the original unAPI idea or not) but without implying that the identifier is valid elsewhere. Before, I stated that I wouldn't try to push any particular scheme as long as I can use whatever I like without breaking spec. Now, I think I will start pushing for tag URIs... :) > > > - where objects might be copied around using unAPI there is probably > > already some sort of implication of object+id persistence > > Why? > > >Fwiw, we're getting to the point where we should be weighing decisions > >more and more w/r/to implemented code. So, from the point of view of > >the projects for which I'm using unAPI... > > Well, my code says that it's more complicated to put record identifier > into a fake URI, and I think that Mike's code says the same thing. I don't think my code says that. I found it no more difficult to create a fake info URI than to not, and I'd need to use a URI in any case. Our metarecords (interesting or not) will be unAPIed, and I'll need to pass the type (record vs. metarecord) as well as the numeric ID. AFAICS, tag URIs aren't "fake" ... but I assume that's not your point. I think your point is that requiring URIs is "harder" than not, but I'm not sure I buy that ... print "tag:$host:$year-$month:urn:$type:$id"; instead of print $id; I'm all for URI, but I'm for it because they are easy to parse and recognise. I don't think they should imply any more utility, though, than pointing to a resource that the accompanying can help you retrieve. > > > > - it is easy to map specific identifier patterns to specific webapps > > - without the standard URI prefix patterns, it might be impossible > > to efficiently assign a handler to a particular arbitrary identifier > > Isn't that a resolver, rather than a copy/paste format? > > > - having full URI patterns makes it easy to use a library like OPA > > to resolve ids > Which is acting as a resolver, effectively. > > > - using full URIs makes it more likely that different pasted-in > > stuff can refer to the same thing consistently, e.g. if user1 writes > > about a book in a blog, user2 saves an amazon book link, and user3 > > saves an OPAC record for the book, unalog can collate all three around > > the URI (as opposed to randomly differing variants on ISBNs) > > In the 'I want this thing I see' mode, this isn't important. As soon as > you get past that, then you're reinventing openURL. > > > - unalog itself referring to an object by its URI allows potentially > > better precision in service/content resolution, e.g. queries for > > object "12345" might return wildly different things with (unlike > > w/tagging) zero potential value to be derived from overlaps across > > disparate objects > > You even use the word resolution here. I won't restate the obvious :) > > >Another good reason to require URIs is that bridging other protocols > >(APP, OpenURL, OpenSearch/SRU) might be easier if implementers already > >have fully-specified URIs. > > Ditto. > > >As for the Evergreen blog post: Mike, I'd suggest that what you want > >there isn't some tag or other made-up URI for your internal record > >identifier, but rather the ISBN URI (e.g. urn:isbn:123456789X) relevant > >for the item in your catalog (or an ISSN, etc.), unless an item in the > >catalog has no known public identifier already. > > Not only is ISBN not consistently available, it's also not consistently > unique. > > > - content identifiers represent publicly-known identifiers that are > > independent of system implementations. all systems dealing with > > the same content item would use the same content identifier. some > > examples would be ISBNs, PMIDs, flickr photo ids, blog post numbers, > > etc. these are probably at least "precious" or "normal", to use > > Xiaoming's formulation. > > But you're dealing with one system. > > > - package and datastream identifiers represent specific-to-an- > > application identifiers that aren't necessarily public or known > > outside of the system itself. maybe they are, maybe they aren't. > > some examples would be unalog entry ids, flickr image file URLs, > > repository bitstream uuids, etc. > > >imho unAPI is all about content identifiers. Or, rather, you could use > >the other kinds of identifiers with it, but if it really takes off as > >an cross-application spec, it will be through the common use of content > >identifiers, most of which can be usefully rendered as URIs. > > Then my claim (and Jeff's claim, I think) is that you're reinventing > OpenURL. > > Rob > _______________________________________________ > gcs-pcs-list mailing list > gcs-pcs-list@cipolo.med.yale.edu > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list > -- Mike Rylander mrylander@gmail.com GPLS -- PINES Development Database Developer http://open-ils.org From jyoung at oclc.org Wed Mar 1 10:55:50 2006 From: jyoung at oclc.org (Young,Jeff (OR)) Date: Wed Mar 1 10:56:18 2006 Subject: [gcs-pcs-list] on using URIs Message-ID: Sorry to follow up on my own post, but I want to add something. > It also strikes me that unAPI could easily be defined in terms of COinS > in conjunction with a meta link pointing at an OpenURL resolver. Using > this approach, a server could describe the referent any way it sees fit. I don't think my suggestion that unAPI could be implemented with COinS and an OpenURL resolver implies an unreasonably high barrier for implementers. The resolver wouldn't have to implement the complete protocol, only enough to handle the COinS the server generates for itself. These can be as simple or complex as the situation calls for. Jeff From yee at berkeley.edu Wed Mar 1 11:01:33 2006 From: yee at berkeley.edu (Raymond Yee) Date: Wed Mar 1 11:04:52 2006 Subject: [gcs-pcs-list] on using URIs In-Reply-To: References: Message-ID: <4405C55D.7050501@berkeley.edu> Hi Jeff, Having to implement an OpenURL resolver, even a simple one, just sounds lot of work to me, even if it isn't. What's the minimum requirement to be an OpenURL resolver? Is there code in various languages that shows such a minimum implementation? -Raymond Young,Jeff (OR) wrote: > I don't think my suggestion that unAPI could be implemented with COinS > and an OpenURL resolver implies an unreasonably high barrier for > implementers. The resolver wouldn't have to implement the complete > protocol, only enough to handle the COinS the server generates for > itself. These can be as simple or complex as the situation calls for. > > Jeff > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3166 bytes Desc: S/MIME Cryptographic Signature Url : http://cipolo.med.yale.edu/pipermail/gcs-pcs-list/attachments/20060301/6cc4fe80/smime.bin From jyoung at oclc.org Wed Mar 1 11:10:56 2006 From: jyoung at oclc.org (Young,Jeff (OR)) Date: Wed Mar 1 11:11:23 2006 Subject: [gcs-pcs-list] on using URIs Message-ID: Here is a current unAPI request: identifier= info%3Adoi%2F10.1126%2Fscience.275.5304.1320 Here is the equivalent request in OpenURL: url_ver=Z39.88-2004&rft_id=info%3Adoi%2F10.1126%2Fscience.275.5304.1320 If an existing unAPI resolver ignored the url_ver and used "rft_id" in place of "identifier", it would instantly be OpenURL 1.0 compliant. Jeff > -----Original Message----- > From: Raymond Yee [mailto:yee@berkeley.edu] > Sent: Wednesday, March 01, 2006 11:02 AM > To: Young,Jeff (OR) > Cc: Robert Sanderson; gcs-pcs-list@cipolo.med.yale.edu > Subject: Re: [gcs-pcs-list] on using URIs > > Hi Jeff, > > Having to implement an OpenURL resolver, even a simple one, just sounds > lot of work to me, even if it isn't. What's the minimum requirement > to be an OpenURL resolver? Is there code in various languages that > shows such a minimum implementation? > > -Raymond > > Young,Jeff (OR) wrote: > > I don't think my suggestion that unAPI could be implemented with COinS > > and an OpenURL resolver implies an unreasonably high barrier for > > implementers. The resolver wouldn't have to implement the complete > > protocol, only enough to handle the COinS the server generates for > > itself. These can be as simple or complex as the situation calls for. > > > > Jeff > > From ross.singer at library.gatech.edu Wed Mar 1 11:12:15 2006 From: ross.singer at library.gatech.edu (Ross Singer) Date: Wed Mar 1 11:13:19 2006 Subject: [gcs-pcs-list] on using URIs In-Reply-To: <4405C55D.7050501@berkeley.edu> References: <4405C55D.7050501@berkeley.edu> Message-ID: <5e3359fcc211eeb316925d0710bf351f@library.gatech.edu> I see somebody didn't attend the openurl library breakout in corvallis... -Ross. On Mar 1, 2006, at 11:01 AM, Raymond Yee wrote: > Hi Jeff, > > Having to implement an OpenURL resolver, even a simple one, just > sounds lot of work to me, even if it isn't. What's the minimum > requirement to be an OpenURL resolver? Is there code in various > languages that shows such a minimum implementation? > > -Raymond > > Young,Jeff (OR) wrote: >> I don't think my suggestion that unAPI could be implemented with COinS >> and an OpenURL resolver implies an unreasonably high barrier for >> implementers. The resolver wouldn't have to implement the complete >> protocol, only enough to handle the COinS the server generates for >> itself. These can be as simple or complex as the situation calls for. >> >> Jeff >> > > _______________________________________________ > gcs-pcs-list mailing list > gcs-pcs-list@cipolo.med.yale.edu > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list From eric at openly.com Wed Mar 1 11:36:07 2006 From: eric at openly.com (Eric Hellman) Date: Wed Mar 1 11:39:53 2006 Subject: [gcs-pcs-list] on using URIs In-Reply-To: <4405C55D.7050501@berkeley.edu> References: <4405C55D.7050501@berkeley.edu> Message-ID: At 8:01 AM -0800 3/1/06, Raymond Yee wrote: >Hi Jeff, > >Having to implement an OpenURL resolver, even a simple one, just >sounds lot of work to me, even if it isn't. What's the minimum >requirement to be an OpenURL resolver? Is there code in various >languages that shows such a minimum implementation? > >-Raymond Some people have complained about this, but there is no minimum requirement to be an OpenURL resolver, except possibly that an OpenURL resolver should not report a horrible error when sent a valid OpenURL. For example, it seems your website is an openURL "resolver", albeit not a useful one. http://iu.berkeley.edu/rdhyee/?url_ver=Z39.88-2004&rft_id=info%3Adoi%2F10.1126%2Fscience.275.5304.1320 Profiles are another story. Eric -- Eric Hellman, Director OCLC Openly Informatics Division eric@openly.com 2 Broad St., Suite 208 tel 1-973-509-7800 fax 1-734-468-6216 Bloomfield, NJ 07003 http://www.openly.com/1cate/ 1 Click Access To Everything From daniel.chudnov at yale.edu Wed Mar 1 11:51:11 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Wed Mar 1 11:52:17 2006 Subject: [gcs-pcs-list] on using URIs In-Reply-To: References: <20060301011736.GB6692@sildin.med.yale.edu> <20060301035708.GC6692@sildin.med.yale.edu> Message-ID: <3A190275-3417-449D-B98A-E49002CD3B8E@yale.edu> On Feb 28, 2006, at 11:56 PM, Mike Rylander wrote: > > IOW, two servers serve the URI "urn:isbn:123456789X"; do we assume > that they point to the same item or serve the same content (assuming > overlap in formats)? (Perhaps ISBN is the wrong identify to use in > examples, what with its know issues regarding reuse ...) Personally, I wouldn't assume anything. Users do crazy things, and we shouldn't try to stop them... indeed we want to help them! :) >> If it matters, I'm not assuming anything about content itself. I'm >> format-agnostic, and don't believe we can impose any "truth" of >> what an >> "original" or "correct" format for an object is. That's a hard >> enough >> problem without trying to address it in unAPI. We just want to be >> able >> to know if people are talking about the same thing (w/r/to >> identifiers). > > Sure. Which means that users /should/ use the original unAPI server > to retrieve objects, even if they've seen the same "thing" elsewhere, > perhaps even in the same format. I would go as far as to write that > explicitly into the unAPI spec (using standard RFC "SHOULD" or even > "MUST" language). Ach, I meant exactly the opposite. I can get the "green o'reilly javascript book" off my bookshelf. Or my neighbor's bookshelf. Or online with safari. Or at the bookstore down the road. Or from amazon or powell's or quantum. It's up to me to judge whether I really need the newer edition or not, and whether the manifestation in my hand is sufficient, right? Same for articles. You can openurl-resolve to a suite of online sites. You can copy it from print. You can get a scanned pdf via your ILL office. You can read it from your course reserve readings page. You can get a copy from a friend. None of those varied scenarios say anything about the "original" source of the materials. I don't think we have any chance to improve on that way things work, so I wouldn't want to spec to attempt to change behavior. Content's a tramp, and nobody will only use our own, single systems. unAPI should simply help make movement of information across applications slightly more robust, and it's still up to users to decide whether what they have in front of them is sufficient. > If the content (value, not structure) of the URI is important (i.e., > the spec says "try to use 'urn:isbn:123456789x' instead of > 'tag:gapines.org:2006:record/12345'"), then why would someone with a > Amazon greasemonkey script use the site-local unAPI server instead of > the, arguably more prevalent/complete/well-know, Amazon webservice > copy of the object? For one thing: what one server has for an identifier might be more relevant for some specific use context than another. For another: why not use both? I've been thinking about adding LC SRU results for urn:isbn:* queries to OPA to see what it would be like to have those side-by-side with amazon results. -Dan From daniel.chudnov at yale.edu Wed Mar 1 11:56:12 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Wed Mar 1 11:57:25 2006 Subject: [gcs-pcs-list] on using URIs In-Reply-To: <7CE11043-0D8A-43E9-BEEC-AE9BBBAE2075@hubmed.org> References: <20060301011736.GB6692@sildin.med.yale.edu> <20060301035708.GC6692@sildin.med.yale.edu> <1edaf10337ff1de9cd3c6a0f27f5b57a@library.gatech.edu> <7CE11043-0D8A-43E9-BEEC-AE9BBBAE2075@hubmed.org> Message-ID: <3363C82B-B0CD-4849-A7A2-DEA46DA6C6F5@yale.edu> On Mar 1, 2006, at 12:24 AM, Alf Eaton wrote: > > Which also makes me think... If Apple decided that file extensions > and MIME types are all suboptimal ways of identifying a file's > content, and used Uniform Type Identifiers instead arstechnica.com/reviews/os/macosx-10.4.ars/11>, maybe UTIs are > something we could use for unAPI? It is after all how OS X > determines the types of data that can be passed through its copy- > paste manager. This is a neat idea, even if the spec isn't widely adopted. Afaict, there's nothing in unAPI as it stands to prevent people from using UTIs for format names. -dc From daniel.chudnov at yale.edu Wed Mar 1 12:05:13 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Wed Mar 1 12:06:34 2006 Subject: [gcs-pcs-list] on using URIs In-Reply-To: References: <20060301011736.GB6692@sildin.med.yale.edu> Message-ID: <8BB93D74-E51F-49D7-97A6-412610B7D215@yale.edu> Though tit-for-tat is a fine strategy in game theory, forgive me for not going fully point by point again here. :) On Mar 1, 2006, at 7:00 AM, Robert Sanderson wrote: > On Tue, 28 Feb 2006, Daniel Chudnov wrote: >> The case for URIs includes: >> - they refer to the same thing across applications > > Which is great, but not interesting for unapi surely where the use > case > is 'I want this that I see now' not 'I want the thing identified by X' I think unAPI is about asking "I want the thing identified by X". >> - they imply some measure of identifier persistence > > Which is a disadvantage because it means that dynamic content which is > not persistent is less appropriate for unapi. I think that's right. Especially in that it's not a hard-and-fast rule... it's just less appropriate. >> - without the standard URI prefix patterns, it might be impossible >> to efficiently assign a handler to a particular arbitrary >> identifier > > Isn't that a resolver, rather than a copy/paste format? Oh isn't it a little young to be assigning labels? :P If it's a resolver, it's primarily a direct content resolver, not a deferred service resolver. But does that matter? >> - using full URIs makes it more likely that different pasted-in >> stuff can refer to the same thing consistently, e.g. if user1 >> writes >> about a book in a blog, user2 saves an amazon book link, and user3 >> saves an OPAC record for the book, unalog can collate all three >> around >> the URI (as opposed to randomly differing variants on ISBNs) > > In the 'I want this thing I see' mode, this isn't important. As > soon as > you get past that, then you're reinventing openURL. Er, no, I rather like openurl as it is, thank you, though I could stand it being a little simpler. :) I think it might be a mistake for all of us to be so focused on this right now when we haven't built any apps that move data around. The issues will become much clearer after those start popping up. > Not only is ISBN not consistently available, it's also not > consistently > unique. No, it's not, and we can't solve either problem, but we can use it when it's appropriate. >> - content identifiers represent publicly-known identifiers that are >> independent of system implementations. all systems dealing with >> the same content item would use the same content identifier. some >> examples would be ISBNs, PMIDs, flickr photo ids, blog post >> numbers, >> etc. these are probably at least "precious" or "normal", to use >> Xiaoming's formulation. > > But you're dealing with one system. Um, no, I'm not. I just haven't been able to show you the other system yet. :) -Dan From daniel.chudnov at yale.edu Wed Mar 1 12:37:42 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Wed Mar 1 12:38:46 2006 Subject: [gcs-pcs-list] on using URIs In-Reply-To: References: Message-ID: <5485E707-162C-4BF2-9618-9B08A1D8E5EB@yale.edu> On Mar 1, 2006, at 9:03 AM, Young,Jeff (OR) wrote: >> Then my claim (and Jeff's claim, I think) is that you're reinventing >> OpenURL. > > I agree. The intention that someone might take a unAPI identifier and > apply it outside the context of the corresponding meta link or vice > versa crossed the line, IMO. > > It also strikes me that unAPI could easily be defined in terms of > COinS > in conjunction with a meta link pointing at an OpenURL resolver. Using > this approach, a server could describe the referent any way it sees > fit. > > Given these considerations, it seems clear to me that the current > mechanism does ultimately constitute a flavor of OpenURL Lite. Is that good? Is that bad? Does it change the usefulness of unAPI? Does it matter? Seriously, does it matter? Maybe it's worth recalling where unAPI came from: http://curtis.med.yale.edu/dchud/log/project/rogue/rogue-no.1- coins-pmh It said "use a COinS with an identifier, and redirect people to an OAI-PMH service." You didn't have to implement all of OAI-PMH to serve COinS-PMH requests. There were several problems with COinS-PMH. They can be summarized thusly: - It had a terrible name - Nobody outside of our community gets OAI-PMH or OpenURL - Barely anybody implemented it, so it died Within days of unAPI rev1 being released, we had diverse implementations from diverse sources: - in java, over OpenURL - in java, bare servlets - in php, over wordpress - in perl, over the unholy combination of sufficiently advanced technology indistinguishable from magic that is evergreen's supercat :) - in python, bare code and over disparate remote APIs and OAI-PMH That's four languages, five web frameworks, and layerings over four application frameworks which include two well-known library specifications - OAI-PMH and OpenURL. Lots of complexity averted for end-user/developers. I'm just saying. -dc From jyoung at oclc.org Wed Mar 1 12:56:00 2006 From: jyoung at oclc.org (Young,Jeff (OR)) Date: Wed Mar 1 12:56:26 2006 Subject: [gcs-pcs-list] on using URIs Message-ID: > Lots of complexity averted for end-user/developers. I'm just saying. I'm not convinced that this: url_ver=Z39.88-2004&rft_id=info%3Adoi%2F10.1126%2Fscience.275.5304.1320 is significantly more difficult to process than this: uri=info%3Adoi%2F10.1126%2Fscience.275.5304.1320 Jeff From daniel.chudnov at yale.edu Wed Mar 1 13:20:03 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Wed Mar 1 13:21:08 2006 Subject: [gcs-pcs-list] on using URIs In-Reply-To: References: Message-ID: <17543AED-4EBC-4E75-B74D-554EC8051A34@yale.edu> On Mar 1, 2006, at 12:56 PM, Young,Jeff (OR) wrote: > >> Lots of complexity averted for end-user/developers. I'm just saying. > > I'm not convinced that this: > > url_ver=Z39.88-2004&rft_id=info%3Adoi%2F10.1126%2Fscience. > 275.5304.1320 > > is significantly more difficult to process than this: > > uri=info%3Adoi%2F10.1126%2Fscience.275.5304.1320 The difference is that you already understand OpenURL. 99.96% of the rest of the developer world doesn't. :) But still: are you saying, therefore, that unAPI itself is not worthwhile? It's good for you to share this opinion here, but it isn't clear to me what you mean by it. And not to beat a dead horse further, but... There's no problem with layering unAPI implementations over OpenURL implementations. That it was fairly easy for you to accomplish is a good thing, and is a positive result indicating that the spec's heading in the right direction. Indeed, this kind of outcome is a stated goal of the spec, and you were first to demonstrate this! There's a problem with asking the world to implement OpenURL 1.0: it'll never happen. That the chances of the world implementing unAPI are only slightly better doesn't keep me up all night anymore. Just a lengthy part of the night. :) -Dan From jyoung at oclc.org Wed Mar 1 13:31:40 2006 From: jyoung at oclc.org (Young,Jeff (OR)) Date: Wed Mar 1 13:32:05 2006 Subject: [gcs-pcs-list] on using URIs Message-ID: I'm not saying unAPI isn't worthwhile. I'm saying that unAPI should be implemented as a profile of OpenURL. Everyone is so convinced OpenURL is incomprehensible that their brains shut down immediately. I'm claiming that converting the existing unAPI protocol to be OpenURL 1.0 compliant is utterly trivial. Here's what it would take: 1) Add "url_ver= Z39.88-2004" in the "microformat" span 2) rename "uri" to "rft_id" in the span 3) Change the resolver so it doesn't blow up when it sees the url_ver parameter 4) Change the resolver to look for "rft_id" in place of "uri" You are now 100% OpenURL 1.0 compliant. Jeff > -----Original Message----- > From: Daniel Chudnov [mailto:daniel.chudnov@yale.edu] > Sent: Wednesday, March 01, 2006 1:20 PM > To: Young,Jeff (OR) > Cc: GCS-PCS list > Subject: Re: [gcs-pcs-list] on using URIs > > On Mar 1, 2006, at 12:56 PM, Young,Jeff (OR) wrote: > > > >> Lots of complexity averted for end-user/developers. I'm just saying. > > > > I'm not convinced that this: > > > > url_ver=Z39.88-2004&rft_id=info%3Adoi%2F10.1126%2Fscience. > > 275.5304.1320 > > > > is significantly more difficult to process than this: > > > > uri=info%3Adoi%2F10.1126%2Fscience.275.5304.1320 > > The difference is that you already understand OpenURL. 99.96% of the > rest of the developer world doesn't. :) > > But still: are you saying, therefore, that unAPI itself is not > worthwhile? It's good for you to share this opinion here, but it > isn't clear to me what you mean by it. > > And not to beat a dead horse further, but... > > There's no problem with layering unAPI implementations over OpenURL > implementations. That it was fairly easy for you to accomplish is a > good thing, and is a positive result indicating that the spec's > heading in the right direction. Indeed, this kind of outcome is a > stated goal of the spec, and you were first to demonstrate this! > > There's a problem with asking the world to implement OpenURL 1.0: > it'll never happen. > > That the chances of the world implementing unAPI are only slightly > better doesn't keep me up all night anymore. Just a lengthy part of > the night. :) > > -Dan From daniel.chudnov at yale.edu Wed Mar 1 13:51:50 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Wed Mar 1 13:52:54 2006 Subject: [gcs-pcs-list] on using URIs In-Reply-To: References: Message-ID: <45D6C45F-F438-4A54-B5C3-BC78350CFA7E@yale.edu> On Mar 1, 2006, at 1:31 PM, Young,Jeff (OR) wrote: > I'm not saying unAPI isn't worthwhile. I'm saying that unAPI should be > implemented as a profile of OpenURL. Everyone is so convinced > OpenURL is > incomprehensible that their brains shut down immediately. I'm claiming > that converting the existing unAPI protocol to be OpenURL 1.0 > compliant > is utterly trivial. Here's what it would take: > > 1) Add "url_ver= Z39.88-2004" in the "microformat" span > 2) rename "uri" to "rft_id" in the span > 3) Change the resolver so it doesn't blow up when it sees the url_ver > parameter > 4) Change the resolver to look for "rft_id" in place of "uri" > > You are now 100% OpenURL 1.0 compliant. Yes... cool... I get it. unAPI can be implemented as a profile of OpenURL, and in your opinion, it should be. And unAPI conventions can be converted trivially to OpenURL. Right. No arguments here. But: are you saying we should change unAPI-the-specification to make it an OpenURL profile? Your words don't say that explicitly, but your tone implies it, and regrettably, we're not at the same table at the bar anymore, so I can't guess whether this is really what you mean or not. :( -dc (whose brain arguably never started up today) From jyoung at oclc.org Wed Mar 1 14:06:12 2006 From: jyoung at oclc.org (Young,Jeff (OR)) Date: Wed Mar 1 14:06:41 2006 Subject: [gcs-pcs-list] on using URIs Message-ID: > Yes... cool... I get it. unAPI can be implemented as a profile of > OpenURL, and in your opinion, it should be. And unAPI conventions > can be converted trivially to OpenURL. Right. No arguments here. > > But: are you saying we should change unAPI-the-specification to make > it an OpenURL profile? Your words don't say that explicitly, but > your tone implies it, and regrettably, we're not at the same table at > the bar anymore, so I can't guess whether this is really what you > mean or not. :( If you change the unAPI specification to include a url_ver parameter and use rft_id in place of url, I think you're 99% of the way there. If implementers obey these rules, OpenURL 1.0 compliance comes for free. Your spec could link to the OpenURL 1.0 spec and unAPI Community Profile as footnotes. BTW, Community Profile means something specific in OpenURL terms and refers to an entry in the OpenURL Registry. For example, here is a "Dublin Core" profile: http://www.openurl.info/registry/docs/pro/info:ofi/pro:dccp-2004 The profile for unAPI would be much simpler and I would be happy to mock one up for you. Jeff From liu_x at lanl.gov Wed Mar 1 14:41:52 2006 From: liu_x at lanl.gov (Xiaoming Liu) Date: Wed Mar 1 14:41:21 2006 Subject: [gcs-pcs-list] on using URIs In-Reply-To: References: <20060301011736.GB6692@sildin.med.yale.edu> Message-ID: I am trying to come up a use case that unapi can be used differently, and see if it makes some sense. Say college A has unique course code, such as cs101, however they all appear differently in univeristy, department, faculty, and students web site, and hence it's diffcult to find related information about a course. Now college A decides to use consistent tag URI for cs101, such as tag:A,2001-01-01:/course/cs101, and all web pages support unapi when they reference this URI. In this case, the URI is an agreement inside of the university, and a student may install a greasymonkey script, it contains all courses he is taking, so whenever a web page contains his selected course, the related information will highlight, and perhaps a link to unapi is added. I think this demonstrate two points: the chosen URI is only meaningful in college A, however it's very useful; and the application is a simple scrips of scanning web page and highlight users' interest, I am not sure how close this is associated with OpenURL. Now maybe college B in same town may decide to share course code with college A, suddently these URIs are meaningful in more than one campus. So this illustrates that nature of your URIs can be slowly changed, so perhaps better be prepared. I hope this example illustrates two points: (a) the nature of your URI can be changed, so be prepared ;-) (b) unapi is simple and just do one thing well, so like unix philophy, its scope of application is not strictly limited by current protocol or practice, therefore not an OpenURL lite or OAI-PMH lite. xiaoming On Wed, 1 Mar 2006, Ross Singer wrote: > There's something else to note here... In the Evergreen scenario, the > suggestion is to use ISxN or some other standard identifier rather than local > identifier, but, frankly, this is much more complicated on, say, /my/ opac. > > So, are tag uris to be discouraged? Is it functionally any different than > just using a local identifier? > > Also, I'm still not sure I'm buying Evergreen using urn:isbn:123456789X in > this case. It's /not/ referring to 123456789X, it's (possibly) referring to > 123456789X /or something sort of like it/. urn:isbn:123456789X seems pretty > explicit. /Maybe/ I am just looking for the title/author, but maybe I'm > looking for publisher city or date. ISBN concordance is /bad/ in this case. > > It's early, though, it's probable that I read that wrong. > > Anyway, I need some clarity on the tag v. info uri v. url issue... > Basically, I don't want to waste my time w/r/t code either over-analyzing the > problem or undoing 'under-analyzing' it. > > -Ross. > > On Mar 1, 2006, at 7:00 AM, Robert Sanderson wrote: > >> >> On Tue, 28 Feb 2006, Daniel Chudnov wrote: >>> The case for URIs includes: >> >>> - they refer to the same thing across applications >> >> Which is great, but not interesting for unapi surely where the use case >> is 'I want this that I see now' not 'I want the thing identified by X' >> >>> - they imply some measure of identifier persistence >> >> Which is a disadvantage because it means that dynamic content which is >> not persistent is less appropriate for unapi. If the use case is 'I >> want what I see now' (copy), not 'I want to refer back to this in the >> future' (citation), then this means that we're adding hindrances. >> >>> - where objects might be copied around using unAPI there is probably >>> already some sort of implication of object+id persistence >> >> Why? >> >>> Fwiw, we're getting to the point where we should be weighing decisions >>> more and more w/r/to implemented code. So, from the point of view of >>> the projects for which I'm using unAPI... >> >> Well, my code says that it's more complicated to put record identifier >> into a fake URI, and I think that Mike's code says the same thing. >> >> >>> - it is easy to map specific identifier patterns to specific webapps >>> - without the standard URI prefix patterns, it might be impossible >>> to efficiently assign a handler to a particular arbitrary identifier >> >> Isn't that a resolver, rather than a copy/paste format? >> >>> - having full URI patterns makes it easy to use a library like OPA >>> to resolve ids >> Which is acting as a resolver, effectively. >> >>> - using full URIs makes it more likely that different pasted-in >>> stuff can refer to the same thing consistently, e.g. if user1 writes >>> about a book in a blog, user2 saves an amazon book link, and user3 >>> saves an OPAC record for the book, unalog can collate all three around >>> the URI (as opposed to randomly differing variants on ISBNs) >> >> In the 'I want this thing I see' mode, this isn't important. As soon as >> you get past that, then you're reinventing openURL. >> >>> - unalog itself referring to an object by its URI allows potentially >>> better precision in service/content resolution, e.g. queries for >>> object "12345" might return wildly different things with (unlike >>> w/tagging) zero potential value to be derived from overlaps across >>> disparate objects >> >> You even use the word resolution here. I won't restate the obvious :) >> >>> Another good reason to require URIs is that bridging other protocols >>> (APP, OpenURL, OpenSearch/SRU) might be easier if implementers already >>> have fully-specified URIs. >> >> Ditto. >> >>> As for the Evergreen blog post: Mike, I'd suggest that what you want >>> there isn't some tag or other made-up URI for your internal record >>> identifier, but rather the ISBN URI (e.g. urn:isbn:123456789X) relevant >>> for the item in your catalog (or an ISSN, etc.), unless an item in the >>> catalog has no known public identifier already. >> >> Not only is ISBN not consistently available, it's also not consistently >> unique. >> >>> - content identifiers represent publicly-known identifiers that are >>> independent of system implementations. all systems dealing with >>> the same content item would use the same content identifier. some >>> examples would be ISBNs, PMIDs, flickr photo ids, blog post numbers, >>> etc. these are probably at least "precious" or "normal", to use >>> Xiaoming's formulation. >> >> But you're dealing with one system. >> >>> - package and datastream identifiers represent specific-to-an- >>> application identifiers that aren't necessarily public or known >>> outside of the system itself. maybe they are, maybe they aren't. >>> some examples would be unalog entry ids, flickr image file URLs, >>> repository bitstream uuids, etc. >> >>> imho unAPI is all about content identifiers. Or, rather, you could use >>> the other kinds of identifiers with it, but if it really takes off as >>> an cross-application spec, it will be through the common use of content >>> identifiers, most of which can be usefully rendered as URIs. >> >> Then my claim (and Jeff's claim, I think) is that you're reinventing >> OpenURL. >> >> Rob >> _______________________________________________ >> gcs-pcs-list mailing list >> gcs-pcs-list@cipolo.med.yale.edu >> http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list >> > > _______________________________________________ > gcs-pcs-list mailing list > gcs-pcs-list@cipolo.med.yale.edu > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list > -- Xiaoming From jyoung at oclc.org Wed Mar 1 14:51:36 2006 From: jyoung at oclc.org (Young,Jeff (OR)) Date: Wed Mar 1 14:52:03 2006 Subject: [gcs-pcs-list] on using URIs Message-ID: If I've convinced Dan that unAPI can be easily reconciled with OpenURL (see previous posts), then the arguments about URIs should become moot. Ross' desire for "private-data" referents might then become an easier sell. Jeff > -----Original Message----- > From: gcs-pcs-list-bounces@cipolo.med.yale.edu [mailto:gcs-pcs-list- > bounces@cipolo.med.yale.edu] On Behalf Of Xiaoming Liu > Sent: Wednesday, March 01, 2006 2:42 PM > To: Ross Singer > Cc: GCS-PCS list > Subject: Re: [gcs-pcs-list] on using URIs > > I am trying to come up a use case that unapi can be used differently, > and see if it makes some sense. > > Say college A has unique course code, such as cs101, however they all > appear differently in univeristy, department, faculty, and students web > site, and hence it's diffcult to find related information about a course. > > Now college A decides to use consistent tag URI for cs101, such as > tag:A,2001-01-01:/course/cs101, and all web pages support unapi when they > reference this URI. In this case, the URI is an agreement inside of the > university, and a student may install a greasymonkey script, it contains > all courses he is taking, so whenever a web page contains his selected > course, the related information will highlight, and perhaps a link to > unapi is added. > > I think this demonstrate two points: the chosen URI is only meaningful in > college A, however it's very useful; and the application is a > simple scrips of scanning web page and highlight users' interest, I am not > sure how close this is associated with OpenURL. > > Now maybe college B in same town may decide to share course code with > college A, suddently these URIs are meaningful in more than one campus. So > this illustrates that nature of your URIs can be slowly changed, so > perhaps better be prepared. > > I hope this example illustrates two points: (a) the nature of your URI > can be changed, so be prepared ;-) (b) unapi is simple and just do one > thing well, so like unix philophy, its scope of application is not > strictly limited by current protocol or practice, therefore not an > OpenURL lite or OAI-PMH lite. > > xiaoming > > > On Wed, 1 Mar 2006, Ross Singer wrote: > > > There's something else to note here... In the Evergreen scenario, the > > suggestion is to use ISxN or some other standard identifier rather than > local > > identifier, but, frankly, this is much more complicated on, say, /my/ > opac. > > > > So, are tag uris to be discouraged? Is it functionally any different > than > > just using a local identifier? > > > > Also, I'm still not sure I'm buying Evergreen using urn:isbn:123456789X > in > > this case. It's /not/ referring to 123456789X, it's (possibly) > referring to > > 123456789X /or something sort of like it/. urn:isbn:123456789X seems > pretty > > explicit. /Maybe/ I am just looking for the title/author, but maybe I'm > > looking for publisher city or date. ISBN concordance is /bad/ in this > case. > > > > It's early, though, it's probable that I read that wrong. > > > > Anyway, I need some clarity on the tag v. info uri v. url issue... > > Basically, I don't want to waste my time w/r/t code either over- > analyzing the > > problem or undoing 'under-analyzing' it. > > > > -Ross. > > > > On Mar 1, 2006, at 7:00 AM, Robert Sanderson wrote: > > > >> > >> On Tue, 28 Feb 2006, Daniel Chudnov wrote: > >>> The case for URIs includes: > >> > >>> - they refer to the same thing across applications > >> > >> Which is great, but not interesting for unapi surely where the use case > >> is 'I want this that I see now' not 'I want the thing identified by X' > >> > >>> - they imply some measure of identifier persistence > >> > >> Which is a disadvantage because it means that dynamic content which is > >> not persistent is less appropriate for unapi. If the use case is 'I > >> want what I see now' (copy), not 'I want to refer back to this in the > >> future' (citation), then this means that we're adding hindrances. > >> > >>> - where objects might be copied around using unAPI there is probably > >>> already some sort of implication of object+id persistence > >> > >> Why? > >> > >>> Fwiw, we're getting to the point where we should be weighing decisions > >>> more and more w/r/to implemented code. So, from the point of view of > >>> the projects for which I'm using unAPI... > >> > >> Well, my code says that it's more complicated to put record identifier > >> into a fake URI, and I think that Mike's code says the same thing. > >> > >> > >>> - it is easy to map specific identifier patterns to specific webapps > >>> - without the standard URI prefix patterns, it might be impossible > >>> to efficiently assign a handler to a particular arbitrary identifier > >> > >> Isn't that a resolver, rather than a copy/paste format? > >> > >>> - having full URI patterns makes it easy to use a library like OPA > >>> to resolve ids > >> Which is acting as a resolver, effectively. > >> > >>> - using full URIs makes it more likely that different pasted-in > >>> stuff can refer to the same thing consistently, e.g. if user1 writes > >>> about a book in a blog, user2 saves an amazon book link, and user3 > >>> saves an OPAC record for the book, unalog can collate all three > around > >>> the URI (as opposed to randomly differing variants on ISBNs) > >> > >> In the 'I want this thing I see' mode, this isn't important. As soon > as > >> you get past that, then you're reinventing openURL. > >> > >>> - unalog itself referring to an object by its URI allows potentially > >>> better precision in service/content resolution, e.g. queries for > >>> object "12345" might return wildly different things with (unlike > >>> w/tagging) zero potential value to be derived from overlaps across > >>> disparate objects > >> > >> You even use the word resolution here. I won't restate the obvious :) > >> > >>> Another good reason to require URIs is that bridging other protocols > >>> (APP, OpenURL, OpenSearch/SRU) might be easier if implementers already > >>> have fully-specified URIs. > >> > >> Ditto. > >> > >>> As for the Evergreen blog post: Mike, I'd suggest that what you want > >>> there isn't some tag or other made-up URI for your internal record > >>> identifier, but rather the ISBN URI (e.g. urn:isbn:123456789X) > relevant > >>> for the item in your catalog (or an ISSN, etc.), unless an item in the > >>> catalog has no known public identifier already. > >> > >> Not only is ISBN not consistently available, it's also not consistently > >> unique. > >> > >>> - content identifiers represent publicly-known identifiers that are > >>> independent of system implementations. all systems dealing with > >>> the same content item would use the same content identifier. some > >>> examples would be ISBNs, PMIDs, flickr photo ids, blog post numbers, > >>> etc. these are probably at least "precious" or "normal", to use > >>> Xiaoming's formulation. > >> > >> But you're dealing with one system. > >> > >>> - package and datastream identifiers represent specific-to-an- > >>> application identifiers that aren't necessarily public or known > >>> outside of the system itself. maybe they are, maybe they aren't. > >>> some examples would be unalog entry ids, flickr image file URLs, > >>> repository bitstream uuids, etc. > >> > >>> imho unAPI is all about content identifiers. Or, rather, you could > use > >>> the other kinds of identifiers with it, but if it really takes off as > >>> an cross-application spec, it will be through the common use of > content > >>> identifiers, most of which can be usefully rendered as URIs. > >> > >> Then my claim (and Jeff's claim, I think) is that you're reinventing > >> OpenURL. > >> > >> Rob > >> _______________________________________________ > >> gcs-pcs-list mailing list > >> gcs-pcs-list@cipolo.med.yale.edu > >> http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list > >> > > > > _______________________________________________ > > gcs-pcs-list mailing list > > gcs-pcs-list@cipolo.med.yale.edu > > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list > > > > -- > Xiaoming > > _______________________________________________ > gcs-pcs-list mailing list > gcs-pcs-list@cipolo.med.yale.edu > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list From mrylander at gmail.com Wed Mar 1 14:53:16 2006 From: mrylander at gmail.com (Mike Rylander) Date: Wed Mar 1 14:54:20 2006 Subject: [gcs-pcs-list] on using URIs In-Reply-To: References: Message-ID: On 3/1/06, Young,Jeff (OR) wrote: > > Yes... cool... I get it. unAPI can be implemented as a profile of > > OpenURL, and in your opinion, it should be. And unAPI conventions > > can be converted trivially to OpenURL. Right. No arguments here. > > > > But: are you saying we should change unAPI-the-specification to make > > it an OpenURL profile? Your words don't say that explicitly, but > > your tone implies it, and regrettably, we're not at the same table at > > the bar anymore, so I can't guess whether this is really what you > > mean or not. :( > > If you change the unAPI specification to include a url_ver parameter and > use rft_id in place of url, I think you're 99% of the way there. If > implementers obey these rules, OpenURL 1.0 compliance comes for free. > Your spec could link to the OpenURL 1.0 spec and unAPI Community Profile > as footnotes. Or, you can just follow 'net convention and be "liberal on read, strict on write", and implement the unAPI spec on top of your existing OpenURL server. I, however, have no plans to build my own OpenURL resolver any time soon. That implies far to much functionality, and I'd rather not get blasted for having a crappy OpenURL server instead of a great unAPI server. Just my $.02 ... :) > > BTW, Community Profile means something specific in OpenURL terms and > refers to an entry in the OpenURL Registry. For example, here is a > "Dublin Core" profile: > > http://www.openurl.info/registry/docs/pro/info:ofi/pro:dccp-2004 > > The profile for unAPI would be much simpler and I would be happy to mock > one up for you. > > Jeff > > _______________________________________________ > gcs-pcs-list mailing list > gcs-pcs-list@cipolo.med.yale.edu > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list > -- Mike Rylander mrylander@gmail.com GPLS -- PINES Development Database Developer http://open-ils.org From jyoung at oclc.org Wed Mar 1 14:56:39 2006 From: jyoung at oclc.org (Young,Jeff (OR)) Date: Wed Mar 1 14:57:07 2006 Subject: [gcs-pcs-list] on using URIs Message-ID: I said "Ross" but I meant "Rob". Sorry. > -----Original Message----- > From: gcs-pcs-list-bounces@cipolo.med.yale.edu [mailto:gcs-pcs-list- > bounces@cipolo.med.yale.edu] On Behalf Of Young,Jeff (OR) > Sent: Wednesday, March 01, 2006 2:52 PM > To: Xiaoming Liu; Ross Singer > Cc: GCS-PCS list > Subject: RE: [gcs-pcs-list] on using URIs > > If I've convinced Dan that unAPI can be easily reconciled with OpenURL > (see previous posts), then the arguments about URIs should become moot. > Ross' desire for "private-data" referents might then become an easier > sell. > > Jeff > > > -----Original Message----- > > From: gcs-pcs-list-bounces@cipolo.med.yale.edu [mailto:gcs-pcs-list- > > bounces@cipolo.med.yale.edu] On Behalf Of Xiaoming Liu > > Sent: Wednesday, March 01, 2006 2:42 PM > > To: Ross Singer > > Cc: GCS-PCS list > > Subject: Re: [gcs-pcs-list] on using URIs > > > > I am trying to come up a use case that unapi can be used differently, > > and see if it makes some sense. > > > > Say college A has unique course code, such as cs101, however they all > > appear differently in univeristy, department, faculty, and students > web > > site, and hence it's diffcult to find related information about a > course. > > > > Now college A decides to use consistent tag URI for cs101, such as > > tag:A,2001-01-01:/course/cs101, and all web pages support unapi when > they > > reference this URI. In this case, the URI is an agreement inside of > the > > university, and a student may install a greasymonkey script, it > contains > > all courses he is taking, so whenever a web page contains his selected > > course, the related information will highlight, and perhaps a link to > > unapi is added. > > > > I think this demonstrate two points: the chosen URI is only meaningful > in > > college A, however it's very useful; and the application is a > > simple scrips of scanning web page and highlight users' interest, I am > not > > sure how close this is associated with OpenURL. > > > > Now maybe college B in same town may decide to share course code with > > college A, suddently these URIs are meaningful in more than one > campus. So > > this illustrates that nature of your URIs can be slowly changed, so > > perhaps better be prepared. > > > > I hope this example illustrates two points: (a) the nature of your URI > > can be changed, so be prepared ;-) (b) unapi is simple and just do one > > thing well, so like unix philophy, its scope of application is not > > strictly limited by current protocol or practice, therefore not an > > OpenURL lite or OAI-PMH lite. > > > > xiaoming > > > > > > On Wed, 1 Mar 2006, Ross Singer wrote: > > > > > There's something else to note here... In the Evergreen scenario, > the > > > suggestion is to use ISxN or some other standard identifier rather > than > > local > > > identifier, but, frankly, this is much more complicated on, say, > /my/ > > opac. > > > > > > So, are tag uris to be discouraged? Is it functionally any > different > > than > > > just using a local identifier? > > > > > > Also, I'm still not sure I'm buying Evergreen using > urn:isbn:123456789X > > in > > > this case. It's /not/ referring to 123456789X, it's (possibly) > > referring to > > > 123456789X /or something sort of like it/. urn:isbn:123456789X > seems > > pretty > > > explicit. /Maybe/ I am just looking for the title/author, but maybe > I'm > > > looking for publisher city or date. ISBN concordance is /bad/ in > this > > case. > > > > > > It's early, though, it's probable that I read that wrong. > > > > > > Anyway, I need some clarity on the tag v. info uri v. url issue... > > > Basically, I don't want to waste my time w/r/t code either over- > > analyzing the > > > problem or undoing 'under-analyzing' it. > > > > > > -Ross. > > > > > > On Mar 1, 2006, at 7:00 AM, Robert Sanderson wrote: > > > > > >> > > >> On Tue, 28 Feb 2006, Daniel Chudnov wrote: > > >>> The case for URIs includes: > > >> > > >>> - they refer to the same thing across applications > > >> > > >> Which is great, but not interesting for unapi surely where the use > case > > >> is 'I want this that I see now' not 'I want the thing identified by > X' > > >> > > >>> - they imply some measure of identifier persistence > > >> > > >> Which is a disadvantage because it means that dynamic content which > is > > >> not persistent is less appropriate for unapi. If the use case is > 'I > > >> want what I see now' (copy), not 'I want to refer back to this in > the > > >> future' (citation), then this means that we're adding hindrances. > > >> > > >>> - where objects might be copied around using unAPI there is > probably > > >>> already some sort of implication of object+id persistence > > >> > > >> Why? > > >> > > >>> Fwiw, we're getting to the point where we should be weighing > decisions > > >>> more and more w/r/to implemented code. So, from the point of view > of > > >>> the projects for which I'm using unAPI... > > >> > > >> Well, my code says that it's more complicated to put record > identifier > > >> into a fake URI, and I think that Mike's code says the same thing. > > >> > > >> > > >>> - it is easy to map specific identifier patterns to specific > webapps > > >>> - without the standard URI prefix patterns, it might be impossible > > >>> to efficiently assign a handler to a particular arbitrary > identifier > > >> > > >> Isn't that a resolver, rather than a copy/paste format? > > >> > > >>> - having full URI patterns makes it easy to use a library like OPA > > >>> to resolve ids > > >> Which is acting as a resolver, effectively. > > >> > > >>> - using full URIs makes it more likely that different pasted-in > > >>> stuff can refer to the same thing consistently, e.g. if user1 > writes > > >>> about a book in a blog, user2 saves an amazon book link, and > user3 > > >>> saves an OPAC record for the book, unalog can collate all three > > around > > >>> the URI (as opposed to randomly differing variants on ISBNs) > > >> > > >> In the 'I want this thing I see' mode, this isn't important. As > soon > > as > > >> you get past that, then you're reinventing openURL. > > >> > > >>> - unalog itself referring to an object by its URI allows > potentially > > >>> better precision in service/content resolution, e.g. queries for > > >>> object "12345" might return wildly different things with (unlike > > >>> w/tagging) zero potential value to be derived from overlaps > across > > >>> disparate objects > > >> > > >> You even use the word resolution here. I won't restate the obvious > :) > > >> > > >>> Another good reason to require URIs is that bridging other > protocols > > >>> (APP, OpenURL, OpenSearch/SRU) might be easier if implementers > already > > >>> have fully-specified URIs. > > >> > > >> Ditto. > > >> > > >>> As for the Evergreen blog post: Mike, I'd suggest that what you > want > > >>> there isn't some tag or other made-up URI for your internal record > > >>> identifier, but rather the ISBN URI (e.g. urn:isbn:123456789X) > > relevant > > >>> for the item in your catalog (or an ISSN, etc.), unless an item in > the > > >>> catalog has no known public identifier already. > > >> > > >> Not only is ISBN not consistently available, it's also not > consistently > > >> unique. > > >> > > >>> - content identifiers represent publicly-known identifiers that > are > > >>> independent of system implementations. all systems dealing with > > >>> the same content item would use the same content identifier. > some > > >>> examples would be ISBNs, PMIDs, flickr photo ids, blog post > numbers, > > >>> etc. these are probably at least "precious" or "normal", to use > > >>> Xiaoming's formulation. > > >> > > >> But you're dealing with one system. > > >> > > >>> - package and datastream identifiers represent specific-to-an- > > >>> application identifiers that aren't necessarily public or known > > >>> outside of the system itself. maybe they are, maybe they > aren't. > > >>> some examples would be unalog entry ids, flickr image file URLs, > > >>> repository bitstream uuids, etc. > > >> > > >>> imho unAPI is all about content identifiers. Or, rather, you > could > > use > > >>> the other kinds of identifiers with it, but if it really takes off > as > > >>> an cross-application spec, it will be through the common use of > > content > > >>> identifiers, most of which can be usefully rendered as URIs. > > >> > > >> Then my claim (and Jeff's claim, I think) is that you're > reinventing > > >> OpenURL. > > >> > > >> Rob > > >> _______________________________________________ > > >> gcs-pcs-list mailing list > > >> gcs-pcs-list@cipolo.med.yale.edu > > >> http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list > > >> > > > > > > _______________________________________________ > > > gcs-pcs-list mailing list > > > gcs-pcs-list@cipolo.med.yale.edu > > > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list > > > > > > > -- > > Xiaoming > > > > _______________________________________________ > > gcs-pcs-list mailing list > > gcs-pcs-list@cipolo.med.yale.edu > > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list > _______________________________________________ > gcs-pcs-list mailing list > gcs-pcs-list@cipolo.med.yale.edu > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list From daniel.chudnov at yale.edu Wed Mar 1 16:03:14 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Wed Mar 1 16:03:16 2006 Subject: [gcs-pcs-list] on using URIs In-Reply-To: References: Message-ID: <20060301210312.GA12041@sildin.med.yale.edu> Young,Jeff (OR) wrote, on Wed, Mar 01, 2006 at 02:06:12PM -0500: > > But: are you saying we should change unAPI-the-specification to make > > it an OpenURL profile? Your words don't say that explicitly, but > > your tone implies it, and regrettably, we're not at the same table at > > the bar anymore, so I can't guess whether this is really what you > > mean or not. :( > > If you change the unAPI specification to include a url_ver parameter and > use rft_id in place of url, I think you're 99% of the way there. If > implementers obey these rules, OpenURL 1.0 compliance comes for free. ... > BTW, Community Profile means something specific in OpenURL terms and > refers to an entry in the OpenURL Registry. For example, here is a > "Dublin Core" profile: I think it's a good idea to create an OpenURL Community Profile for unAPI-like services. Other members of this list have exchanged messages with me off-list suggesting something similar, so you'd probably have willing and knowledgeable collaborators. Plus, if unAPI fails, then we could all just use the OpenURL profile. :) The unAPI specification is not OpenURL, and it isn't intended to be, so direct compliance doesn't seem to me to offer anything. Basing the spec on simple HTTP rather than OpenURL (or any other existing spec) makes it palpably easier to understand and gives it a chance at succeeding across communities and across existing protocols on its own merits. -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From lists at hubmed.org Wed Mar 1 16:17:23 2006 From: lists at hubmed.org (Alf Eaton) Date: Wed Mar 1 16:20:43 2006 Subject: [gcs-pcs-list] on using URIs In-Reply-To: References: Message-ID: On 01 Mar 2006, at 13:31, Young,Jeff (OR) wrote: > I'm not saying unAPI isn't worthwhile. I'm saying that unAPI should be > implemented as a profile of OpenURL. Everyone is so convinced > OpenURL is > incomprehensible that their brains shut down immediately. I'm claiming > that converting the existing unAPI protocol to be OpenURL 1.0 > compliant > is utterly trivial. Here's what it would take: > > 1) Add "url_ver= Z39.88-2004" in the "microformat" span Which just made it about 10x harder to implement. > 2) rename "uri" to "rft_id" in the span Ditto. > 3) Change the resolver so it doesn't blow up when it > sees the url_ver > parameter Surely an OpenURL resolver shouldn't ignore the parameter passed to it that tells it what kind of OpenURL it has to handle? > 4) Change the resolver to look for "rft_id" in place of "uri" > > You are now 100% OpenURL 1.0 compliant. Great - what do I win? alf (sarcastically, but only because I think the chances of persuading everyone to do this are much higher if it looks as much like a simple microformat as possible). From jyoung at oclc.org Wed Mar 1 16:24:32 2006 From: jyoung at oclc.org (Young,Jeff (OR)) Date: Wed Mar 1 16:25:30 2006 Subject: [gcs-pcs-list] on using URIs Message-ID: Uncle. > -----Original Message----- > From: gcs-pcs-list-bounces@cipolo.med.yale.edu [mailto:gcs-pcs-list- > bounces@cipolo.med.yale.edu] On Behalf Of Alf Eaton > Sent: Wednesday, March 01, 2006 4:17 PM > To: GCS-PCS list > Subject: Re: [gcs-pcs-list] on using URIs > > On 01 Mar 2006, at 13:31, Young,Jeff (OR) wrote: > > > I'm not saying unAPI isn't worthwhile. I'm saying that unAPI should be > > implemented as a profile of OpenURL. Everyone is so convinced > > OpenURL is > > incomprehensible that their brains shut down immediately. I'm claiming > > that converting the existing unAPI protocol to be OpenURL 1.0 > > compliant > > is utterly trivial. Here's what it would take: > > > > 1) Add "url_ver= Z39.88-2004" in the "microformat" span > > Which just made it about 10x harder to implement. > > > 2) rename "uri" to "rft_id" in the span > > Ditto. > > > 3) Change the resolver so it doesn't blow up when it > > sees the url_ver > > parameter > > Surely an OpenURL resolver shouldn't ignore the parameter passed to > it that tells it what kind of OpenURL it has to handle? > > > 4) Change the resolver to look for "rft_id" in place of "uri" > > > > You are now 100% OpenURL 1.0 compliant. > > Great - what do I win? > > alf (sarcastically, but only because I think the chances of > persuading everyone to do this are much higher if it looks as much > like a simple microformat as possible). > _______________________________________________ > gcs-pcs-list mailing list > gcs-pcs-list@cipolo.med.yale.edu > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list From lists at hubmed.org Wed Mar 1 16:25:59 2006 From: lists at hubmed.org (Alf Eaton) Date: Wed Mar 1 16:26:09 2006 Subject: [gcs-pcs-list] on using URIs In-Reply-To: References: <20060301011736.GB6692@sildin.med.yale.edu> Message-ID: <37D881AF-8435-43C9-B2EA-54379B3C0098@hubmed.org> On 01 Mar 2006, at 10:44, Mike Rylander wrote: > On 3/1/06, Robert Sanderson wrote: >> >> On Tue, 28 Feb 2006, Daniel Chudnov wrote: >>> The case for URIs includes: >> >>> - they refer to the same thing across applications >> >> Which is great, but not interesting for unapi surely where the use >> case >> is 'I want this that I see now' not 'I want the thing identified >> by X' >> >>> - they imply some measure of identifier persistence >> >> Which is a disadvantage because it means that dynamic content >> which is >> not persistent is less appropriate for unapi. If the use case is 'I >> want what I see now' (copy), not 'I want to refer back to this in the >> future' (citation), then this means that we're adding hindrances. > > Well, they don't have to though. If Alf's blog posts use day granular > tag URIs, then the persistence is valid for that one day. If my > catalog uses year granular tags then I should do my best to make sure > that the records are available for the entire year (or use a more > granular time specifier). To put it another way, the time specifier > defines the "horizontal (temporal) persistence", the sub-URI at the > end defines the "vertical (cross-app) persistence", and as an added > bonus, the "authority identifier" can tell us where to go looking for > an unapi server. I don't interpret the date part of tag URIs as working that way. The date should identify when the tag was coined (so as to distinguish it from someone else using the same authority at a later date), but should resolve to the same item for perpetuity. eg should always refer to the same post, regardless of where it's stored, whereas if someone else buys my domain and uses the tag that will identify their post, forever, instead. alf. From daniel.chudnov at yale.edu Wed Mar 1 16:45:21 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Wed Mar 1 16:45:28 2006 Subject: [gcs-pcs-list] call to vote: table the URI debate Message-ID: <20060301214520.GE12041@sildin.med.yale.edu> We could keep debating the URI vs. not-URI thing for another two weeks, but then we'd stay distracted from addressing other pressing issues in the meantime. So: SEEING AS many of us are keenly interested in resolving (he-heh... I said "resolving") this debate, and; SEEING AS there are many other issues to address that are arguably far simpler and, thus, more likely to be quickly resolved (heh), and; SEEING AS we all want to keep pushing forward, and; SEEING AS many of us have previously gone 15 rounds of heavyweight slugging with the identifier demon before and lived to swear vilely about it, but; SEEING AS ALSO how important this is to be sure we decide on before we're done; BE IT PROPOSED that we should table the identifier debate until after the next revision or after such time has passed that a number of interesting new unAPI-driven applications make it easier to weigh the options based on real code and not our hard-won (or, in my case, lost) biases, and; BE IT DECIDED that we will leave the spec unchanged, for now, on the topic of what we mean by "URI" and "identifier", but; LET IT NOT BE FORGOTTEN that this is of critical importance and to be taken up again soon, as so stated in the previous-by-two paragraph. What say? -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From mrylander at gmail.com Wed Mar 1 16:54:13 2006 From: mrylander at gmail.com (Mike Rylander) Date: Wed Mar 1 16:55:16 2006 Subject: [gcs-pcs-list] call to vote: table the URI debate In-Reply-To: <20060301214520.GE12041@sildin.med.yale.edu> References: <20060301214520.GE12041@sildin.med.yale.edu> Message-ID: +1 On 3/1/06, Daniel Chudnov wrote: > We could keep debating the URI vs. not-URI thing for another two weeks, > but then we'd stay distracted from addressing other pressing issues in > the meantime. So: > > SEEING AS many of us are keenly interested in resolving (he-heh... I said > "resolving") this debate, and; > > SEEING AS there are many other issues to address that are arguably far > simpler and, thus, more likely to be quickly resolved (heh), and; > > SEEING AS we all want to keep pushing forward, and; > > SEEING AS many of us have previously gone 15 rounds of heavyweight > slugging with the identifier demon before and lived to swear vilely > about it, but; > > SEEING AS ALSO how important this is to be sure we decide on before we're > done; > > BE IT PROPOSED that we should table the identifier debate until after the > next revision or after such time has passed that a number of interesting > new unAPI-driven applications make it easier to weigh the options based > on real code and not our hard-won (or, in my case, lost) biases, and; > > BE IT DECIDED that we will leave the spec unchanged, for now, on the > topic of what we mean by "URI" and "identifier", but; > > LET IT NOT BE FORGOTTEN that this is of critical importance and to be > taken up again soon, as so stated in the previous-by-two paragraph. > > What say? > > -Dan > > > -- > Daniel Chudnov > Yale Center for Medical Informatics > (203) 737-5789 > _______________________________________________ > gcs-pcs-list mailing list > gcs-pcs-list@cipolo.med.yale.edu > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list > -- Mike Rylander mrylander@gmail.com GPLS -- PINES Development Database Developer http://open-ils.org From ross.singer at library.gatech.edu Wed Mar 1 17:45:53 2006 From: ross.singer at library.gatech.edu (Ross Singer) Date: Wed Mar 1 17:45:49 2006 Subject: [gcs-pcs-list] Another unAPI implementation Message-ID: <44062421.1050503@library.gatech.edu> http://rsinger.library.gatech.edu/search/index.php?search=aerospace&page=1&show=gil Er, you can do other searches, as long as they're one word only. I think it conforms to the spec, but I'm not entirely sure. -Ross. From azaroth at liverpool.ac.uk Thu Mar 2 03:00:08 2006 From: azaroth at liverpool.ac.uk (Robert Sanderson) Date: Thu Mar 2 03:03:20 2006 Subject: [gcs-pcs-list] on using URIs In-Reply-To: References: Message-ID: On Wed, 1 Mar 2006, Alf Eaton wrote: >On 01 Mar 2006, at 13:31, Young,Jeff (OR) wrote: >> I'm not saying unAPI isn't worthwhile. I'm saying that unAPI should be >> implemented as a profile of OpenURL. Everyone is so convinced >> 1) Add "url_ver= Z39.88-2004" in the "microformat" span >Which just made it about 10x harder to implement. But requiring URIs doesn't make it 10x harder to implement? The complete story for url_ver=z39.88-2004 is that you have it as a string. The complete story for uri is that you need to decide which uri schema to use, if any, how to transform your record into something that's at least slightly persistent, and then munge a string to put it in. >> 2) rename "uri" to "rft_id" in the span >Ditto. Ditto. >> You are now 100% OpenURL 1.0 compliant. >Great - what do I win? Not reinventing wheels. Rob From azaroth at liverpool.ac.uk Thu Mar 2 03:26:17 2006 From: azaroth at liverpool.ac.uk (Robert Sanderson) Date: Thu Mar 2 03:29:34 2006 Subject: [gcs-pcs-list] call to vote: table the URI debate In-Reply-To: <20060301214520.GE12041@sildin.med.yale.edu> References: <20060301214520.GE12041@sildin.med.yale.edu> Message-ID: +1 On Wed, 1 Mar 2006, Daniel Chudnov wrote: >BE IT PROPOSED that we should table the identifier debate until after the >next revision or after such time has passed that a number of interesting >new unAPI-driven applications make it easier to weigh the options based >on real code and not our hard-won (or, in my case, lost) biases, and; From daniel.chudnov at yale.edu Thu Mar 2 15:14:31 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Thu Mar 2 15:14:33 2006 Subject: [gcs-pcs-list] new issue: is 406 correct? Message-ID: <20060302201431.GA17286@sildin.med.yale.edu> unAPI revision 1 states, at the very bottom, among the HTTP status code notes: "requests for a URI that is available on the server but for a format that is not available for that URI should return status code 406 Not Acceptable" While implementing OPA I reread what HTTP status code 406 Not Acceptable means: http://rfc.net/rfc2616.html#s10.4.7 "The resource identified by the request is only capable of generating response entities which have content characteristics not acceptable according to the accept headers sent in the request." Note that we are not currently addressing accept headers in unAPI (not that it hasn't come up :). Perhaps it would be better to use HTTP 415 Unsupported Media Type: http://rfc.net/rfc2616.html#s10.4.16 "The server is refusing to service the request because the entity of the request is in a format not supported by the requested resource for the requested method." (Note that this does not even specify mime-type but rather the more general-purpose "format".) That seems like an exact match, and therefore better. I'll propose we change that note, and thus the spec, to now read (where before it read as in the first quote): "requests for a URI that is available on the server but for a format that is not available for that URI should return status code 415 Unsupported Media Type" But, I have no idea if this matters to browsers/languages/etc. -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From mrylander at gmail.com Thu Mar 2 15:19:26 2006 From: mrylander at gmail.com (Mike Rylander) Date: Thu Mar 2 15:20:30 2006 Subject: [gcs-pcs-list] new issue: is 406 correct? In-Reply-To: <20060302201431.GA17286@sildin.med.yale.edu> References: <20060302201431.GA17286@sildin.med.yale.edu> Message-ID: +1 Wow ... that's the first one I've voted on without issue... scary. :) On 3/2/06, Daniel Chudnov wrote: > unAPI revision 1 states, at the very bottom, among the HTTP status > code notes: > > "requests for a URI that is available on the server but for a format > that is not available for that URI should return status code 406 > Not Acceptable" > > > While implementing OPA I reread what HTTP status code 406 Not Acceptable > means: > > http://rfc.net/rfc2616.html#s10.4.7 > > "The resource identified by the request is only capable of generating > response entities which have content characteristics not acceptable > according to the accept headers sent in the request." > > Note that we are not currently addressing accept headers in unAPI > (not that it hasn't come up :). > > Perhaps it would be better to use HTTP 415 Unsupported Media Type: > > http://rfc.net/rfc2616.html#s10.4.16 > > "The server is refusing to service the request because the entity of > the request is in a format not supported by the requested resource > for the requested method." > > (Note that this does not even specify mime-type but rather the more > general-purpose "format".) > > > That seems like an exact match, and therefore better. I'll propose we > change that note, and thus the spec, to now read (where before it read > as in the first quote): > > "requests for a URI that is available on the server but for a format > that is not available for that URI should return status code 415 > Unsupported Media Type" > > > But, I have no idea if this matters to browsers/languages/etc. > > -Dan > > > -- > Daniel Chudnov > Yale Center for Medical Informatics > (203) 737-5789 > _______________________________________________ > gcs-pcs-list mailing list > gcs-pcs-list@cipolo.med.yale.edu > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list > -- Mike Rylander mrylander@gmail.com GPLS -- PINES Development Database Developer http://open-ils.org From arhyno at uwindsor.ca Fri Mar 3 11:05:30 2006 From: arhyno at uwindsor.ca (arhyno@uwindsor.ca) Date: Fri Mar 3 11:07:40 2006 Subject: [gcs-pcs-list] call to vote: table the URI debate In-Reply-To: <20060301214520.GE12041@sildin.med.yale.edu> Message-ID: > What say? +1 (with suitable weighting for voting from beirut with the world's most expensive internet connection) art -------------- next part -------------- An HTML attachment was scrubbed... URL: http://cipolo.med.yale.edu/pipermail/gcs-pcs-list/attachments/20060303/b80021ee/attachment.htm From jyoung at oclc.org Fri Mar 3 11:07:26 2006 From: jyoung at oclc.org (Young,Jeff (OR)) Date: Fri Mar 3 11:08:32 2006 Subject: [gcs-pcs-list] on using URIs Message-ID: Why can't I let this die? On Thurs, Mar 2006, Robert Sanderson wrote: > >> You are now 100% OpenURL 1.0 compliant. > >Great - what do I win? > > Not reinventing wheels. http://alcme.oclc.org/wikid/CollectionOpenUrlResolver:TheSinOfunApi From daniel.chudnov at yale.edu Fri Mar 3 11:41:00 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Fri Mar 3 11:41:01 2006 Subject: [gcs-pcs-list] on using URIs In-Reply-To: References: Message-ID: <20060303164058.GB26227@sildin.med.yale.edu> Young,Jeff (OR) wrote, on Fri, Mar 03, 2006 at 11:07:26AM -0500: > Why can't I let this die? I don't know how I can say this any more simply: you are not unAPI's target audience. You already have OpenURL. Good. I love OpenURL. The rest of the world is unAPI's target audience. The rest of the world doesn't use OpenURL, nor are they about to, today. If something like unAPI caught on with the rest of the world, the world might wake up and realize that they really do need OpenURL. That would be great. We would be ready. Today we're ready, but they're not. That's no value judgement on any of us or on OpenURL... it's a business decision. We've already discussed the possibility of defining an OpenURL Community Profile for unAPI-like services. That seems like a very fruitful path and it seems you already have willing collaborators. I don't want to be a jerk, but at this point, this discussion is a distraction. If unAPI fails, let it be a failure of a spec released to the market, not a failure because we couldn't ship a spec due to infighting. Love, -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From jyoung at oclc.org Fri Mar 3 11:45:50 2006 From: jyoung at oclc.org (Young,Jeff (OR)) Date: Fri Mar 3 11:46:18 2006 Subject: [gcs-pcs-list] on using URIs Message-ID: I've whittled the difference down to two lines of code. If that must stand between us, so be it. > -----Original Message----- > From: Daniel Chudnov [mailto:daniel.chudnov@yale.edu] > Sent: Friday, March 03, 2006 11:41 AM > To: Young,Jeff (OR) > Cc: GCS-PCS list > Subject: Re: [gcs-pcs-list] on using URIs > > Young,Jeff (OR) wrote, on Fri, Mar 03, 2006 at 11:07:26AM -0500: > > Why can't I let this die? > > I don't know how I can say this any more simply: you are not unAPI's > target audience. You already have OpenURL. Good. I love OpenURL. > > The rest of the world is unAPI's target audience. The rest of the > world doesn't use OpenURL, nor are they about to, today. If something > like unAPI caught on with the rest of the world, the world might wake > up and realize that they really do need OpenURL. That would be great. > We would be ready. > > Today we're ready, but they're not. That's no value judgement on any > of us or on OpenURL... it's a business decision. > > We've already discussed the possibility of defining an OpenURL Community > Profile for unAPI-like services. That seems like a very fruitful path > and it seems you already have willing collaborators. > > I don't want to be a jerk, but at this point, this discussion is a > distraction. If unAPI fails, let it be a failure of a spec released > to the market, not a failure because we couldn't ship a spec due to > infighting. > > Love, -Dan > > > -- > Daniel Chudnov > Yale Center for Medical Informatics > (203) 737-5789 From daniel.chudnov at yale.edu Fri Mar 3 11:46:35 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Fri Mar 3 11:46:36 2006 Subject: [gcs-pcs-list] new issue: is 406 correct? In-Reply-To: <20060302201431.GA17286@sildin.med.yale.edu> References: <20060302201431.GA17286@sildin.med.yale.edu> Message-ID: <20060303164634.GC26227@sildin.med.yale.edu> As of yet we're at +2 on this, with no additional comments. That so few have weighed in could be because nobody cares, or because it's a trivial change, or because it's complicated, or because people are busy doing work they get paid for... I dunno. In the past we've typically gotten at least five votes within 24 hours, so I'm raising a special flag on this. I'm hesitant to make a spec change without at least a +5-or-so tally. If you haven't had a chance to review this, please take a moment to do so. If you're indifferent, please say so. Even +2 and 3 indifferents/abstensions is better than just +2. :) I'll leave it open over the weekend, but will start another issue/vote thread in the meantime. Thanks, -Dan Daniel Chudnov wrote, on Thu, Mar 02, 2006 at 03:14:31PM -0500: > unAPI revision 1 states, at the very bottom, among the HTTP status > code notes: > > "requests for a URI that is available on the server but for a format > that is not available for that URI should return status code 406 > Not Acceptable" > > > While implementing OPA I reread what HTTP status code 406 Not Acceptable > means: > > http://rfc.net/rfc2616.html#s10.4.7 > > "The resource identified by the request is only capable of generating > response entities which have content characteristics not acceptable > according to the accept headers sent in the request." > > Note that we are not currently addressing accept headers in unAPI > (not that it hasn't come up :). > > Perhaps it would be better to use HTTP 415 Unsupported Media Type: > > http://rfc.net/rfc2616.html#s10.4.16 > > "The server is refusing to service the request because the entity of > the request is in a format not supported by the requested resource > for the requested method." > > (Note that this does not even specify mime-type but rather the more > general-purpose "format".) > > > That seems like an exact match, and therefore better. I'll propose we > change that note, and thus the spec, to now read (where before it read > as in the first quote): > > "requests for a URI that is available on the server but for a format > that is not available for that URI should return status code 415 > Unsupported Media Type" > > > But, I have no idea if this matters to browsers/languages/etc. > > -Dan > > > -- > Daniel Chudnov > Yale Center for Medical Informatics > (203) 737-5789 > _______________________________________________ > gcs-pcs-list mailing list > gcs-pcs-list@cipolo.med.yale.edu > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list > -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From lists at hubmed.org Fri Mar 3 11:49:07 2006 From: lists at hubmed.org (Alf Eaton) Date: Fri Mar 3 11:55:52 2006 Subject: [gcs-pcs-list] new issue: is 406 correct? In-Reply-To: <20060303164634.GC26227@sildin.med.yale.edu> References: <20060302201431.GA17286@sildin.med.yale.edu> <20060303164634.GC26227@sildin.med.yale.edu> Message-ID: <44087383.60601@hubmed.org> Daniel Chudnov wrote: > As of yet we're at +2 on this, with no additional comments. That so > few have weighed in could be because nobody cares, or because it's a > trivial change, or because it's complicated, or because people are busy > doing work they get paid for... I dunno. > > In the past we've typically gotten at least five votes within 24 hours, > so I'm raising a special flag on this. I'm hesitant to make a spec > change without at least a +5-or-so tally. If you haven't had a chance to > review this, please take a moment to do so. If you're indifferent, please > say so. Even +2 and 3 indifferents/abstensions is better than just +2. :) +1 (I hadn't voted because I didn't disagree with the consensus so far). alf. From ross.singer at library.gatech.edu Fri Mar 3 12:28:47 2006 From: ross.singer at library.gatech.edu (Ross Singer) Date: Fri Mar 3 12:29:51 2006 Subject: [gcs-pcs-list] new issue: is 406 correct? In-Reply-To: <20060302201431.GA17286@sildin.med.yale.edu> References: <20060302201431.GA17286@sildin.med.yale.edu> Message-ID: <23b83f160603030928u3aa6ca96hec29d9bee32cb285@mail.gmail.com> +1 I had held my response because when I first saw your email I though, 'whoa that's way too propeller head for where I'm at right now'. Looking back, it seems like a simpler propeller. -Ross. On 3/2/06, Daniel Chudnov wrote: > unAPI revision 1 states, at the very bottom, among the HTTP status > code notes: > > "requests for a URI that is available on the server but for a format > that is not available for that URI should return status code 406 > Not Acceptable" > > > While implementing OPA I reread what HTTP status code 406 Not Acceptable > means: > > http://rfc.net/rfc2616.html#s10.4.7 > > "The resource identified by the request is only capable of generating > response entities which have content characteristics not acceptable > according to the accept headers sent in the request." > > Note that we are not currently addressing accept headers in unAPI > (not that it hasn't come up :). > > Perhaps it would be better to use HTTP 415 Unsupported Media Type: > > http://rfc.net/rfc2616.html#s10.4.16 > > "The server is refusing to service the request because the entity of > the request is in a format not supported by the requested resource > for the requested method." > > (Note that this does not even specify mime-type but rather the more > general-purpose "format".) > > > That seems like an exact match, and therefore better. I'll propose we > change that note, and thus the spec, to now read (where before it read > as in the first quote): > > "requests for a URI that is available on the server but for a format > that is not available for that URI should return status code 415 > Unsupported Media Type" > > > But, I have no idea if this matters to browsers/languages/etc. > > -Dan > > > -- > Daniel Chudnov > Yale Center for Medical Informatics > (203) 737-5789 > _______________________________________________ > gcs-pcs-list mailing list > gcs-pcs-list@cipolo.med.yale.edu > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list > > From daniel.chudnov at yale.edu Fri Mar 3 12:39:03 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Fri Mar 3 12:39:05 2006 Subject: [gcs-pcs-list] (possible) issue: what to do for redirects? Message-ID: <20060303173902.GD26227@sildin.med.yale.edu> I'm not sure if this is an unAPI issue or not. In OPA, requests for things like images in binary formats can be simply redirected to another site. See the flickr links here for examples: http://onebiglibrary.net/project/opa/opa-0.2-release-with-json-wrapper If you follow, for example, the flickr jpeg_Original format link, OPA will respond with 302 Found with the flickr URL in the Location: header, and clients (browsers, wget) will follow the Location header URL. e.g.: [dlc33@sildin tmp]$ wget "http://opa.onebiglibrary.net/?uri=http://flickr.com/photos/dchud/100544935/&format=jpeg_Original" --12:30:45-- http://opa.onebiglibrary.net/?uri=http://flickr.com/photos/dchud/100544935/&format=jpeg_Original => `index.html?uri=http:%2F%2Fflickr.com%2Fphotos%2Fdchud%2F100544935%2F&format=jpeg_Original' Resolving opa.onebiglibrary.net... 207.210.245.105 Connecting to opa.onebiglibrary.net|207.210.245.105|:80... connected. HTTP request sent, awaiting response... 302 Found Location: http://static.flickr.com/32/100544935_ac537ae9e5_o.jpg [following] --12:30:50-- http://static.flickr.com/32/100544935_ac537ae9e5_o.jpg => `100544935_ac537ae9e5_o.jpg' Resolving static.flickr.com... 68.142.213.135 Connecting to static.flickr.com|68.142.213.135|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 1,357,967 (1.3M) [image/jpeg] 100%[====================================>] 1,357,967 453.28K/s 12:30:53 (451.83 KB/s) - `100544935_ac537ae9e5_o.jpg' saved [1357967/1357967] [dlc33@sildin tmp]$ file 100544935_ac537ae9e5_o.jpg 100544935_ac537ae9e5_o.jpg: JPEG image data, EXIF standard 2.2 At first, OPA was returning 301 Moved Permanently but that didn't seem right as it hadn't "moved" at all. 302 Found seemed better. Admittedly, OPA is a weird application, seeing as it's a proxy, but it still raises the questions: - Is the redirection response within the scope of unAPI? - If so, should we standardize the suggested HTTP status code(s)? - If so, is 302 Found correct? - Is it wrong for OPA to use a redirect here? i.e. would it be more appropriate for OPA (as an unAPI service) to fetch the remote data itself, and return *that* to the user directly, with the correct content-type and a 200 code? This one is hurting my brain, I have no idea what the answers are. -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From Peter.Binkley at ualberta.ca Fri Mar 3 14:29:21 2006 From: Peter.Binkley at ualberta.ca (Binkley, Peter) Date: Fri Mar 3 14:36:42 2006 Subject: [gcs-pcs-list] call to vote: table the URI debate Message-ID: <908893006339C0409519E4065DF3B2490157109D@mailserver.ualibrary.ualberta.ca> +1 Peter Binkley Digital Initiatives Technology Librarian Information Technology Services 4-30 Cameron Library University of Alberta Libraries Edmonton, Alberta Canada T6G 2J8 Phone: (780) 492-3743 Fax: (780) 492-9243 e-mail: peter.binkley@ualberta.ca -----Original Message----- From: gcs-pcs-list-bounces@cipolo.med.yale.edu [mailto:gcs-pcs-list-bounces@cipolo.med.yale.edu] On Behalf Of Daniel Chudnov Sent: Wednesday, March 01, 2006 2:45 PM To: gcs-pcs-list@cipolo.med.yale.edu Subject: [gcs-pcs-list] call to vote: table the URI debate We could keep debating the URI vs. not-URI thing for another two weeks, but then we'd stay distracted from addressing other pressing issues in the meantime. So: SEEING AS many of us are keenly interested in resolving (he-heh... I said "resolving") this debate, and; SEEING AS there are many other issues to address that are arguably far simpler and, thus, more likely to be quickly resolved (heh), and; SEEING AS we all want to keep pushing forward, and; SEEING AS many of us have previously gone 15 rounds of heavyweight slugging with the identifier demon before and lived to swear vilely about it, but; SEEING AS ALSO how important this is to be sure we decide on before we're done; BE IT PROPOSED that we should table the identifier debate until after the next revision or after such time has passed that a number of interesting new unAPI-driven applications make it easier to weigh the options based on real code and not our hard-won (or, in my case, lost) biases, and; BE IT DECIDED that we will leave the spec unchanged, for now, on the topic of what we mean by "URI" and "identifier", but; LET IT NOT BE FORGOTTEN that this is of critical importance and to be taken up again soon, as so stated in the previous-by-two paragraph. What say? -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 _______________________________________________ gcs-pcs-list mailing list gcs-pcs-list@cipolo.med.yale.edu http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list From liu_x at lanl.gov Fri Mar 3 14:41:02 2006 From: liu_x at lanl.gov (Xiaoming Liu) Date: Fri Mar 3 14:40:27 2006 Subject: [gcs-pcs-list] call to vote: table the URI debate In-Reply-To: <908893006339C0409519E4065DF3B2490157109D@mailserver.ualibrary.ualberta.ca> References: <908893006339C0409519E4065DF3B2490157109D@mailserver.ualibrary.ualberta.ca> Message-ID: +1 > > -----Original Message----- > From: gcs-pcs-list-bounces@cipolo.med.yale.edu > [mailto:gcs-pcs-list-bounces@cipolo.med.yale.edu] On Behalf Of Daniel > Chudnov > Sent: Wednesday, March 01, 2006 2:45 PM > To: gcs-pcs-list@cipolo.med.yale.edu > Subject: [gcs-pcs-list] call to vote: table the URI debate > > We could keep debating the URI vs. not-URI thing for another two weeks, > but then we'd stay distracted from addressing other pressing issues in > the meantime. So: > > SEEING AS many of us are keenly interested in resolving (he-heh... I > said > "resolving") this debate, and; > > SEEING AS there are many other issues to address that are arguably far > simpler and, thus, more likely to be quickly resolved (heh), and; > > SEEING AS we all want to keep pushing forward, and; > > SEEING AS many of us have previously gone 15 rounds of heavyweight > slugging with the identifier demon before and lived to swear vilely > about it, but; > > SEEING AS ALSO how important this is to be sure we decide on before > we're > done; > > BE IT PROPOSED that we should table the identifier debate until after > the > next revision or after such time has passed that a number of interesting > new unAPI-driven applications make it easier to weigh the options based > on real code and not our hard-won (or, in my case, lost) biases, and; > > BE IT DECIDED that we will leave the spec unchanged, for now, on the > topic of what we mean by "URI" and "identifier", but; > > LET IT NOT BE FORGOTTEN that this is of critical importance and to be > taken up again soon, as so stated in the previous-by-two paragraph. > > What say? > > -Dan > > > From mrylander at gmail.com Fri Mar 3 15:46:36 2006 From: mrylander at gmail.com (Mike Rylander) Date: Fri Mar 3 15:47:40 2006 Subject: [gcs-pcs-list] (possible) issue: what to do for redirects? In-Reply-To: <20060303173902.GD26227@sildin.med.yale.edu> References: <20060303173902.GD26227@sildin.med.yale.edu> Message-ID: On 3/3/06, Daniel Chudnov wrote: > I'm not sure if this is an unAPI issue or not. > > In OPA, requests for things like images in binary formats can be > simply redirected to another site. See the flickr links here for > examples: > > http://onebiglibrary.net/project/opa/opa-0.2-release-with-json-wrapper > > If you follow, for example, the flickr jpeg_Original format link, OPA > will respond with 302 Found with the flickr URL in the Location: header, > and clients (browsers, wget) will follow the Location header URL. e.g.: > > [dlc33@sildin tmp]$ wget "http://opa.onebiglibrary.net/?uri=http://flickr.com/photos/dchud/100544935/&format=jpeg_Original" > --12:30:45-- http://opa.onebiglibrary.net/?uri=http://flickr.com/photos/dchud/100544935/&format=jpeg_Original > => `index.html?uri=http:%2F%2Fflickr.com%2Fphotos%2Fdchud%2F100544935%2F&format=jpeg_Original' > Resolving opa.onebiglibrary.net... 207.210.245.105 > Connecting to opa.onebiglibrary.net|207.210.245.105|:80... connected. > HTTP request sent, awaiting response... 302 Found > Location: http://static.flickr.com/32/100544935_ac537ae9e5_o.jpg [following] > --12:30:50-- http://static.flickr.com/32/100544935_ac537ae9e5_o.jpg > => `100544935_ac537ae9e5_o.jpg' > Resolving static.flickr.com... 68.142.213.135 > Connecting to static.flickr.com|68.142.213.135|:80... connected. > HTTP request sent, awaiting response... 200 OK > Length: 1,357,967 (1.3M) [image/jpeg] > > 100%[====================================>] 1,357,967 453.28K/s > > 12:30:53 (451.83 KB/s) - `100544935_ac537ae9e5_o.jpg' saved [1357967/1357967] > > [dlc33@sildin tmp]$ file 100544935_ac537ae9e5_o.jpg > 100544935_ac537ae9e5_o.jpg: JPEG image data, EXIF standard 2.2 > > > At first, OPA was returning 301 Moved Permanently but that didn't > seem right as it hadn't "moved" at all. 302 Found seemed better. > > Admittedly, OPA is a weird application, seeing as it's a proxy, but > it still raises the questions: > > - Is the redirection response within the scope of unAPI? unAPI is fibbing a little about the direct response type in the , but if the ultimate endpoint is what the said then I think it's OK. > - If so, should we standardize the suggested HTTP status code(s)? I think HTTP does a good job of that, personally. If the item used to live at the URL that unAPI pointed you at, but some other system is actually responsible for actually producing/delivering the content and it really did move, I think a 301 would be correct. > - If so, is 302 Found correct? For your case (and mine; my "opac" format which also uses a 302 to send you to the right place), I vote yes. If working code wins, and we both have idependently implemented similar redirect schemes, then there's the pudding full of proof. :) > > - Is it wrong for OPA to use a redirect here? i.e. would it be more > appropriate for OPA (as an unAPI service) to fetch the remote data > itself, and return *that* to the user directly, with the correct > content-type and a 200 code? > It seems to me that this would put unduly heavy requirements on the unAPI server. If we're depending on HTTP response codes to figure out what's going on, we should depend on them to get us to the endpoint as well ... IMHO :) > This one is hurting my brain, I have no idea what the answers are. > > -Dan > > > -- > Daniel Chudnov > Yale Center for Medical Informatics > (203) 737-5789 > _______________________________________________ > gcs-pcs-list mailing list > gcs-pcs-list@cipolo.med.yale.edu > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list > -- Mike Rylander mrylander@gmail.com GPLS -- PINES Development Database Developer http://open-ils.org From daniel.chudnov at yale.edu Fri Mar 3 16:23:34 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Fri Mar 3 16:23:36 2006 Subject: [gcs-pcs-list] test suite. Message-ID: <20060303212334.GK26227@sildin.med.yale.edu> Does anybody here know selenium: http://www.openqa.org/selenium/ (...or something like it?) An *awesome* project would be an in-browser test suite for unAPI service developers (said the unAPI service developer who isn't 100% certain if his app is meeting the spec...). Or, actually, any unAPI test suite would be cool, too: just point it at some page in your webapp that has at least one unapi-uri and see if it will do all the stuff you expect. -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From ehs at pobox.com Fri Mar 3 16:32:16 2006 From: ehs at pobox.com (Ed Summers) Date: Fri Mar 3 16:33:23 2006 Subject: [gcs-pcs-list] test suite. In-Reply-To: <20060303212334.GK26227@sildin.med.yale.edu> References: <20060303212334.GK26227@sildin.med.yale.edu> Message-ID: > Or, actually, any unAPI test suite would be cool, too: just point > it at some page in your webapp that has at least one unapi-uri and > see if it will do all the stuff you expect. I'm willing to try this. Can you sketch out what you would want it to exercise and check? I could start out with a simple command line app, and then put it behind a web app if you want. //Ed From daniel.chudnov at yale.edu Fri Mar 3 16:44:46 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Fri Mar 3 16:44:51 2006 Subject: [gcs-pcs-list] test suite. In-Reply-To: References: <20060303212334.GK26227@sildin.med.yale.edu> Message-ID: <20060303214446.GL26227@sildin.med.yale.edu> Ed Summers wrote, on Fri, Mar 03, 2006 at 03:32:16PM -0600: > > Or, actually, any unAPI test suite would be cool, too: just point > > it at some page in your webapp that has at least one unapi-uri and > > see if it will do all the stuff you expect. > > I'm willing to try this. Can you sketch out what you would want it to > exercise and check? Hooray for edsu! :) I *think* the simplest thing that might work would be: - A commandline app or web form into which you could paste a url (alternately a bookmarklet that would send the current page in) - The url should be a web page with at least one unAPI unapi-uri span element and the unAPI link element. - If there's no unapi-uri, but there is a unAPI link element, check that the UNAPI? formats response is correct and stop - If there's no link element, indicate the error and stop - Check that the following works: - The UNAPI? formats response is correct (xml pattern and 300 code) - The UNAPI?uri=URI response is correct (xml pattern and 300 code) - For each format listed in UNAPI?uri=URI, verify that the response headers are as advertised (esp. mime-type) - Check that the following fail correctly: - Some bad UNAPI request (e.g. UNAPI?format=FORMAT) should return 400 - Make up a bad URI (info:bad-uri/BAD!-BAD!-BAD! :) and UNAPI?uri=URI should return a 404 - For a good URI (one you discover in a unapi-uri span) try a format that isn't listed; should return a 415 > I could start out with a simple command line app, and then put it > behind a web app if you want. Any working start on any of this would be way cool. Style points for AJAX whiz-bang and slick CSS layout will not be included in the final judging (we can always add that later :P). -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From liu_x at lanl.gov Fri Mar 3 16:46:47 2006 From: liu_x at lanl.gov (Xiaoming Liu) Date: Fri Mar 3 16:46:13 2006 Subject: [gcs-pcs-list] test suite. In-Reply-To: References: <20060303212334.GK26227@sildin.med.yale.edu> Message-ID: On Fri, 3 Mar 2006, Ed Summers wrote: >> Or, actually, any unAPI test suite would be cool, too: just point >> it at some page in your webapp that has at least one unapi-uri and >> see if it will do all the stuff you expect. > > I'm willing to try this. Can you sketch out what you would want it to > exercise and check? > > I could start out with a simple command line app, and then put it > behind a web app if you want. Maybe you can borrow some from Hussein's repository explorer for OAI-PMH? although his service doesn't seem stable now. It is a c implementation and cgi front end. The unapi_link greasymonkey script can be useful to play with unapi service, but it doesn't do any validation. http://lxming.blogspot.com/2006/02/unapilink-script-to-add-unapi-links.html xiaoming > > //Ed > _______________________________________________ > gcs-pcs-list mailing list > gcs-pcs-list@cipolo.med.yale.edu > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list > From leftwing at alumni.rutgers.edu Fri Mar 3 17:05:54 2006 From: leftwing at alumni.rutgers.edu (Michael J. Giarlo) Date: Fri Mar 3 17:06:57 2006 Subject: [gcs-pcs-list] call to vote: table the URI debate In-Reply-To: References: <908893006339C0409519E4065DF3B2490157109D@mailserver.ualibrary.ualberta.ca> Message-ID: <22dbc4ae0603031405s5498a62cv83646c07955a77ed@mail.gmail.com> +1 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://cipolo.med.yale.edu/pipermail/gcs-pcs-list/attachments/20060303/6b53e677/attachment.htm From eric at openly.com Fri Mar 3 18:14:26 2006 From: eric at openly.com (Eric Hellman) Date: Fri Mar 3 18:18:16 2006 Subject: [gcs-pcs-list] usability of the unAPI specs, other comments In-Reply-To: <20060303164058.GB26227@sildin.med.yale.edu> References: <20060303164058.GB26227@sildin.med.yale.edu> Message-ID: For reasons of having lots on my plate recently, I've not been following the discussion of unAPI in detail, and I have only today been able to study the spec. Here are my comments. Please forgive me if I have missed previous discussion, I hope my perspective properly simulates someone coming to the spec afresh, as those are the people you have to write for. just a few notes on usability of the unAPI spec. 1. the unapi spec documents are undated- please annotate them with the date they were published 2. each spec should link back to the previous version of the spec 3. http://www.code4lib.org/specs/unapi/ should list all version of the spec somehow. http://www.code4lib.org/specs/unapi/current should alias to current version. 4. there is no author or contact information in the dpec document - if the gcs-pcs list is to be considered the author, then it should say that; anonymous shouldn't use the royal we. 5. In the interests of being accessible to the "rest of the world", the name needs to be explained or at least meaning disclaimed. "Universal API?" 6. "microformat" is not explained. there should be a link. 7. please add html name anchors so that links to spec can reference fragments 8. please replace curly quotes in quoted code with straight quotes. comments on the technical content A URI microformat 1. as in COinS spec, should warn against empty spans 2. considering functional overlap, should probably reference COinS as an alternative for richer metadata embedding; COinS spec would return the favor citiing unAPI as a "lighter weight" embedding method. 3. info uri is not a "rest of the world" thing yet; should add an explanatory link 4. The uninitiated will want to know why not : PMID 12345678 5. If I may be forgiven for commenting after the subject is tabled, using a real URI as current has the advantage of retaining compatibility with OpenURL, which I think is a good thing. There is nothing to be won (in terms of compliance with a potential OpenURL Profile for unAPI transport) by changing the class name or adding a version identifier. It can compatible as is, with no changes. not using a real URI would break this, however. An autodiscovery link pointing to an appropriate unAPI service 1. I continue to be worried about web pages that want to use more than one metadata server. For example, how about allowing and in the body: PMID 12345678 ISBN 123456789X this would make it easier for metadata providers to specialize and potentially lift one barrier to implementation and propagation. HTTP interface functions 1. I am confused about the function of oai_dc are these random tokens, are they a controlled vocabulary? If these are meant to be machine readable, then a list or registry of standard name tokens is desirable. From farther down, I understand that these are really meant to be format-handles. if so, then only mimetype is guaranteed as informing usage. I guess this is ok. It would help readability if this functionality were disclosed immediately when introduced. 2. I trust there will be a real schema 3. when a metadata server sends back xml document which uses more than one schema, it be possible to report multiple schemas in one formats? Or is it to be forbidden to send back this sort of metadata? 4. "URIs in unAPI HTTP calls must be url-encoded". This is ambiguous. What sort of URIs are not url encoded? I presume you mean they must be doubly encoded. 5. Why does the spec say to redirect to the object instead of simply returning the object? Why does it matter? 6. Why should the UNAPI ?uri=URI function should return status code 300 Multiple Choices if there are 0 or one choices. 7. is zero metadata choices the same as object not found? 8. suppose a metadata server is set up to serve privileged users with privileged formats; I assume the usual http status codes would apply. Bottom line; based on my reading the current spec we would probably want to add unAPI client capability to OpenURL referrer; this would certainly help to drive OpenURL 1.0 link-server adoption, which of course is what we care about. -- Eric Hellman, Director OCLC Openly Informatics Division eric@openly.com 2 Broad St., Suite 208 tel 1-973-509-7800 fax 1-734-468-6216 Bloomfield, NJ 07003 http://www.openly.com/1cate/ 1 Click Access To Everything From liu_x at lanl.gov Fri Mar 3 22:20:47 2006 From: liu_x at lanl.gov (Xiaoming Liu) Date: Fri Mar 3 22:20:12 2006 Subject: [gcs-pcs-list] (possible) issue: what to do for redirects? In-Reply-To: <20060303173902.GD26227@sildin.med.yale.edu> References: <20060303173902.GD26227@sildin.med.yale.edu> Message-ID: Dan, I have been a little hesitant about this and 406 issue, I wonder if we are getting too smart of dealing with http response code, for several reasons: a) it's hard to get all correct. b) it may distract implementation and other important topics (such as Eric's comments). c) it makes implementation difficult. Here I suggest we have a look atom publishing protocol's approach, see section 5.5 of atom publishing protocol (http://www.ietf.org/internet-drafts/draft-ietf-atompub-protocol-08.txt) 5.5 Use of HTTP Response codes The Atom Protocol uses the response status codes defined in HTTP to indicate the success or failure of an operation. Consult the HTTP specification [RFC2616] for detailed definitions of each status code. It is RECOMMENDED that entities contained within HTTP 4xx and 5xx responses include an explanation of the error using natural language. I am prone to Atom's approach. I would vote 0 for 406 issue. xiaoming On Fri, 3 Mar 2006, Daniel Chudnov wrote: > I'm not sure if this is an unAPI issue or not. > > In OPA, requests for things like images in binary formats can be > simply redirected to another site. See the flickr links here for > examples: > > http://onebiglibrary.net/project/opa/opa-0.2-release-with-json-wrapper > > If you follow, for example, the flickr jpeg_Original format link, OPA > will respond with 302 Found with the flickr URL in the Location: header, > and clients (browsers, wget) will follow the Location header URL. e.g.: > > [dlc33@sildin tmp]$ wget "http://opa.onebiglibrary.net/?uri=http://flickr.com/photos/dchud/100544935/&format=jpeg_Original" > --12:30:45-- http://opa.onebiglibrary.net/?uri=http://flickr.com/photos/dchud/100544935/&format=jpeg_Original > => `index.html?uri=http:%2F%2Fflickr.com%2Fphotos%2Fdchud%2F100544935%2F&format=jpeg_Original' > Resolving opa.onebiglibrary.net... 207.210.245.105 > Connecting to opa.onebiglibrary.net|207.210.245.105|:80... connected. > HTTP request sent, awaiting response... 302 Found > Location: http://static.flickr.com/32/100544935_ac537ae9e5_o.jpg [following] > --12:30:50-- http://static.flickr.com/32/100544935_ac537ae9e5_o.jpg > => `100544935_ac537ae9e5_o.jpg' > Resolving static.flickr.com... 68.142.213.135 > Connecting to static.flickr.com|68.142.213.135|:80... connected. > HTTP request sent, awaiting response... 200 OK > Length: 1,357,967 (1.3M) [image/jpeg] > > 100%[====================================>] 1,357,967 453.28K/s > > 12:30:53 (451.83 KB/s) - `100544935_ac537ae9e5_o.jpg' saved [1357967/1357967] > > [dlc33@sildin tmp]$ file 100544935_ac537ae9e5_o.jpg > 100544935_ac537ae9e5_o.jpg: JPEG image data, EXIF standard 2.2 > > > At first, OPA was returning 301 Moved Permanently but that didn't > seem right as it hadn't "moved" at all. 302 Found seemed better. > > Admittedly, OPA is a weird application, seeing as it's a proxy, but > it still raises the questions: > > - Is the redirection response within the scope of unAPI? > - If so, should we standardize the suggested HTTP status code(s)? > - If so, is 302 Found correct? > > - Is it wrong for OPA to use a redirect here? i.e. would it be more > appropriate for OPA (as an unAPI service) to fetch the remote data > itself, and return *that* to the user directly, with the correct > content-type and a 200 code? > > This one is hurting my brain, I have no idea what the answers are. > > -Dan > > > -- Xiaoming From liu_x at lanl.gov Fri Mar 3 23:06:24 2006 From: liu_x at lanl.gov (Xiaoming Liu) Date: Fri Mar 3 23:05:49 2006 Subject: [gcs-pcs-list] test suite. In-Reply-To: <20060303214446.GL26227@sildin.med.yale.edu> References: <20060303212334.GK26227@sildin.med.yale.edu> <20060303214446.GL26227@sildin.med.yale.edu> Message-ID: On Fri, 3 Mar 2006, Daniel Chudnov wrote: > Ed Summers wrote, on Fri, Mar 03, 2006 at 03:32:16PM -0600: >>> Or, actually, any unAPI test suite would be cool, too: just point >>> it at some page in your webapp that has at least one unapi-uri and >>> see if it will do all the stuff you expect. >> >> I'm willing to try this. Can you sketch out what you would want it to >> exercise and check? In OAI-PMH development, Alan Kent has some good input about testing and actually setup a nice site for this. Unfortunately the site has long gone, if you are interested, I just found several links: -- search oai-implementor email list, such as this one http://www.openarchives.org/pipermail/oai-implementers/2002-February/000347.html -- his SOAP test site is still available from archive.org http://web.archive.org/web/*/http://www.mds.rmit.edu.au/~ajk/soap/interop-results.htm -- and celestial has some similar flavor http://celestial.eprints.org/cgi-bin/status maybe these have some reference value. xiaoming > > Hooray for edsu! :) > > I *think* the simplest thing that might work would be: > > - A commandline app or web form into which you could paste a url > (alternately a bookmarklet that would send the current page in) > - The url should be a web page with at least one unAPI > unapi-uri span element and the unAPI link element. > - If there's no unapi-uri, but there is a unAPI link element, check > that the UNAPI? formats response is correct and stop > - If there's no link element, indicate the error and stop > - Check that the following works: > - The UNAPI? formats response is correct (xml pattern and 300 code) > - The UNAPI?uri=URI response is correct (xml pattern and 300 code) > - For each format listed in UNAPI?uri=URI, verify that the > response headers are as advertised (esp. mime-type) > - Check that the following fail correctly: > - Some bad UNAPI request (e.g. UNAPI?format=FORMAT) should return > 400 > - Make up a bad URI (info:bad-uri/BAD!-BAD!-BAD! :) and > UNAPI?uri=URI should return a 404 > - For a good URI (one you discover in a unapi-uri span) try a > format that isn't listed; should return a 415 > > >> I could start out with a simple command line app, and then put it >> behind a web app if you want. > > Any working start on any of this would be way cool. Style points for > AJAX whiz-bang and slick CSS layout will not be included in the final > judging (we can always add that later :P). > > -Dan > > > From eric at openly.com Sat Mar 4 00:18:39 2006 From: eric at openly.com (Eric Hellman) Date: Sat Mar 4 00:22:41 2006 Subject: [gcs-pcs-list] more comments Message-ID: An HTML attachment was scrubbed... URL: http://cipolo.med.yale.edu/pipermail/gcs-pcs-list/attachments/20060304/1ee6dc17/attachment.htm From jyoung at oclc.org Sat Mar 4 03:33:10 2006 From: jyoung at oclc.org (Young,Jeff (OR)) Date: Sat Mar 4 03:33:38 2006 Subject: [gcs-pcs-list] usability of the unAPI specs, other comments Message-ID: It occurs to me that we have crossed a threshold and no one noticed. OpenURL has opened an important door in our world and Dan was unlucky enough to be the first person since then to spout a clever idea. I think this is going to happen more and more, and we need to figure out a way to deal with it. Perhaps there is a business model here for OCLC to act as an intermediary. We already do this for OPAC deeplinks. This service could/should have been implemented as an OpenURL resolver anyway. The OpenURL gateway service is another. Now this. What next? Jeff ------Original Message------ From: Eric Hellman To: GCS-PCS list Sent: Mar 3, 2006 6:14 PM Subject: [gcs-pcs-list] usability of the unAPI specs, other comments For reasons of having lots on my plate recently, I've not been following the discussion of unAPI in detail, and I have only today been able to study the spec. Here are my comments. Please forgive me if I have missed previous discussion, I hope my perspective properly simulates someone coming to the spec afresh, as those are the people you have to write for. just a few notes on usability of the unAPI spec. 1. the unapi spec documents are undated- please annotate them with the date they were published 2. each spec should link back to the previous version of the spec 3. http://www.code4lib.org/specs/unapi/ should list all version of the spec somehow. http://www.code4lib.org/specs/unapi/current should alias to current version. 4. there is no author or contact information in the dpec document - if the gcs-pcs list is to be considered the author, then it should say that; anonymous shouldn't use the royal we. 5. In the interests of being accessible to the "rest of the world", the name needs to be explained or at least meaning disclaimed. "Universal API?" 6. "microformat" is not explained. there should be a link. 7. please add html name anchors so that links to spec can reference fragments 8. please replace curly quotes in quoted code with straight quotes. comments on the technical content A URI microformat 1. as in COinS spec, should warn against empty spans 2. considering functional overlap, should probably reference COinS as an alternative for richer metadata embedding; COinS spec would return the favor citiing unAPI as a "lighter weight" embedding method. 3. info uri is not a "rest of the world" thing yet; should add an explanatory link 4. The uninitiated will want to know why not : PMID 12345678 5. If I may be forgiven for commenting after the subject is tabled, using a real URI as current has the advantage of retaining compatibility with OpenURL, which I think is a good thing. There is nothing to be won (in terms of compliance with a potential OpenURL Profile for unAPI transport) by changing the class name or adding a version identifier. It can compatible as is, with no changes. not using a real URI would break this, however. An autodiscovery link pointing to an appropriate unAPI service 1. I continue to be worried about web pages that want to use more than one metadata server. For example, how about allowing and in the body: PMID 12345678 ISBN 123456789X this would make it easier for metadata providers to specialize and potentially lift one barrier to implementation and propagation. HTTP interface functions 1. I am confused about the function of oai_dc are these random tokens, are they a controlled vocabulary? If these are meant to be machine readable, then a list or registry of standard name tokens is desirable. From farther down, I understand that these are really meant to be format-handles. if so, then only mimetype is guaranteed as informing usage. I guess this is ok. It would help readability if this functionality were disclosed immediately when introduced. 2. I trust there will be a real schema 3. when a metadata server sends back xml document which uses more than one schema, it be possible to report multiple schemas in one formats? Or is it to be forbidden to send back this sort of metadata? 4. "URIs in unAPI HTTP calls must be url-encoded". This is ambiguous. What sort of URIs are not url encoded? I presume you mean they must be doubly encoded. 5. Why does the spec say to redirect to the object instead of simply returning the object? Why does it matter? 6. Why should the UNAPI ?uri=URI function should return status code 300 Multiple Choices if there are 0 or one choices. 7. is zero metadata choices the same as object not found? 8. suppose a metadata server is set up to serve privileged users with privileged formats; I assume the usual http status codes would apply. Bottom line; based on my reading the current spec we would probably want to add unAPI client capability to OpenURL referrer; this would certainly help to drive OpenURL 1.0 link-server adoption, which of course is what we care about. -- Eric Hellman, Director OCLC Openly Informatics Division eric@openly.com 2 Broad St., Suite 208 tel 1-973-509-7800 fax 1-734-468-6216 Bloomfield, NJ 07003 http://www.openly.com/1cate/ 1 Click Access To Everything _______________________________________________ gcs-pcs-list mailing list gcs-pcs-list@cipolo.med.yale.edu http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list Sent from my Blackberry Wireless Handheld OCLC Online Computer Library Center, Inc. From lists at hubmed.org Sat Mar 4 10:49:57 2006 From: lists at hubmed.org (Alf Eaton) Date: Sat Mar 4 10:53:11 2006 Subject: [gcs-pcs-list] on using URIs In-Reply-To: References: Message-ID: <24A87470-AE38-4827-B3F0-4BEA3308BE19@hubmed.org> On 03 Mar 2006, at 11:45, Young,Jeff (OR) wrote: > I've whittled the difference down to two lines of code. If that must > stand between us, so be it. Was it these two lines?: RewriteEngine On RewriteRule /unapi\?url_ver= Z39.88-2004&rft_id=(.*?) &url_ctx_fmt=ori:fmt:kev:mtx:ctx /unapi?id=$1 [R=301,L,NE] alf. From mrylander at gmail.com Sat Mar 4 10:57:28 2006 From: mrylander at gmail.com (Mike Rylander) Date: Sat Mar 4 10:58:34 2006 Subject: [gcs-pcs-list] on using URIs In-Reply-To: <24A87470-AE38-4827-B3F0-4BEA3308BE19@hubmed.org> References: <24A87470-AE38-4827-B3F0-4BEA3308BE19@hubmed.org> Message-ID: On 3/4/06, Alf Eaton wrote: > > On 03 Mar 2006, at 11:45, Young,Jeff (OR) wrote: > > > I've whittled the difference down to two lines of code. If that must > > stand between us, so be it. > > Was it these two lines?: > > RewriteEngine On > RewriteRule /unapi\?url_ver= Z39.88-2004&rft_id=(.*?) > &url_ctx_fmt=ori:fmt:kev:mtx:ctx /unapi?id=$1 [R=301,L,NE] > > alf. Alf++ ;) > _______________________________________________ > gcs-pcs-list mailing list > gcs-pcs-list@cipolo.med.yale.edu > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list > -- Mike Rylander mrylander@gmail.com GPLS -- PINES Development Database Developer http://open-ils.org From daniel.chudnov at yale.edu Sun Mar 5 13:09:15 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Sun Mar 5 13:09:17 2006 Subject: [gcs-pcs-list] call to vote: table the URI debate In-Reply-To: <22dbc4ae0603031405s5498a62cv83646c07955a77ed@mail.gmail.com> References: <908893006339C0409519E4065DF3B2490157109D@mailserver.ualibrary.ualberta.ca> <22dbc4ae0603031405s5498a62cv83646c07955a77ed@mail.gmail.com> Message-ID: <20060305180915.GD3728@sildin.med.yale.edu> This issue is - most emphatically - tabled until, at least, rev2, or until we have working code that brings the issues into clearer focus. Thanks, -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From eric at openly.com Sun Mar 5 14:35:35 2006 From: eric at openly.com (Eric Hellman) Date: Sun Mar 5 14:39:26 2006 Subject: [gcs-pcs-list] more comments (plain text) Message-ID: (resent in plain text at request of list members) Now that I've had a chance to digest the spec and start to plan an implementation, I see more issues that could make it difficult to write good code, mainly in the area labeled "error handling". 1. silly injunction against non-unAPI parameters # requests with non-unAPI parameters or an invalid combination of unAPI parameters (e.g. "UNAPI?format=FORMAT") should return status code 400 Bad Request - this prevents me from doing stuff like invoking a test mode in my unAPI server with an additional parameter. in OpenURL we set aside _parameters for this. -makes future versions of unAPI incompatible 2. modality of response to UNAPI?uri=URI requests. channel modality is generally to be avoided in well designed protocols. If I ask a question, it should be reasonable to get the answer back in a single language which should not depend on the answer. If I ask "what kind of soup do you have today" the answer should be "chicken noodle" or "sorry, no soup today". Using French only if there is no soup makes no sense. When I build an client for an XML service, I delegate the message handling to an XML Processor (usually with XSLT doing most of the work). The processor will throw an exception if the response is not well formed xml; this is usually because a service is broken. If I have to listen for a 404 response just in case there are no available format for an item, or if the item is unknown, then I can't handle that inside the XML processor. As the spec is currently written, it is not clear whether anything is to be sent in the body of the 404 response. It's not clear if client could rely on receiving a well-formed xml body message along with the 404 header . whatever the HTTP response codes are, I think that, to make it easier to develop robust clients, an unAPI response to a UNAPI?uri=URI request should ALWAYS be well formed XML. When no metadata object is unavailable the body of the 404 response should be: info:sid/example.com/12345 3. those response codes As for the use of http response codes, the use of http code 300 looks bogus to me- shouldn't that be used for http content negotiation? If someone used an http client stack that supported http content negotiation, wouldn't this break? I admit it's bee a while since I looked at the http spec, but really if this is what is desired, then the unAPI spec needs to explain to the reader why these odd codes are used. -- Eric Hellman, Director OCLC Openly Informatics Division eric@openly.com 2 Broad St., Suite 208 tel 1-973-509-7800 fax 1-734-468-6216 Bloomfield, NJ 07003 http://www.openly.com/1cate/ 1 Click Access To Everything From daniel.chudnov at yale.edu Sun Mar 5 16:01:04 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Sun Mar 5 16:01:06 2006 Subject: [gcs-pcs-list] (possible) issue: what to do for redirects? In-Reply-To: References: <20060303173902.GD26227@sildin.med.yale.edu> Message-ID: <20060305210103.GF3728@sildin.med.yale.edu> Mike Rylander wrote, on Fri, Mar 03, 2006 at 08:46:36PM +0000: > On 3/3/06, Daniel Chudnov wrote: > > - Is it wrong for OPA to use a redirect here? i.e. would it be more > > appropriate for OPA (as an unAPI service) to fetch the remote data > > itself, and return *that* to the user directly, with the correct > > content-type and a 200 code? > > It seems to me that this would put unduly heavy requirements on the > unAPI server. If we're depending on HTTP response codes to figure out > what's going on, we should depend on them to get us to the endpoint as > well ... IMHO :) Indeed. I can live with this as-is, then. Happily. :) The only caveat being (though it's really a separate case) in other OPA examples like the generic OAI-PMH proxy, the unAPI service (OPA) should do the heavy lifting of liberating the record from the OAI-PMH wrapper and returning just the plain record/object directly. -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From daniel.chudnov at yale.edu Sun Mar 5 16:04:40 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Sun Mar 5 16:04:42 2006 Subject: [gcs-pcs-list] (possible) issue: what to do for redirects? In-Reply-To: References: <20060303173902.GD26227@sildin.med.yale.edu> Message-ID: <20060305210440.GG3728@sildin.med.yale.edu> Xiaoming Liu wrote, on Fri, Mar 03, 2006 at 08:20:47PM -0700: > > I have been a little hesitant about this and 406 issue, I wonder if we are > getting too smart of dealing with http response code, for several > reasons: > > a) it's hard to get all correct. > b) it may distract implementation and other important topics (such as > Eric's comments). > c) it makes implementation difficult. I think through implementations and intensive discussion we're finding out the most correct way. I don't see "deferring as much as possible to HTTP" as a distraction, but rather as an objective, and a result many potential developers would prefer. How does it make implementation difficult? > Here I suggest we have a look atom publishing protocol's approach, see > section 5.5 of atom publishing protocol > (http://www.ietf.org/internet-drafts/draft-ietf-atompub-protocol-08.txt) > > 5.5 Use of HTTP Response codes > > The Atom Protocol uses the response status codes defined in HTTP to > indicate the success or failure of an operation. Consult the HTTP > specification [RFC2616] for detailed definitions of each status code. > It is RECOMMENDED that entities contained within HTTP 4xx and 5xx > responses include an explanation of the error using natural language. > > I am prone to Atom's approach. How is this different from our approach? In that perhaps we're specifying even more than we should? Or that we should recommend a natural language explanation as well? Sorry if I'm just missing your point here. We're deferring to HTTP status codes as much as possible, too. -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From daniel.chudnov at yale.edu Sun Mar 5 16:09:06 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Sun Mar 5 16:09:07 2006 Subject: [gcs-pcs-list] usability of the unAPI specs, other comments In-Reply-To: References: <20060303164058.GB26227@sildin.med.yale.edu> Message-ID: <20060305210906.GH3728@sildin.med.yale.edu> It's great to get your input, Eric. :) Most of these are good points, but it's too many to address in one thread. If you don't mind me breaking it up some... Eric Hellman wrote, on Fri, Mar 03, 2006 at 06:14:26PM -0500: > > just a few notes on usability of the unAPI spec. > > 1. the unapi spec documents are undated- please annotate them with > the date they were published > 2. each spec should link back to the previous version of the spec > 3. http://www.code4lib.org/specs/unapi/ should list all version of > the spec somehow. http://www.code4lib.org/specs/unapi/current should > alias to current version. > 4. there is no author or contact information in the dpec document - > if the gcs-pcs list is to be considered the author, then it should > say that; anonymous shouldn't use the royal we. All good points. I'm getting started on this. > 5. In the interests of being accessible to the "rest of the world", > the name needs to be explained or at least meaning disclaimed. > "Universal API?" It's not "Universal API". Just "unAPI". I started an FAQ and hope to have a draft written for release with the next revision. There's a "what's with the name?" Q in it. > 6. "microformat" is not explained. there should be a link. > 7. please add html name anchors so that links to spec can reference > fragments > 8. please replace curly quotes in quoted code with straight quotes. Right, easy fixes. -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From daniel.chudnov at yale.edu Sun Mar 5 16:26:56 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Sun Mar 5 16:26:58 2006 Subject: [gcs-pcs-list] more comments (plain text) In-Reply-To: References: Message-ID: <20060305212656.GI3728@sildin.med.yale.edu> Eric Hellman wrote, on Sun, Mar 05, 2006 at 02:35:35PM -0500: > (resent in plain text at request of list members) (thank you :) > 1. silly injunction against non-unAPI parameters > > # requests with non-unAPI parameters or an invalid combination of > unAPI parameters (e.g. "UNAPI?format=FORMAT") should return status > code 400 Bad Request > > - this prevents me from doing stuff like invoking a test mode in my > unAPI server with an additional parameter. in OpenURL we set aside > _parameters for this. It says "should", not "must". Nothing in how it is written prevents you from experimenting with new paramaters or a test mode on your own server. > -makes future versions of unAPI incompatible Who said anything about future versions? :) > 2. modality of response to UNAPI?uri=URI requests. Your point about how a URI 404 should have a body like this: info:sid/example.com/12345 Is a good one. I'll flag it for a vote. But: > When I build an client for an XML service, I delegate the message > handling to an XML Processor (usually with XSLT doing most of the > work). The processor will throw an exception if the response is not > well formed xml; this is usually because a service is broken. If I > have to listen for a 404 response just in case there are no available > format for an item, or if the item is unknown, then I can't handle > that inside the XML processor. I hear you, but there's a deeper issue: the XML modality is layered over the HTTP modality. HTTP is the common modality across all of unAPI; some responses are XML, not all (indeed responses can be any type). So your client should start by watching HTTP status codes, then handing off to the XML processor, no? > 3. those response codes > > As for the use of http response codes, the use of http code 300 looks > bogus to me- shouldn't that be used for http content negotiation? If > someone used an http client stack that supported http content > negotiation, wouldn't this break? I admit it's bee a while since I > looked at the http spec, but really if this is what is desired, then > the unAPI spec needs to explain to the reader why these odd codes are > used. Reviewing the RFC: http://rfc.net/rfc2616.html#p61 "The requested resource corresponds to any one of a set of representations, each with its own specific location, and agent-driven negotiation information (section 12) is being provided so that the user (or user agent) can select a preferred representation and redirect its request to that location. ...selection of the most appropriate choice MAY be performed automatically." RFC 2295 specifies transparent content negotation, which we've found to be (in its entirety) complex and more than what we need. But, unless I'm mistaken, nothing in what unAPI specifies so far prohibits the layering of transparent negotiation over the server-side (using RFC 2295-style headers, perhaps) or from the client side. -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From daniel.chudnov at yale.edu Sun Mar 5 16:31:03 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Sun Mar 5 16:31:04 2006 Subject: [gcs-pcs-list] new issue: is 406 correct? In-Reply-To: <23b83f160603030928u3aa6ca96hec29d9bee32cb285@mail.gmail.com> References: <20060302201431.GA17286@sildin.med.yale.edu> <23b83f160603030928u3aa6ca96hec29d9bee32cb285@mail.gmail.com> Message-ID: <20060305213103.GJ3728@sildin.med.yale.edu> Ross Singer wrote, on Fri, Mar 03, 2006 at 12:28:47PM -0500: > +1 These 4 +1s and Xiaoming's 0 add up to 5 votes, +4 and no dissent. It passes! s/406/415/. -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From liu_x at lanl.gov Mon Mar 6 02:15:29 2006 From: liu_x at lanl.gov (Xiaoming Liu) Date: Mon Mar 6 02:14:50 2006 Subject: [gcs-pcs-list] (possible) issue: what to do for redirects? In-Reply-To: <20060305210440.GG3728@sildin.med.yale.edu> References: <20060303173902.GD26227@sildin.med.yale.edu> <20060305210440.GG3728@sildin.med.yale.edu> Message-ID: On Sun, 5 Mar 2006, Daniel Chudnov wrote: > >> Here I suggest we have a look atom publishing protocol's approach, see >> section 5.5 of atom publishing protocol >> (http://www.ietf.org/internet-drafts/draft-ietf-atompub-protocol-08.txt) >> >> 5.5 Use of HTTP Response codes >> >> The Atom Protocol uses the response status codes defined in HTTP to >> indicate the success or failure of an operation. Consult the HTTP >> specification [RFC2616] for detailed definitions of each status code. >> It is RECOMMENDED that entities contained within HTTP 4xx and 5xx >> responses include an explanation of the error using natural language. >> >> I am prone to Atom's approach. > > How is this different from our approach? In that perhaps we're specifying > even more than we should? Or that we should recommend a natural language > explanation as well? Sorry if I'm just missing your point here. > > We're deferring to HTTP status codes as much as possible, too. sorry I didn't put my point clearly. My understanding is that APP leaves the choice of error processing to implementors, thereforer avoid explicitly defining error code in the protocol, e.g. in the previous discussion about 406 vs. 415, an implementor can decide either return 406, 415, or even straight 400. I am not an APP expert so any explanation is my best guess. I think APP's approach has following advantage: (1) make the implementation simple. The server and client are not burdened with special eror processing code. (2) shorten specification. By defering all error processing to HTTP protocol. (3) avoid future bloating unapi with error code look at the HTTP 400/500 series code, several more might be applicable to our case, such as 410 (gone) 403 (forbidden) 408 (request timeout), 500 (server error) 503 (service unavailable), some of these are not completely under unapi's control. e.g. a 403 or 503 error might be created by apache. More practically, because most 400/500 errors need human intervene, no matter what error code is chosen, a human being has to figure out the problem. if so, a natual language explanation is the best choice. So my proposal is that we literally adopt APP's approach, how to define/implementat error code is up to server/client individual choice. An advanced server may use up all http 400/500 code, and an advanced client may try to interpret all of them. But the bottom line is that a server will generate an error code if it believes so, and a client should not silently ignore an error code. So one may choose an advanced or dummy implementation, but they are still unapi compliant. xiaoming From mrylander at gmail.com Mon Mar 6 08:32:17 2006 From: mrylander at gmail.com (Mike Rylander) Date: Mon Mar 6 08:33:21 2006 Subject: [gcs-pcs-list] (possible) issue: what to do for redirects? In-Reply-To: References: <20060303173902.GD26227@sildin.med.yale.edu> <20060305210440.GG3728@sildin.med.yale.edu> Message-ID: On 3/6/06, Xiaoming Liu wrote: > On Sun, 5 Mar 2006, Daniel Chudnov wrote: > > > > >> Here I suggest we have a look atom publishing protocol's approach, see > >> section 5.5 of atom publishing protocol > >> (http://www.ietf.org/internet-drafts/draft-ietf-atompub-protocol-08.txt) > >> > >> 5.5 Use of HTTP Response codes > >> > >> The Atom Protocol uses the response status codes defined in HTTP to > >> indicate the success or failure of an operation. Consult the HTTP > >> specification [RFC2616] for detailed definitions of each status code. > >> It is RECOMMENDED that entities contained within HTTP 4xx and 5xx > >> responses include an explanation of the error using natural language. > >> > >> I am prone to Atom's approach. > > > > How is this different from our approach? In that perhaps we're specifying > > even more than we should? Or that we should recommend a natural language > > explanation as well? Sorry if I'm just missing your point here. > > > > We're deferring to HTTP status codes as much as possible, too. > > sorry I didn't put my point clearly. My understanding is that APP leaves > the choice of error processing to implementors, thereforer avoid > explicitly defining error code in the protocol, e.g. in the previous > discussion about 406 vs. 415, an implementor can decide either return > 406, 415, or even straight 400. > > I am not an APP expert so any explanation is my best guess. I think APP's > approach has following advantage: > > (1) make the implementation simple. > The server and client are not burdened with special eror processing code. This may just be me, but "not burdened with special eror processing code" sounds like the opposite of "programming for failure". Programming for failure allows for a consistent user experience across all implementations and under all conditions, failure or success. Admittedly, I too need to take this advice, since my implementation is just punting when bad things happen. I think it's fine to build a prototype that doesn't fail gracefully, but, IMHO, we should actively encourage programmers interested in implementing unAPI to use a standard set of error codes (and non-error codes, for that matter) because it promotes cross-implementation portability, and it ends up making good clients easier to write because they only have to follow the spec and not know the implementation quirks of every "major" unAPI server. > > (2) shorten specification. > By defering all error processing to HTTP protocol. > I think we're already doing this, while also recommending the "best" code to use in each particular case that we've run into. > (3) avoid future bloating unapi with error code > look at the HTTP 400/500 series code, several more might be applicable to > our case, such as 410 (gone) 403 (forbidden) 408 (request timeout), 500 > (server error) 503 (service unavailable), some of these are not > completely under unapi's control. e.g. a 403 or 503 error might be created > by apache. > See above -- we are explicitly looking at HTTP, and trying to find the best, smallest set of error codes to use. > More practically, because most 400/500 errors need human intervene, no > matter what error code is chosen, a human being has to figure out the > problem. if so, a natual language explanation is the best choice. > > So my proposal is that we literally adopt APP's approach, how to > define/implementat error code is up to server/client individual choice. An > advanced server may use up all http 400/500 code, and an advanced client may try to > interpret all of them. But the bottom line is that a server will generate > an error code if it believes so, and a client should not silently ignore > an error code. So one may choose an advanced or dummy implementation, but > they are still unapi compliant. > Like I said, I think this is the spirit of what we're doing today. Here in the early stages of protocol and format development, however, I think it's a good idea to help server admins and implementers pick the best code for a particular situation. It may not be difficult for someone with lots of server side development experience to pick status codes that make sense (though it's obviously not trivial -- the HTTP spec is (necessarily) vague), but it certainly wouldn't hurt to give the "noobs" a helping hand in interpreting the HTTP status code spec. If we find that the "recommended status codes" list is indeed bloating the spec at some point, then I think it should be spun off into an auxiliary "best practices" document. But for the time being, having the knowledge of the "right" way to apply status codes right there at the bottom of the spec makes creating new implementations easier, and IMO encourages those new implementations to be more accessible to existing clients, since these new servers will fail in the same way as existing servers. > xiaoming > -- Mike Rylander mrylander@gmail.com GPLS -- PINES Development Database Developer http://open-ils.org From liu_x at lanl.gov Mon Mar 6 10:04:05 2006 From: liu_x at lanl.gov (Xiaoming Liu) Date: Mon Mar 6 10:03:25 2006 Subject: [gcs-pcs-list] (possible) issue: what to do for redirects? In-Reply-To: References: <20060303173902.GD26227@sildin.med.yale.edu> <20060305210440.GG3728@sildin.med.yale.edu> Message-ID: On Mon, 6 Mar 2006, Mike Rylander wrote: >> > > Like I said, I think this is the spirit of what we're doing today. > Here in the early stages of protocol and format development, however, > I think it's a good idea to help server admins and implementers pick > the best code for a particular situation. It may not be difficult for > someone with lots of server side development experience to pick status > codes that make sense (though it's obviously not trivial -- the HTTP > spec is (necessarily) vague), but it certainly wouldn't hurt to give > the "noobs" a helping hand in interpreting the HTTP status code spec. > If we find that the "recommended status codes" list is indeed bloating > the spec at some point, then I think it should be spun off into an > auxiliary "best practices" document. But for the time being, having Thanks for catching key point for me. It's really about whether these status code are recommendation/best practice, or mandatory. I am much comfortable if we put them as recommendation, therefore not part of compliance check. I also agree HTTP spec is (necessarily) vague, and kind of thinking many of these error codes are designed for human reading. Considering these factors, human readability perhaps outweight machine readability. xiaoming > the knowledge of the "right" way to apply status codes right there at > the bottom of the spec makes creating new implementations easier, and > IMO encourages those new implementations to be more accessible to > existing clients, since these new servers will fail in the same way as > existing servers. > >> xiaoming >> > > -- > Mike Rylander > mrylander@gmail.com > GPLS -- PINES Development > Database Developer > http://open-ils.org > From daniel.chudnov at yale.edu Mon Mar 6 11:00:36 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Mon Mar 6 11:00:39 2006 Subject: [gcs-pcs-list] (possible) issue: what to do for redirects? In-Reply-To: References: <20060303173902.GD26227@sildin.med.yale.edu> <20060305210440.GG3728@sildin.med.yale.edu> Message-ID: <20060306160036.GB8742@sildin.med.yale.edu> Xiaoming Liu wrote, on Mon, Mar 06, 2006 at 08:04:05AM -0700: > On Mon, 6 Mar 2006, Mike Rylander wrote: > > >Like I said, I think this is the spirit of what we're doing today. > >Here in the early stages of protocol and format development, however, > >I think it's a good idea to help server admins and implementers pick > >the best code for a particular situation. It may not be difficult for > >someone with lots of server side development experience to pick status > >codes that make sense (though it's obviously not trivial -- the HTTP > >spec is (necessarily) vague), but it certainly wouldn't hurt to give > >the "noobs" a helping hand in interpreting the HTTP status code spec. > >If we find that the "recommended status codes" list is indeed bloating > >the spec at some point, then I think it should be spun off into an > >auxiliary "best practices" document. But for the time being, having > > Thanks for catching key point for me. It's really about whether these > status code are recommendation/best practice, or mandatory. I am much > comfortable if we put them as recommendation, therefore not part of > compliance check. Okay, so, I think we're converging on the same point here: we defer to HTTP itself, but maybe suggest a few particular codes. Maybe the suggestions are even non-normative, and we don't require specific response codes for "unAPI compliance". Does anyone want to take a stab at rewriting that final bit on HTTP codes? -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From liu_x at lanl.gov Mon Mar 6 11:48:29 2006 From: liu_x at lanl.gov (Xiaoming Liu) Date: Mon Mar 6 11:47:54 2006 Subject: [gcs-pcs-list] more comments (plain text) In-Reply-To: <20060305212656.GI3728@sildin.med.yale.edu> References: <20060305212656.GI3728@sildin.med.yale.edu> Message-ID: On Sun, 5 Mar 2006, Daniel Chudnov wrote: > Eric Hellman wrote, on Sun, Mar 05, 2006 at 02:35:35PM -0500: >> (resent in plain text at request of list members) > > >> 2. modality of response to UNAPI?uri=URI requests. > > Your point about how a URI 404 should have a body like this: > > > info:sid/example.com/12345 > > > Is a good one. I'll flag it for a vote. > > But: > >> When I build an client for an XML service, I delegate the message >> handling to an XML Processor (usually with XSLT doing most of the >> work). The processor will throw an exception if the response is not >> well formed xml; this is usually because a service is broken. If I >> have to listen for a 404 response just in case there are no available >> format for an item, or if the item is unknown, then I can't handle >> that inside the XML processor. > > I hear you, but there's a deeper issue: the XML modality is layered over > the HTTP modality. HTTP is the common modality across all of unAPI; > some responses are XML, not all (indeed responses can be any type). > So your client should start by watching HTTP status codes, then handing > off to the XML processor, no? > If we agree on natural language reponse for error message, and "best practice" for error code, I think an appropriate way of error processing is checking status code first, if any error (http 400-500 range), a client may log or prompt these errors, but the client may not expect a machine readable error message (such as the XML snippet proposed above). xiaoming From eric at openly.com Mon Mar 6 12:23:45 2006 From: eric at openly.com (Eric Hellman) Date: Mon Mar 6 12:27:39 2006 Subject: [gcs-pcs-list] more comments (plain text) In-Reply-To: References: <20060305212656.GI3728@sildin.med.yale.edu> Message-ID: basically, we're having this discussion because the relevant section of the spec falls on the short side of "as short as possible, but not too short" What I'm observing is that there are two types of requests made to an unAPI service 1. request for availability info 2. request for metadata object What I'm saying is that responses to (1) should ALWAYS return xml if the unAPI service is working, and I shouldn't have to care about http status codes. Responses to (2) should be possible to delegate to an http stack, or to a browser, or whatever. It's unfortunate IMHO that the spec has not chosen to make this necessary modality explicit, but it should at least explain it better. At 9:48 AM -0700 3/6/06, Xiaoming Liu wrote: >On Sun, 5 Mar 2006, Daniel Chudnov wrote: > >>Eric Hellman wrote, on Sun, Mar 05, 2006 at 02:35:35PM -0500: >>>(resent in plain text at request of list members) >> >> >>>2. modality of response to UNAPI?uri=URI requests. >> >>Your point about how a URI 404 should have a body like this: >> >> >> info:sid/example.com/12345 >> >> >>Is a good one. I'll flag it for a vote. >> >>But: >> >>>When I build an client for an XML service, I delegate the message >>>handling to an XML Processor (usually with XSLT doing most of the >>>work). The processor will throw an exception if the response is not >>>well formed xml; this is usually because a service is broken. If I >>>have to listen for a 404 response just in case there are no available >>>format for an item, or if the item is unknown, then I can't handle >>>that inside the XML processor. >> >>I hear you, but there's a deeper issue: the XML modality is layered over >>the HTTP modality. HTTP is the common modality across all of unAPI; >>some responses are XML, not all (indeed responses can be any type). >>So your client should start by watching HTTP status codes, then handing >>off to the XML processor, no? >> > >If we agree on natural language reponse for error message, and "best >practice" for error code, I think an appropriate way of error >processing is checking status code first, if any error (http 400-500 >range), a client >may log or prompt these errors, but the client may not expect a >machine readable error message (such as the XML snippet proposed >above). > >xiaoming -- Eric Hellman, Director OCLC Openly Informatics Division eric@openly.com 2 Broad St., Suite 208 tel 1-973-509-7800 fax 1-734-468-6216 Bloomfield, NJ 07003 http://www.openly.com/1cate/ 1 Click Access To Everything From daniel.chudnov at yale.edu Mon Mar 6 12:44:18 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Mon Mar 6 12:44:19 2006 Subject: [gcs-pcs-list] more comments (plain text) In-Reply-To: References: <20060305212656.GI3728@sildin.med.yale.edu> Message-ID: <20060306174417.GE8742@sildin.med.yale.edu> Eric Hellman wrote, on Mon, Mar 06, 2006 at 12:23:45PM -0500: > > What I'm observing is that there are two types of requests made to an > unAPI service > ... > 2. request for metadata object A quick point of information: unAPI makes no functional distinction between objects and metadata objects. The same functions may refer to requests for either, relative to the same URI, and nothing in unAPI itself specifies which is which. > What I'm saying is that responses to (1) should ALWAYS return xml if > the unAPI service is working, and I shouldn't have to care about http > status codes. Responses to (2) should be possible to delegate to an > http stack, or to a browser, or whatever. This is worth discussing, so: What is the benefit of an xml response on a 404, like you suggest: info:foo/bar There is nothing you can do with that that a 404 doesn't already tell you. Indeed, if it is a restricted-access item, you will get more information from a 401 or 403 status code, also, than just examining this echoed response. Version 0 suggested echoing http status codes into the response entity format itself; this was voted down by consensus as the information is already present in the HTTP headers if appropriate codes are used. Your preference for implementing unAPI with an XML handler-centric processing technique doesn't change the fact that the HTTP functions in unAPI are an HTTP convention, not an XML protocol. :) -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From mrylander at gmail.com Mon Mar 6 14:06:04 2006 From: mrylander at gmail.com (Mike Rylander) Date: Mon Mar 6 14:07:08 2006 Subject: [gcs-pcs-list] big day in #code4lib Message-ID: A 4+ hour conversation started today around the real differences between OpenURL and unAPI. Excepting some initial ... um ... emotional/evangelical responses from several interested parties (me included), it was all very civil, and we managed to come to a truce, if not an agreement, on some things. What follows is my interpretation of the discussion, distilled, for your viewing pleasure, from about 400K of scrollback buffer. 1) unAPI can be implemented on top of an OpenURL resolver 2) working code shows that it seems to be useful to do this 3) working code also shows that unAPI needn't be implemented this way (OpenILS, WP) 4) there is some confusion as to whether these implementations expose unAPI to be a resolver in the real sense -- I contend that this is mixing the purpose of unAPI with implementation details 5) the use of URI for resource identifiers is confusing, with regard to identifier opacity/transparency It is generally agreed (I think, it got a few ++s) that resource identifiers, be they URIs or not (future debate), should be explicitly stated to be opaque in the spec. This solves (at least) a few problems: * asking for a MARC record by ISBN seems counter intuitive to some -- "shouldn't it return the full text of the item?" * if a user sees an unqualified urn:isbn:xxxxxxxx URI, can they assume it means the same thing across different sites? Or for that matter, across time on the same site? (think: upgrading a MARC record after the Encoding Level changes) * can a user ask an unapi server to retrieve something by handing it an identifier for a resourse that the server did not publish along with its ? If the spec were to say "identifiers, regardless of format, are opaque beyond the walls of the ed server, and across time (granular to some basic expectation of stability -- eg, today?)", then all of these questions are moot. The identifier has /no intrinsic meaning/, in the unAPI sense, outside the context of the page it appeared on. Now for some editorializing: I think there is merit in using well-know URIs to fetch resources. If a site has MARCXML and OAI_DC, but the user wants MODS, they could go to Amazon (or Evergreen ;) ) to get that representation. But they would be fetching a /different but similar/ thing, not an alternate representations of the unAPI-linked item, and it's an expectation that should be explicitly outside the scope of unAPI. Summing up, here are my thoughts: Should there exist any expectation, in terms of an unAPI services' ability to retrieve resources, that an identifier can be constructed by a client? If not, then IMHO the identifiers should be said to be opaque as far as their use in unAPI goes, whether or not they are parsable/understandable by humans. Proposal for adding a vote to the queue: Should the unAPI spec say explicitly that all unAPI identifiers, for the purpose of unAPI resource retrieval, are opaque and that the user should have no expectation that said identifiers are valid/useful/meaningful beyond the scope of the ed retriever, and that the identifiers served are the extent of the known universe so far as that ed retriever is concerned? I'll leave it to someone else to clarify that if we want to vote on it ... -- Mike Rylander mrylander@gmail.com GPLS -- PINES Development Database Developer http://open-ils.org From jyoung at oclc.org Mon Mar 6 14:26:24 2006 From: jyoung at oclc.org (Young,Jeff (OR)) Date: Mon Mar 6 14:26:51 2006 Subject: [gcs-pcs-list] big day in #code4lib Message-ID: I'm not here to argue for OpenURL any more. To the extent others are interested, however, I want to make sure OpenURL is represented accurately. > 1) unAPI can be implemented on top of an OpenURL resolver This is true, but only in the sense that "on top of..." means "as a separate gateway service" or "using mod_rewrite", or some other such trick. > 2) working code shows that it seems to be useful to do this Working code merely shows that it is trivial to do this. It is only useful to the extent that people actually implement these tricks. Jeff From daniel.chudnov at yale.edu Mon Mar 6 14:47:51 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Mon Mar 6 14:48:58 2006 Subject: [gcs-pcs-list] big day in #code4lib In-Reply-To: References: Message-ID: <9D8DCB0F-D3DA-4C08-8F4D-97FD0A41395E@yale.edu> On Mar 6, 2006, at 2:06 PM, Mike Rylander wrote: > A 4+ hour conversation started today around the real differences > between OpenURL and unAPI. Excepting some initial ... um ... > emotional/evangelical responses from several interested parties (me > included), it was all very civil, and we managed to come to a truce, > if not an agreement, on some things. What follows is my > interpretation of the discussion, distilled, for your viewing > pleasure, from about 400K of scrollback buffer. Oh dear. > 5) the use of URI for resource identifiers is confusing, with regard > to identifier opacity/transparency For those of us who missed it, please define "opaque" and "transparent" w/r/to identifiers, in this context. I think I know what you mean, but I'm not certain. There are a lot of different issues mixed together in your summary so your summary is a little too "opaque" for me to understand (i.e. I cannot see the light through it :). -Dan From mrylander at gmail.com Mon Mar 6 14:57:51 2006 From: mrylander at gmail.com (Mike Rylander) Date: Mon Mar 6 14:58:56 2006 Subject: [gcs-pcs-list] big day in #code4lib In-Reply-To: <9D8DCB0F-D3DA-4C08-8F4D-97FD0A41395E@yale.edu> References: <9D8DCB0F-D3DA-4C08-8F4D-97FD0A41395E@yale.edu> Message-ID: On 3/6/06, Daniel Chudnov wrote: > On Mar 6, 2006, at 2:06 PM, Mike Rylander wrote: > > > A 4+ hour conversation started today around the real differences > > between OpenURL and unAPI. Excepting some initial ... um ... > > emotional/evangelical responses from several interested parties (me > > included), it was all very civil, and we managed to come to a truce, > > if not an agreement, on some things. What follows is my > > interpretation of the discussion, distilled, for your viewing > > pleasure, from about 400K of scrollback buffer. > > Oh dear. > > > > 5) the use of URI for resource identifiers is confusing, with regard > > to identifier opacity/transparency > > For those of us who missed it, please define "opaque" and > "transparent" w/r/to identifiers, in this context. I think I know > what you mean, but I'm not certain. opaque == "as far as you, the user, knows, this identifier only means something to the in the header of this page, and you don't know how to build one, so don't try" ;) transparent == "server says: I understand, among other things, urn:isbn:xxx URIs, so go ahead and gimme one you found on some random web site" > > There are a lot of different issues mixed together in your summary so > your summary is a little too "opaque" for me to understand (i.e. I > cannot see the light through it :). The point of all of that, IMO, is that if we say "identifiers are opaque handles that only the server at understands", then we sidestep all issues where interpreting identifiers causes confusion. > > -Dan > -- Mike Rylander mrylander@gmail.com GPLS -- PINES Development Database Developer http://open-ils.org From daniel.chudnov at yale.edu Mon Mar 6 15:19:04 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Mon Mar 6 15:20:10 2006 Subject: [gcs-pcs-list] big day in #code4lib In-Reply-To: References: <9D8DCB0F-D3DA-4C08-8F4D-97FD0A41395E@yale.edu> Message-ID: Y'all are going to have to gang up something fierce to convince me that the unAPI spec itself should say *anything* about the meaning of URIs or the meaning of patterns of URIs and specific unAPI servers. unAPI services and clients should not be forced into a mode of operating on objects anywhere that is mandated to be at any specific node/level in the FRBR work-expression-manifestation-item model. Or that any fetched object with any kind of URI from any unAPI server should be expected to remain identical over time or space. Or that the only "correct" dissemination for some URI and FORMAT is from some specific server. My premise behind wanting to work on this and related efforts is to simplify movement of information across applications... not to make moved information more rigorous, or more verifiable, or more trustworthy, or more authoritative, or any of that, just simpler. It's up to implementors to make their own choices about expectations and assumptions, including whether URIs have constructable meaning or not, or whether objects should be expected to stay the same or not. If this is what you meant, cool. Mess is lore! -Dan p.s. not that this isn't a perfect discussion for one or more FAQs... :) From eric at openly.com Mon Mar 6 15:19:56 2006 From: eric at openly.com (Eric Hellman) Date: Mon Mar 6 15:23:55 2006 Subject: [gcs-pcs-list] big day in #code4lib In-Reply-To: References: <9D8DCB0F-D3DA-4C08-8F4D-97FD0A41395E@yale.edu> Message-ID: At 7:57 PM +0000 3/6/06, Mike Rylander wrote: >opaque == "as far as you, the user, knows, this identifier only means >something to the in the header of this page, and you don't know >how to build one, so don't try" ;) > >transparent == "server says: I understand, among other things, >urn:isbn:xxx URIs, so go ahead and gimme one you found on some random >web site" this is not the definition commonly used- these definitions would better describe the terms "private" or "local" and "public" or "global" as applied to identifiers well, saying that the identifiers ARE private would seem to me to be rather silly; saying that they MAY be private seems sensible. disclosure- I work for an organization with a large store of metadata which could conceivably be served via unAPI using either private or public identifiers. -- Eric Hellman, Director OCLC Openly Informatics Division eric@openly.com 2 Broad St., Suite 208 tel 1-973-509-7800 fax 1-734-468-6216 Bloomfield, NJ 07003 http://www.openly.com/1cate/ 1 Click Access To Everything From Peter.Binkley at ualberta.ca Mon Mar 6 15:32:21 2006 From: Peter.Binkley at ualberta.ca (Binkley, Peter) Date: Mon Mar 6 15:40:20 2006 Subject: [gcs-pcs-list] big day in #code4lib Message-ID: <908893006339C0409519E4065DF3B249015710A6@mailserver.ualibrary.ualberta.ca> I think Mike has drawn a useful (for me anyway) distinction: how tokens are built vs. what tokens the unapi server should be expected to respond to. I agree that a unapi server isn't a resolver and shouldn't be expected to respond to a token that it hasn't issued; but I don't see a reason why that token shouldn't be labeled as a bona fide ISBN if that's what it is. Clients that throw arbitrary ISBNs at a unapi server deserve whatever they get, but they can at least collect an isbn from the unapi link and reuse it. Peter From mrylander at gmail.com Mon Mar 6 15:48:39 2006 From: mrylander at gmail.com (Mike Rylander) Date: Mon Mar 6 15:49:44 2006 Subject: [gcs-pcs-list] big day in #code4lib In-Reply-To: References: <9D8DCB0F-D3DA-4C08-8F4D-97FD0A41395E@yale.edu> Message-ID: On 3/6/06, Daniel Chudnov wrote: > Y'all are going to have to gang up something fierce to convince me > that the unAPI spec itself should say *anything* about the meaning of > URIs or the meaning of patterns of URIs and specific unAPI servers. > I want to say that the URIs /don't mean anything/. Any resource you fetch using an URI you get from me may have no relation whatsoever to any other site's resource identified by an identical URI (where identical is defined by strcmp (3)). > unAPI services and clients should not be forced into a mode of > operating on objects anywhere that is mandated to be at any specific > node/level in the FRBR work-expression-manifestation-item model. Or > that any fetched object with any kind of URI from any unAPI server > should be expected to remain identical over time or space. Or that > the only "correct" dissemination for some URI and FORMAT is from some > specific server. > Sure. The spec doesn't say that, and it, apparently, caused some confusion. It is my belief that the confusion arose due to the mixing of implementation concepts (how a "real" OpenURL server works) versus the actual purpose of the unAPI spec. > My premise behind wanting to work on this and related efforts is to > simplify movement of information across applications... not to make > moved information more rigorous, or more verifiable, or more > trustworthy, or more authoritative, or any of that, just simpler. > It's up to implementors to make their own choices about expectations > and assumptions, including whether URIs have constructable meaning or > not, or whether objects should be expected to stay the same or not. > Sure. I don't care about big-a Authoritative, just little-a authoritative HERE (from this page). > If this is what you meant, cool. > umm... I think it is. The important part of unapi, the end result we desire, is the resource, and /not/ the URI/identifier/handle/pointer/thing-that-comes-after-"uri="-in-the-url. My point, though, is about user expectations: unAPI identifiers embedded in a page should only be expected to "work" with the service named in the unAPI for the page you are viewing, and (so far as you know) /only/ those identifiers. More may work, and they may work elsewhere, but from an unAPI viewpoint the user cannot know that. If the service at is a resolver, just use OpenURL. If it's specifically a retrieval mechanism for things hosted behind it (alternate formats for things you can already get to), and exposed via unAPI spans, then we should codify that ... It's about the "service level", if you like. OpenURL provides more flexibility, but we don't want that (I think). We want "gimme that thing you published an identifier for as MODS (or oai_dc, or MARCXML, or PDF, or whatever)" ... we don't want "do you have ISBN 1234567890X in PDF format?" ... right? > Mess is lore! > > -Dan > > > p.s. not that this isn't a perfect discussion for one or more FAQs... :) > -- Mike Rylander mrylander@gmail.com GPLS -- PINES Development Database Developer http://open-ils.org From mrylander at gmail.com Mon Mar 6 15:50:28 2006 From: mrylander at gmail.com (Mike Rylander) Date: Mon Mar 6 15:51:33 2006 Subject: [gcs-pcs-list] big day in #code4lib In-Reply-To: References: <9D8DCB0F-D3DA-4C08-8F4D-97FD0A41395E@yale.edu> Message-ID: On 3/6/06, Eric Hellman wrote: > At 7:57 PM +0000 3/6/06, Mike Rylander wrote: > >opaque == "as far as you, the user, knows, this identifier only means > >something to the in the header of this page, and you don't know > >how to build one, so don't try" ;) > > > >transparent == "server says: I understand, among other things, > >urn:isbn:xxx URIs, so go ahead and gimme one you found on some random > >web site" > > this is not the definition commonly used- these definitions would > better describe the terms "private" or "local" and "public" or > "global" as applied to identifiers My purpose in using those terms was to stay away from a definition of what goes into the URI, but instead focus on whether it makes sense for the user to even try to understand them. > > well, saying that the identifiers ARE private would seem to me to be > rather silly; saying that they MAY be private seems sensible. > > disclosure- I work for an organization with a large store of metadata > which could conceivably be served via unAPI using either private or > public identifiers. > -- > > Eric Hellman, Director OCLC Openly > Informatics Division > eric@openly.com 2 Broad St., Suite 208 > tel 1-973-509-7800 fax 1-734-468-6216 Bloomfield, NJ 07003 > http://www.openly.com/1cate/ 1 Click Access To Everything > -- Mike Rylander mrylander@gmail.com GPLS -- PINES Development Database Developer http://open-ils.org From liu_x at lanl.gov Mon Mar 6 16:04:53 2006 From: liu_x at lanl.gov (Xiaoming Liu) Date: Mon Mar 6 16:04:17 2006 Subject: [gcs-pcs-list] more comments (plain text) In-Reply-To: References: <20060305212656.GI3728@sildin.med.yale.edu> Message-ID: On Mon, 6 Mar 2006, Eric Hellman wrote: > basically, we're having this discussion because the relevant section of the > spec falls on the short side of "as short as possible, but not too short" > > What I'm observing is that there are two types of requests made to an unAPI > service > 1. request for availability info > 2. request for metadata object > I was thinking there is perhaps a proper model to describe unAPI, it's intriguing to me because it's recursive, and it may be useful to clarify error processing and perhaps other issues. The model might be described as: (a) a URI (b) the URI can be disseminated in several formats. (c) The format response itself (introspect document) is one of these disseminations. give a concrete example, a request to UNAPI?uri=data:abc&format=fmt may return a result set including itself. "fmt I think this model is beautiful because it integrates your two types of requests. There is only one type of request which asks some kind of dissemination of an URI, and therefore we have a consistent way of error handling or other issues. Notice I am not proposing changes to unapi spec, but just gives another view of the error handling problem raised by Eric. xiaoming From eric at openly.com Mon Mar 6 16:15:30 2006 From: eric at openly.com (Eric Hellman) Date: Mon Mar 6 16:19:23 2006 Subject: [gcs-pcs-list] big day in #code4lib In-Reply-To: References: <9D8DCB0F-D3DA-4C08-8F4D-97FD0A41395E@yale.edu> Message-ID: At 8:50 PM +0000 3/6/06, Mike Rylander wrote: >On 3/6/06, Eric Hellman wrote: >> At 7:57 PM +0000 3/6/06, Mike Rylander wrote: >> >opaque == "as far as you, the user, knows, this identifier only means >> >something to the in the header of this page, and you don't know >> >how to build one, so don't try" ;) >> > >> >transparent == "server says: I understand, among other things, >> >urn:isbn:xxx URIs, so go ahead and gimme one you found on some random >> >web site" >> >> this is not the definition commonly used- these definitions would >> better describe the terms "private" or "local" and "public" or >> "global" as applied to identifiers > >My purpose in using those terms was to stay away from a definition of >what goes into the URI, but instead focus on whether it makes sense >for the user to even try to understand them. > >> >> well, saying that the identifiers ARE private would seem to me to be >> rather silly; saying that they MAY be private seems sensible. >> >> disclosure- I work for an organization with a large store of metadata >> which could conceivably be served via unAPI using either private or > > public identifiers. If you talk to identifier people, isbn is considered non-opaque because it contains country- and publisher- codes, i.e. certain metadata can be extracted from the identifier. -- Eric Hellman, Director OCLC Openly Informatics Division eric@openly.com 2 Broad St., Suite 208 tel 1-973-509-7800 fax 1-734-468-6216 Bloomfield, NJ 07003 http://www.openly.com/1cate/ 1 Click Access To Everything From liu_x at lanl.gov Mon Mar 6 16:27:32 2006 From: liu_x at lanl.gov (Xiaoming Liu) Date: Mon Mar 6 16:26:52 2006 Subject: [gcs-pcs-list] big day in #code4lib In-Reply-To: References: <9D8DCB0F-D3DA-4C08-8F4D-97FD0A41395E@yale.edu> Message-ID: On Mon, 6 Mar 2006, Mike Rylander wrote: > On 3/6/06, Daniel Chudnov wrote: >> Y'all are going to have to gang up something fierce to convince me >> that the unAPI spec itself should say *anything* about the meaning of >> URIs or the meaning of patterns of URIs and specific unAPI servers. >> > > I want to say that the URIs /don't mean anything/. Any resource you > fetch using an URI you get from me may have no relation whatsoever to > any other site's resource identified by an identical URI (where > identical is defined by strcmp (3)). > >> unAPI services and clients should not be forced into a mode of >> operating on objects anywhere that is mandated to be at any specific >> node/level in the FRBR work-expression-manifestation-item model. Or >> that any fetched object with any kind of URI from any unAPI server >> should be expected to remain identical over time or space. Or that >> the only "correct" dissemination for some URI and FORMAT is from some >> specific server. >> > > Sure. The spec doesn't say that, and it, apparently, caused some > confusion. It is my belief that the confusion arose due to the mixing > of implementation concepts (how a "real" OpenURL server works) versus > the actual purpose of the unAPI spec. > I indeed think many confusions arose due to the mixing of implmentation vs. spec. unAPI spec only describes a protocol. How to use it is out of the scope of spec definition. Let's take the example of Web, in one case, say if you run a google of all unAPI resources, you may only care about current snapshot and deliver a search service; in another case, say if I am building an Internet Archive of all unAPI resources, I do care where(unapi baseURL) and when (response time) that I got them; in a third case, I may build my own server/client inside of firewall, so how to deal with it is solely my business. With all those possibilities, I don't think you want to limit the capability of unAPI to some pre-defined profiles, such as private or public, or transparent. This is really a decision of unAPI server or service implementation. I may choose well-known URIs when I intend to have the world use my data; or I can choose any private URIs if I want two linux box talk to each other. Again, there are lots of nice discussions about URI beyond scope of unAPI. xiaoming From jyoung at oclc.org Mon Mar 6 16:27:19 2006 From: jyoung at oclc.org (Young,Jeff (OR)) Date: Mon Mar 6 16:27:52 2006 Subject: [gcs-pcs-list] big day in #code4lib Message-ID: > -----Original Message----- > From: gcs-pcs-list-bounces@cipolo.med.yale.edu [mailto:gcs-pcs-list- > bounces@cipolo.med.yale.edu] On Behalf Of Eric Hellman > Sent: Monday, March 06, 2006 4:16 PM > To: Mike Rylander > Cc: gcs-pcs-list@cipolo.med.yale.edu > Subject: Re: [gcs-pcs-list] big day in #code4lib > > At 8:50 PM +0000 3/6/06, Mike Rylander wrote: > >On 3/6/06, Eric Hellman wrote: > >> At 7:57 PM +0000 3/6/06, Mike Rylander wrote: > >> >opaque == "as far as you, the user, knows, this identifier only means > >> >something to the in the header of this page, and you don't > know > >> >how to build one, so don't try" ;) > >> > > >> >transparent == "server says: I understand, among other things, > >> >urn:isbn:xxx URIs, so go ahead and gimme one you found on some random > >> >web site" > >> > >> this is not the definition commonly used- these definitions would > >> better describe the terms "private" or "local" and "public" or > >> "global" as applied to identifiers > > > >My purpose in using those terms was to stay away from a definition of > >what goes into the URI, but instead focus on whether it makes sense > >for the user to even try to understand them. > > > >> > >> well, saying that the identifiers ARE private would seem to me to be > >> rather silly; saying that they MAY be private seems sensible. > >> > >> disclosure- I work for an organization with a large store of metadata > >> which could conceivably be served via unAPI using either private or > > > public identifiers. > > If you talk to identifier people, isbn is considered non-opaque > because it contains country- and publisher- codes, i.e. certain > metadata can be extracted from the identifier. In this context, it appears that the term "opaque" is being used in the sense of globally unique (URIs) vs. locally unique (a String). Whether it can be parsed locally or globally is inconsequential. Jeff From azaroth at liverpool.ac.uk Mon Mar 6 16:30:22 2006 From: azaroth at liverpool.ac.uk (Robert Sanderson) Date: Mon Mar 6 16:33:35 2006 Subject: [gcs-pcs-list] big day in #code4lib In-Reply-To: References: <9D8DCB0F-D3DA-4C08-8F4D-97FD0A41395E@yale.edu> Message-ID: On Mon, 6 Mar 2006, Mike Rylander wrote: >On 3/6/06, Daniel Chudnov wrote: >> Y'all are going to have to gang up something fierce to convince me >> that the unAPI spec itself should say *anything* about the meaning of >> URIs or the meaning of patterns of URIs and specific unAPI servers. >I want to say that the URIs /don't mean anything/. Any resource you >fetch using an URI you get from me may have no relation whatsoever to >any other site's resource identified by an identical URI (where >identical is defined by strcmp (3)). Which is my problem with saying 'uri' not 'identifier'. By buying into the URI concept, you lose your opacity because the URI specs define sub-string meaning. For example uri:isbn:123456789 is NOT just a single string, it has three parts 'uri' 'isbn' and '123456789'. The same goes for all other URI schemes. As soon as you say 'uri', you buy into the uri world view and you just cannot say that you mean an opaque identifier when you say uri. That's like saying that http://a.b.c:8000/~azaroth/foo?bar=baz is 'opaque' when everyone knows that it consists of a bunch of different parts. >> unAPI services and clients should not be forced into a mode of >> operating on objects anywhere that is mandated to be at any specific >> node/level in the FRBR work-expression-manifestation-item model. Or >> that any fetched object with any kind of URI from any unAPI server >> should be expected to remain identical over time or space. Or that >> the only "correct" dissemination for some URI and FORMAT is from some >> specific server. >Sure. The spec doesn't say that, and it, apparently, caused some >confusion. As it is completely against any notion of URI out there. Here's my URI scheme: http://sru.cheshire3.org/services/database?query={searchTerms}&recordPosition={startIndex} Heh, I just reinvented SRU over unAPI. Niiiiiiice. :) This is the ridiculous end result of saying that uris have no persistence and no cross-application applicability. They stop being URIs! > My point, though, is about user expectations: unAPI identifiers >embedded in a page should only be expected to "work" with the service >named in the unAPI for the page you are viewing, and (so far as >you know) /only/ those identifiers. More may work, and they may work >elsewhere, but from an unAPI viewpoint the user cannot know that. Absolutely 100% correct, IMO. URIs carry much larger expectations than this. (Going back to lurk mode) Rob From mrylander at gmail.com Mon Mar 6 16:34:16 2006 From: mrylander at gmail.com (Mike Rylander) Date: Mon Mar 6 16:35:19 2006 Subject: [gcs-pcs-list] big day in #code4lib In-Reply-To: <908893006339C0409519E4065DF3B249015710A6@mailserver.ualibrary.ualberta.ca> References: <908893006339C0409519E4065DF3B249015710A6@mailserver.ualibrary.ualberta.ca> Message-ID: On 3/6/06, Binkley, Peter wrote: > I think Mike has drawn a useful (for me anyway) distinction: how tokens > are built vs. what tokens the unapi server should be expected to respond > to. I agree that a unapi server isn't a resolver and shouldn't be > expected to respond to a token that it hasn't issued; but I don't see a > reason why that token shouldn't be labeled as a bona fide ISBN if that's > what it is. Clients that throw arbitrary ISBNs at a unapi server deserve > whatever they get, but they can at least collect an isbn from the unapi > link and reuse it. Not to beat a dead horse into the shape of a llama, but: Quoth miker_, in starting this thread ... Now for some editorializing: I think there is merit in using well-know URIs to fetch resources. If a site has MARCXML and OAI_DC, but the user wants MODS, they could go to Amazon (or Evergreen ;) ) to get that representation. But they would be fetching a /different but similar/ thing, not an alternate representations of the unAPI-linked item, and it's an expectation that should be explicitly outside the scope of unAPI. > > Peter > > > -- Mike Rylander mrylander@gmail.com GPLS -- PINES Development Database Developer http://open-ils.org From ehs at pobox.com Mon Mar 6 16:37:11 2006 From: ehs at pobox.com (Ed Summers) Date: Mon Mar 6 16:38:15 2006 Subject: [gcs-pcs-list] big day in #code4lib In-Reply-To: References: <9D8DCB0F-D3DA-4C08-8F4D-97FD0A41395E@yale.edu> Message-ID: On 3/6/06, Xiaoming Liu wrote: > With all those possibilities, I don't think you want to limit the > capability of unAPI to some pre-defined profiles, such as private or > public, or transparent. This is really a decision of unAPI server or > service implementation. I may choose well-known URIs when I intend to have > the world use my data; or I can choose any private URIs if I want two > linux box talk to each other. Again, there are lots of nice discussions > about URI beyond scope of unAPI. Well said! Perhaps we're only having this discussion because the unAPI spec uses such prolific use of the term URI. s/URI/identifier/ and we may not even be talking about it :-) //Ed From mrylander at gmail.com Mon Mar 6 16:45:24 2006 From: mrylander at gmail.com (Mike Rylander) Date: Mon Mar 6 16:46:27 2006 Subject: [gcs-pcs-list] big day in #code4lib In-Reply-To: References: <9D8DCB0F-D3DA-4C08-8F4D-97FD0A41395E@yale.edu> Message-ID: On 3/6/06, Xiaoming Liu wrote: > On Mon, 6 Mar 2006, Mike Rylander wrote: > > > On 3/6/06, Daniel Chudnov wrote: > >> Y'all are going to have to gang up something fierce to convince me > >> that the unAPI spec itself should say *anything* about the meaning of > >> URIs or the meaning of patterns of URIs and specific unAPI servers. > >> > > > > I want to say that the URIs /don't mean anything/. Any resource you > > fetch using an URI you get from me may have no relation whatsoever to > > any other site's resource identified by an identical URI (where > > identical is defined by strcmp (3)). > > > >> unAPI services and clients should not be forced into a mode of > >> operating on objects anywhere that is mandated to be at any specific > >> node/level in the FRBR work-expression-manifestation-item model. Or > >> that any fetched object with any kind of URI from any unAPI server > >> should be expected to remain identical over time or space. Or that > >> the only "correct" dissemination for some URI and FORMAT is from some > >> specific server. > >> > > > > Sure. The spec doesn't say that, and it, apparently, caused some > > confusion. It is my belief that the confusion arose due to the mixing > > of implementation concepts (how a "real" OpenURL server works) versus > > the actual purpose of the unAPI spec. > > > > I indeed think many confusions arose due to the mixing of implmentation > vs. spec. > > unAPI spec only describes a protocol. How to use it is out of the scope of > spec definition. Let's take the example of Web, in one case, say if you > run a google of all unAPI resources, you may only care about current > snapshot and deliver a search service; in another case, say if I am > building an Internet Archive of all unAPI resources, I do care where(unapi > baseURL) and when (response time) that I got them; in a third case, I may > build my own server/client inside of firewall, so how to deal with it is > solely my business. > Sure. The IA based on unAPI would be very interesting. :) > With all those possibilities, I don't think you want to limit the > capability of unAPI to some pre-defined profiles, such as private or > public, or transparent. This is really a decision of unAPI server or > service implementation. I may choose well-known URIs when I intend to have > the world use my data; or I can choose any private URIs if I want two > linux box talk to each other. Again, there are lots of nice discussions > about URI beyond scope of unAPI. I may not be explaining myself clearly ... I don't want to resrict what a server can produce as identifiers, and I don't want to restrict what users can do with those identifiers. I just want the spec to say that the only garentee about an unAPI identifier is that it's valid for use right now against the ed service and no other expectation can be made ... eg, this thing you have is known to us, now, and at , and that's potentially /all/ that knows about. Whatever else you (the user) do is up to you. If this is self-evident then, please, someone shoot me now. ;) The non-obviousness of this point seems to me to be what today's bru-ha-ha stemmed from (for the most part). > > xiaoming > -- Mike Rylander mrylander@gmail.com GPLS -- PINES Development Database Developer http://open-ils.org From liu_x at lanl.gov Mon Mar 6 17:00:56 2006 From: liu_x at lanl.gov (Xiaoming Liu) Date: Mon Mar 6 17:00:21 2006 Subject: [gcs-pcs-list] big day in #code4lib In-Reply-To: References: <9D8DCB0F-D3DA-4C08-8F4D-97FD0A41395E@yale.edu> Message-ID: On Mon, 6 Mar 2006, Mike Rylander wrote: > >> With all those possibilities, I don't think you want to limit the >> capability of unAPI to some pre-defined profiles, such as private or >> public, or transparent. This is really a decision of unAPI server or >> service implementation. I may choose well-known URIs when I intend to have >> the world use my data; or I can choose any private URIs if I want two >> linux box talk to each other. Again, there are lots of nice discussions >> about URI beyond scope of unAPI. > > I may not be explaining myself clearly ... I don't want to resrict > what a server can produce as identifiers, and I don't want to restrict > what users can do with those identifiers. I just want the spec to say > that the only garentee about an unAPI identifier is that it's valid > for use right now against the ed service and no other > expectation can be made ... eg, this thing you have is known to us, > now, and at , and that's potentially /all/ that knows > about. Whatever else you (the user) do is up to you. > I think this is an example of putting limitations to unAPI's potential. If I put up a web server, do I have to put a disclaimer that the service might be unavailable due to flooding? Put it concretely, once you put the data there, it can be cached, used in multiple ways of not imagined before. Perhaps the disclaimer is irrelevant after that. xiaoming > If this is self-evident then, please, someone shoot me now. ;) The > non-obviousness of this point seems to me to be what today's bru-ha-ha > stemmed from (for the most part). > From azaroth at liverpool.ac.uk Mon Mar 6 17:08:35 2006 From: azaroth at liverpool.ac.uk (Robert Sanderson) Date: Mon Mar 6 17:11:47 2006 Subject: [gcs-pcs-list] big day in #code4lib In-Reply-To: References: <9D8DCB0F-D3DA-4C08-8F4D-97FD0A41395E@yale.edu> Message-ID: On Mon, 6 Mar 2006, Xiaoming Liu wrote: >On Mon, 6 Mar 2006, Mike Rylander wrote: >> I may not be explaining myself clearly ... I don't want to resrict >> what a server can produce as identifiers, and I don't want to restrict >> what users can do with those identifiers. I just want the spec to say >> that the only garentee about an unAPI identifier is that it's valid >> for use right now against the ed service and no other >> expectation can be made ... eg, this thing you have is known to us, >> now, and at , and that's potentially /all/ that knows >> about. Whatever else you (the user) do is up to you. >I think this is an example of putting limitations to unAPI's potential. If s/potential/scope/ It doesn't limit the potential, it limits the scope that the spec is designed for. Nothing is stopping you from using a URI, so no potential is lost. However you do so in the privacy of your own implementation, which is exactly how it should be unless those URIs are globally unique and persistent. Here's the backchannel from IRC: pbinkley: if i promise not to use identifiers that look like uris unless they really are uris? azaroth: Identifiers are opaque azaroth: If they happen to look to YOU like a uri, then you're already looking too close jeyo: Once you accept "identifiers" in the generic sense, there is no safe way to pick out URIs miker_: azaroth++ azaroth: But I'm not going to stop you looking closely pbinkley: ok miker_ azaroth: you just boiled down my whole argument in 1.5 lines on IRC ... thanks :) :) Rob, REALLY going back to lurking now From liu_x at lanl.gov Mon Mar 6 17:51:13 2006 From: liu_x at lanl.gov (Xiaoming Liu) Date: Mon Mar 6 17:50:31 2006 Subject: [gcs-pcs-list] big day in #code4lib In-Reply-To: References: <9D8DCB0F-D3DA-4C08-8F4D-97FD0A41395E@yale.edu> Message-ID: On Mon, 6 Mar 2006, Robert Sanderson wrote: > On Mon, 6 Mar 2006, Xiaoming Liu wrote: >> On Mon, 6 Mar 2006, Mike Rylander wrote: > >>> I may not be explaining myself clearly ... I don't want to resrict >>> what a server can produce as identifiers, and I don't want to restrict >>> what users can do with those identifiers. I just want the spec to say >>> that the only garentee about an unAPI identifier is that it's valid >>> for use right now against the ed service and no other >>> expectation can be made ... eg, this thing you have is known to us, >>> now, and at , and that's potentially /all/ that knows >>> about. Whatever else you (the user) do is up to you. > >> I think this is an example of putting limitations to unAPI's potential. If > > s/potential/scope/ > > It doesn't limit the potential, it limits the scope that the spec is > designed for. Nothing is stopping you from using a URI, so no potential > is lost. However you do so in the privacy of your own implementation, I hope I did not spam the list by repeating same messeges, but I believe adoption of URI is a good thing, if I am properly using URI I want to let the world know (instead of a small secret for myself). Everyone should be encouraged to use URI, urn:isbn:0131103628 is better than 0131103628 and therefore should be strongly suggested. And there is no execuse of not using URI when we come to interoperability, especially after the release of tag URI. The whole world is using URI and we cannot excuse ourselves that library is different. So perhaps this comes close to belief or religion ;-) xiaoming > which is exactly how it should be unless those URIs are globally unique > and persistent. > > Here's the backchannel from IRC: > > pbinkley: if i promise not to use identifiers that look like uris > unless they really are uris? > azaroth: Identifiers are opaque > azaroth: If they happen to look to YOU like a uri, then you're already > looking too close > jeyo: Once you accept "identifiers" in the generic sense, there is > no safe way to pick out URIs > miker_: azaroth++ > azaroth: But I'm not going to stop you looking closely > pbinkley: ok > miker_ azaroth: you just boiled down my whole argument in 1.5 lines > on IRC ... thanks :) > > :) > > Rob, REALLY going back to lurking now > _______________________________________________ > gcs-pcs-list mailing list > gcs-pcs-list@cipolo.med.yale.edu > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list > From daniel.chudnov at yale.edu Mon Mar 6 22:25:54 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Mon Mar 6 22:26:58 2006 Subject: [gcs-pcs-list] big day in #code4lib In-Reply-To: References: <9D8DCB0F-D3DA-4C08-8F4D-97FD0A41395E@yale.edu> Message-ID: <1D614E4E-D91E-41F0-B21B-1541DE31B564@yale.edu> On Mar 6, 2006, at 4:45 PM, Mike Rylander wrote: > > I may not be explaining myself clearly ... I don't want to resrict > what a server can produce as identifiers, and I don't want to restrict > what users can do with those identifiers. I just want the spec to say > that the only garentee about an unAPI identifier is that it's valid > for use right now against the ed service and no other > expectation can be made ... eg, this thing you have is known to us, > now, and at , and that's potentially /all/ that knows > about. Even that's too much. Ever had a link on a page that pointed to something that had gone away or moved? To paraphrase Butthead (badly), unAPI is pretty cool, Beavis, but even unAPI can't change the information lifecycle. This use case is a great example of why wholly deferring to HTTP status codes is better. unAPI can't and shouldn't impose guarantees on anything. I don't want to be a jerk (though, noting that this is the second time I've said that in a week, so I'll just go ahead and be a jerk) but I don't see this as a potentially productive discussion. Also, I'm sorry that I missed today's channel session as it sounds like it must have been a fun time. But: There are too many separate issues tangled up in this discussion - what's a valid identifier, what do we mean by identifier, what's the expectation of a server when it says foo or doesn't say bar - I don't see any viable way to reach consensus on all that at once if we're not in the same room with the promise of excellent microbrew nearby. We have tabled the discussion of URIs vs non-URIs... it's not open for discussion now. unAPI revision 2 will be unchanged w/r/to its references to URIs. How unAPI should behave relative to resolution when it's implemented through an OpenURL resolver isn't an issue for the spec; it is an implementation choice. Whether unAPI services are really resolvers is good fodder for research papers and blog rants. :) If you want to raise an issue regarding what the spec should say about what clients can/should expect of a server, please re-raise the issue in a way that can be stated in a single sentence and doesn't impinge on all these other issues. The spec is already too long, but, done right, this could be a useful addition. Love, -the Jerk -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From mrylander at gmail.com Mon Mar 6 22:48:45 2006 From: mrylander at gmail.com (Mike Rylander) Date: Mon Mar 6 22:49:49 2006 Subject: [gcs-pcs-list] big day in #code4lib In-Reply-To: <1D614E4E-D91E-41F0-B21B-1541DE31B564@yale.edu> References: <9D8DCB0F-D3DA-4C08-8F4D-97FD0A41395E@yale.edu> <1D614E4E-D91E-41F0-B21B-1541DE31B564@yale.edu> Message-ID: On 3/7/06, Daniel Chudnov wrote: > unAPI can't and shouldn't impose guarantees on anything. um ... that's what I said, unless you mean that even unAPI spans that sit on the same page as the are fair game for failure ... in which case, I agree. (Though I'd hope that's not the normal case, since unAPI is about copy, not link. ;-) ) > If you want to raise an issue regarding what the spec should say > about what clients can/should expect of a server, please re-raise the > issue in a way that can be stated in a single sentence and doesn't > impinge on all these other issues. The spec is already too long, > but, done right, this could be a useful addition. Re-raising (with Robert's help). The server (retriever/resolver/, and identifier producer/publisher) says to the client, "My identifiers are opaque. If they happen to look to YOU like a uri, then you're already looking too close. I'm not going to stop you looking closely, but don't expect your assumptions to be correct today, or, if they are, true here tomorrow." Note: this says nothing about what constitutes an identifier, or who builds it, or whether unAPI is a resolver. Just that identifiers are opaque to the user. > > Love, -the Jerk > Yours truly, the guy that brings out the jerk in dchud ;) -- Mike Rylander mrylander@gmail.com GPLS -- PINES Development Database Developer http://open-ils.org From azaroth at liverpool.ac.uk Tue Mar 7 06:08:26 2006 From: azaroth at liverpool.ac.uk (Robert Sanderson) Date: Tue Mar 7 06:27:05 2006 Subject: [gcs-pcs-list] big day in #code4lib In-Reply-To: <1D614E4E-D91E-41F0-B21B-1541DE31B564@yale.edu> References: <9D8DCB0F-D3DA-4C08-8F4D-97FD0A41395E@yale.edu> <1D614E4E-D91E-41F0-B21B-1541DE31B564@yale.edu> Message-ID: >If you want to raise an issue regarding what the spec should say >about what clients can/should expect of a server, please re-raise the >issue in a way that can be stated in a single sentence and doesn't >impinge on all these other issues. The spec is already too long, >but, done right, this could be a useful addition. "The client can expect only that the server which gave it the identifier will recognise it, and only for an unspecified, limited time after delivering it. Anything else is at the good nature of the server." Second point, which is nothing to do with identifiers: If we were to revisit the introspection document idea (eg the openSearch url template approach) then Jeff and I could have our openURL unapi profile, and Dan and Xiaoming could have their simple named parameters. eg: http://.../unapi?uri={identifier}&format={format} vs http://.../unapi?ctx_ver=1.0&rft_id={identifier}&rft_fmt={format} (Or similar) And everyone(?) would be happy? Rob From mrylander at gmail.com Tue Mar 7 07:59:31 2006 From: mrylander at gmail.com (Mike Rylander) Date: Tue Mar 7 08:00:35 2006 Subject: [gcs-pcs-list] Introspection document (WAS: big day in #code4lib) Message-ID: On 3/7/06, Robert Sanderson wrote: [snip] > If we were to revisit the introspection document idea (eg the openSearch > url template approach) then Jeff and I could have our openURL > unapi profile, and Dan and Xiaoming could have their simple named > parameters. > > eg: > > http://.../unapi?uri={identifier}&format={format} > vs > http://.../unapi?ctx_ver=1.0&rft_id={identifier}&rft_fmt={format} > > (Or similar) > > And everyone(?) would be happy? > I would be [1], and judging by by Dan's initial response to the idea [2] he could be made to be happy. If we get Jeff Young, all three local jerks [*wink, wink*] will be happy. Wouldn't that be something -- everyone wanting and saying the same thing, just like now, but using the /same words/! Wait ... didn't MS just patent that? ;-) > > Rob > _______________________________________________ > gcs-pcs-list mailing list > gcs-pcs-list@cipolo.med.yale.edu > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list > 1. http://cipolo.med.yale.edu/pipermail/gcs-pcs-list/2006-January/000299.html 2. http://cipolo.med.yale.edu/pipermail/gcs-pcs-list/2006-January/000309.html -- Mike Rylander mrylander@gmail.com GPLS -- PINES Development Database Developer http://open-ils.org From jyoung at oclc.org Tue Mar 7 08:51:55 2006 From: jyoung at oclc.org (Young,Jeff (OR)) Date: Tue Mar 7 08:52:25 2006 Subject: [gcs-pcs-list] Introspection document (WAS: big day in #code4lib) Message-ID: > On 3/7/06, Robert Sanderson wrote: > [snip] > > If we were to revisit the introspection document idea (eg the openSearch > > url template approach) then Jeff and I could have our openURL > > unapi profile, and Dan and Xiaoming could have their simple named > > parameters. > > > > eg: > > > > http://.../unapi?uri={identifier}&format={format} > > vs > > > http://.../unapi?ctx_ver=1.0&rft_id={identifier}&rft_fmt={format} l> > > > > (Or similar) > > > > And everyone(?) would be happy? > > > > I would be [1], and judging by by Dan's initial response to the idea > [2] he could be made to be happy. If we get Jeff Young, all three > local jerks [*wink, wink*] will be happy. > > Wouldn't that be something -- everyone wanting and saying the same > thing, just like now, but using the /same words/! Wait ... didn't MS > just patent that? ;-) I'm not familiar with introspection documents. Is there a standard for this that someone can point me at? If so, it sounds like a useful idea. If not, it doesn't make sense to me to invent a proprietary introspection mechanism when simple aliases for the two labels would^D^D^D^D^Dshould make everyone just as happy. Jeff From azaroth at liverpool.ac.uk Tue Mar 7 09:01:18 2006 From: azaroth at liverpool.ac.uk (Rob Sanderson) Date: Tue Mar 7 09:02:24 2006 Subject: [gcs-pcs-list] Introspection document (WAS: big day in #code4lib) In-Reply-To: References: Message-ID: <1141740078.21685.28.camel@helmsdeep> On Tue, 2006-03-07 at 08:51 -0500, Young,Jeff (OR) wrote: > > On 3/7/06, Robert Sanderson wrote: > http://.../unapi?ctx_ver=1.0&rft_id={identifier}&rft_fmt={format} > > I would be [1], and judging by by Dan's initial response to the idea > > [2] he could be made to be happy. If we get Jeff Young, all three > > local jerks [*wink, wink*] will be happy. 4 local jerks, as I'll add myself to the happy jerk pile. (Man, that sounds bad :D) > > Wouldn't that be something -- everyone wanting and saying the same > > thing, just like now, but using the /same words/! Wait ... didn't MS > > just patent that? ;-) Except with slightly different pronunciations. Dan pronounces it 'uri', I pronounce it 'identifier' and Jeff pronounces it 'rft_id' :} (Actually I probably pronounce it the same as Jeff) > I'm not familiar with introspection documents. Is there a standard for > this that someone can point me at? If so, it sounds like a useful idea. > If not, it doesn't make sense to me to invent a proprietary > introspection mechanism when simple aliases for the two labels > would^D^D^D^D^Dshould make everyone just as happy. The format above is stolen wholesale from OpenSearch. I'm not sure if they got it from somewhere else, or just invented it themselves, but we wouldn't be doing evil to re-use it, as far as I can tell. Rob -- Dr Robert Sanderson Dept of Computer Science, University of Liverpool Home: http://www.csc.liv.ac.uk/~azaroth/ Cheshire: http://www.cheshire3.org/ From jyoung at oclc.org Tue Mar 7 09:23:22 2006 From: jyoung at oclc.org (Young,Jeff (OR)) Date: Tue Mar 7 09:23:53 2006 Subject: [gcs-pcs-list] Introspection document (WAS: big day in#code4lib) Message-ID: > > I'm not familiar with introspection documents. Is there a standard for > > this that someone can point me at? If so, it sounds like a useful idea. > > If not, it doesn't make sense to me to invent a proprietary > > introspection mechanism when simple aliases for the two labels > > would^D^D^D^D^Dshould make everyone just as happy. > > The format above is stolen wholesale from OpenSearch. I'm not sure if > they got it from somewhere else, or just invented it themselves, but we > wouldn't be doing evil to re-use it, as far as I can tell. If introspection documents were a widely adopted standard, I could imagine working it into the OpenURL Object Model mechanism and make it work transparently. I can and will put a hook in so these kinds of things can be used as a pre/post-process, but it will be an application-specific thing. There's only so far I'm willing to go to accommodate narrowly-defined standards. Jeff From daniel.chudnov at yale.edu Tue Mar 7 09:26:11 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Tue Mar 7 09:27:17 2006 Subject: [gcs-pcs-list] jerk mode #3 Message-ID: <26AEDB09-B451-41B1-9002-75AABB37A7A3@yale.edu> I'm very excited about all the energy flowing through the list right now. Unfortunately I'm rather backed up during the day (two words: usability testing (and two more: it hurts!)) and seem to keep falling behind only to catch up to find a whole new deep thread started. I don't want to slow anybody down. But, we have a queue of issues to work through. Later today I'll try to close off the issue threads that are hanging open and raise the next items on the list from the head of the queue. New issues get pushed to the tail of the queue. Please keep separate issues in separate threads with (preferably) appropriate subjects, (e.g. the recent "introspection document" thread, nicely done :). Though, anything that revisits a decision we've already made (e.g. revising the introspection doc) should have to wait until we get further through the queue, which means probably after rev2. Don't worry, there's still going to be a rev3 and a voting/ballot version 1 so we will have time to revisit everything. I'm sorry I can't be as responsive just now. Good thing this mailing list thingy is asynchronous. :P -Dan From mrylander at gmail.com Tue Mar 7 09:35:16 2006 From: mrylander at gmail.com (Mike Rylander) Date: Tue Mar 7 09:36:20 2006 Subject: [gcs-pcs-list] jerk mode #3 In-Reply-To: <26AEDB09-B451-41B1-9002-75AABB37A7A3@yale.edu> References: <26AEDB09-B451-41B1-9002-75AABB37A7A3@yale.edu> Message-ID: On 3/7/06, Daniel Chudnov wrote: > I'm very excited about all the energy flowing through the list right > now. Unfortunately I'm rather backed up during the day (two words: > usability testing (and two more: it hurts!)) and seem to keep > falling behind only to catch up to find a whole new deep thread started. > > I don't want to slow anybody down. > > But, we have a queue of issues to work through. Later today I'll try > to close off the issue threads that are hanging open and raise the > next items on the list from the head of the queue. > > New issues get pushed to the tail of the queue. > > Please keep separate issues in separate threads with (preferably) > appropriate subjects, (e.g. the recent "introspection document" > thread, nicely done :). miker_.jerkiness -= 1; // ;-) > > Though, anything that revisits a decision we've already made (e.g. > revising the introspection doc) should have to wait until we get > further through the queue, which means probably after rev2. Don't > worry, there's still going to be a rev3 and a voting/ballot version 1 > so we will have time to revisit everything. Cool. I'm just glad it's going into the queue. And thanks for all the (um...) jerk wrangling, Dan. We all appreciate it, I'm sure. > > I'm sorry I can't be as responsive just now. Good thing this mailing > list thingy is asynchronous. :P What, you need to do work for money?!?! ;) > > -Dan > _______________________________________________ > gcs-pcs-list mailing list > gcs-pcs-list@cipolo.med.yale.edu > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list > -- Mike Rylander mrylander@gmail.com GPLS -- PINES Development Database Developer http://open-ils.org From eric at openly.com Tue Mar 7 10:19:12 2006 From: eric at openly.com (Eric Hellman) Date: Tue Mar 7 10:23:12 2006 Subject: [gcs-pcs-list] more comments (plain text) Message-ID: >Eric Hellman wrote, on Mon, Mar 06, 2006 at 12:23:45PM -0500: >> >> What I'm observing is that there are two types of requests made to an >> unAPI service >> ... >> 2. request for metadata object > >A quick point of information: unAPI makes no functional distinction >between objects and metadata objects. The same functions may refer >to requests for either, relative to the same URI, and nothing in unAPI >itself specifies which is which. right. > > What I'm saying is that responses to (1) should ALWAYS return xml if >> the unAPI service is working, and I shouldn't have to care about http >> status codes. Responses to (2) should be possible to delegate to an >> http stack, or to a browser, or whatever. > >This is worth discussing, so: > >What is the benefit of an xml response on a 404, like you suggest: > > > info:foo/bar > > >There is nothing you can do with that that a 404 doesn't already tell >you. Indeed, if it is a restricted-access item, you will get more >information from a 401 or 403 status code, also, than just examining >this echoed response. Version 0 suggested echoing http status codes >into the response entity format itself; this was voted down by consensus >as the information is already present in the HTTP headers if appropriate >codes are used. > >Your preference for implementing unAPI with an XML handler-centric >processing technique doesn't change the fact that the HTTP functions in >unAPI are an HTTP convention, not an XML protocol. :) the benefit is that the nothing-available response can be handled at the same level as the something-available response (easier to write efficient client code), and that the nothing-available response can be distinguished from the unAPI-service-not-working response (possible to write good error-handling code). Eric -- Eric Hellman, Director OCLC Openly Informatics Division eric@openly.com 2 Broad St., Suite 208 tel 1-973-509-7800 fax 1-734-468-6216 Bloomfield, NJ 07003 http://www.openly.com/1cate/ 1 Click Access To Everything From liu_x at lanl.gov Tue Mar 7 11:20:30 2006 From: liu_x at lanl.gov (Xiaoming Liu) Date: Tue Mar 7 11:19:49 2006 Subject: [gcs-pcs-list] jerk mode #3 In-Reply-To: <26AEDB09-B451-41B1-9002-75AABB37A7A3@yale.edu> References: <26AEDB09-B451-41B1-9002-75AABB37A7A3@yale.edu> Message-ID: On Tue, 7 Mar 2006, Daniel Chudnov wrote: > I don't want to slow anybody down. > > But, we have a queue of issues to work through. Later today I'll try to > close off the issue threads that are hanging open and raise the next items on > the list from the head of the queue. > > New issues get pushed to the tail of the queue. Just see if several issues can get into the queue. They are really entangled and all associated with UNAPI (no parameters) vs. UNAPI?uri=URI. First I list problems: (1) 3.1 and 3.2 in the spec is largely duplicate. Since we are targeting a one-page spec, I think it would be very nice to remove the duplication. (2) the relationships between UNAPI (no parameters) and UNAPI?uri=URI are not clear from the spec. (3) the namespace_uri and schema_location makes the spec very XML centric. (4) The inclusion of "uri" element in UNAPI?uri=URI is kind of subjective to me, and causes duplication of 3.1 and 3.2 My proposal includes: (1) drop schema_location from formats response. (2) drop "uri" element from UNAPI?uri=URI. (3) merge 3.1 and 3.2, following the style of OAI-PMH ListMetadataFormats: "This verb is used to retrieve the metadata formats available from a repository. An optional argument restricts the request to the formats available for a specific item. Arguments * identifier an optional argument that specifies the unique identifier of the item for which available metadata formats are being requested. If this argument is omitted, then the response includes all metadata formats supported by this repository. Note that the fact that a metadata format is supported by a repository does not mean that it can be disseminated from all items in the repository." I am willing to argue each of these points if it gets into the queue. xiaoming From mrylander at gmail.com Tue Mar 7 11:47:42 2006 From: mrylander at gmail.com (Mike Rylander) Date: Tue Mar 7 11:48:48 2006 Subject: [gcs-pcs-list] jerk mode #3 In-Reply-To: References: <26AEDB09-B451-41B1-9002-75AABB37A7A3@yale.edu> Message-ID: On 3/7/06, Xiaoming Liu wrote: > On Tue, 7 Mar 2006, Daniel Chudnov wrote: > > > I don't want to slow anybody down. > > > > But, we have a queue of issues to work through. Later today I'll try to > > close off the issue threads that are hanging open and raise the next items on > > the list from the head of the queue. > > > > New issues get pushed to the tail of the queue. > > > Just see if several issues can get into the queue. They are really > entangled and all associated with UNAPI (no parameters) vs. UNAPI?uri=URI. > > First I list problems: > (1) 3.1 and 3.2 in the spec is largely duplicate. Since we are targeting a > one-page spec, I think it would be very nice to remove the duplication. > Deduplication is good! :) > (2) the relationships between UNAPI (no parameters) and UNAPI?uri=URI are > not clear from the spec. > Really? But maybe I'm just too close to it now to see that... > (3) the namespace_uri and schema_location makes the spec very XML centric. > Since these are optional I don't see them as an issue. If other formats become prevalent and have equivalent validation data we can add those as optional elements. I think it's helpful to provide for the option. > (4) The inclusion of "uri" element in UNAPI?uri=URI is kind of subjective > to me, and causes duplication of 3.1 and 3.2 > I think this can be addressed directly by the description doc queue item ... and it works well enough to not attempt injecting a new item into the queue right now ... IMHO ;) > > My proposal includes: > (1) drop schema_location from formats response. > (2) drop "uri" element from UNAPI?uri=URI. > (3) merge 3.1 and 3.2, following the style of OAI-PMH ListMetadataFormats: > > "This verb is used to retrieve the metadata formats available from a > repository. An optional argument restricts the request to the formats > available for a specific item. > Arguments > > * identifier an optional argument that specifies the unique identifier > of the item for which available metadata formats are being requested. If > this argument is omitted, then the response includes all metadata formats > supported by this repository. Note that the fact that a metadata format is > supported by a repository does not mean that it can be disseminated from > all items in the repository." > > I am willing to argue each of these points if it gets into the queue. > > xiaoming > > > > _______________________________________________ > gcs-pcs-list mailing list > gcs-pcs-list@cipolo.med.yale.edu > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list > -- Mike Rylander mrylander@gmail.com GPLS -- PINES Development Database Developer http://open-ils.org From liu_x at lanl.gov Tue Mar 7 11:51:04 2006 From: liu_x at lanl.gov (Xiaoming Liu) Date: Tue Mar 7 11:50:25 2006 Subject: [gcs-pcs-list] client-side xslt rendering issue In-Reply-To: References: <26AEDB09-B451-41B1-9002-75AABB37A7A3@yale.edu> Message-ID: This is another issue, again I am willing to discuss once it gets into the queue, but perhaps the answer is self-evident, as I am not well-informed about common practice in this area. The problem is raised by Jeff's wikiD implementation, such as http://alcme.oclc.org/wikid/CollectionGsafd, the response is in XML format with a link to stylesheet, therefore only client-side XSL rendering can discover it's an unAPI page. I think this raises how unAPI client should behave, whether they are supposed to do XSLT rendering, etc. xiaoming From daniel.chudnov at yale.edu Tue Mar 7 16:20:54 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Tue Mar 7 16:22:00 2006 Subject: [gcs-pcs-list] another unAPI implementation. Message-ID: <00A7899B-5A1A-4F75-BD13-C8E54064795B@yale.edu> canarydatabase.org has been liberated! Python, quixote-1 as web framework, quixote's PTL as templating language. Record views have unapi-uris: http://canarydatabase.org/record/403?view=canary The export page uses direct unapi links inside unapi-uris: http://canarydatabase.org/record/403?view=export If you log in and save records or sets, the export links for those are similarly unapi links inside unapi-uris. I think it's up to spec. edsu, have you had a chance to look more closely at testing? -Dan From lists at hubmed.org Tue Mar 7 19:57:00 2006 From: lists at hubmed.org (Alf Eaton) Date: Tue Mar 7 20:00:09 2006 Subject: [gcs-pcs-list] unapi/live clipboard Message-ID: The blog post at apparently describes something Ray Ozzie (of Microsoft) talked about at ETech today - a UI for copy/pasting on the web. There are some screencasts linked from the post and a web demo here: I tried to use this method with unapi just now, but I can't see a way to do it - the information to be copied has to be written in the page at the time the user selects 'Copy', so - because it doesn't use the oncopy method (not supported by Firefox?) - there's no place to fetch remote data or present a list of possible formats after the Copy event has happened. There's also a related Anil Dash post here: alf. From daniel.chudnov at yale.edu Tue Mar 7 20:35:07 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Tue Mar 7 20:36:12 2006 Subject: [gcs-pcs-list] unapi/live clipboard In-Reply-To: References: Message-ID: <0D93C7BB-E361-4D9C-8FFE-7B76A418FA73@yale.edu> On Mar 7, 2006, at 7:57 PM, Alf Eaton wrote: > The blog post at apparently describes > something Ray Ozzie (of Microsoft) talked about at ETech today - a > UI for copy/pasting on the web. There are some screencasts linked > from the post and a web demo here: rayozzie/demo/liveclip/liveclipsample/clipboardexample.html> I > tried to use this method with unapi just now, but I can't see a way > to do it - the information to be copied has to be written in the > page at the time the user selects 'Copy', so - because it doesn't > use the oncopy method (not supported by Firefox?) - there's no > place to fetch remote data or present a list of possible formats > after the Copy event has happened. > > There's also a related Anil Dash post here: 2006/03/05/reinventing_cop> Well, so, now we have independent and irrefutable corroboration that what we're working on is something the rest of the world wants. Who knows how soon they'll get specs or libraries published. In the meantime we've got a head start on an *extremely* simple knob that anybody can turn and experiment with. Onward! -dc -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From ehs at pobox.com Tue Mar 7 22:53:10 2006 From: ehs at pobox.com (Edward Summers) Date: Tue Mar 7 22:53:45 2006 Subject: [gcs-pcs-list] another unAPI implementation. In-Reply-To: <00A7899B-5A1A-4F75-BD13-C8E54064795B@yale.edu> References: <00A7899B-5A1A-4F75-BD13-C8E54064795B@yale.edu> Message-ID: On Mar 7, 2006, at 3:20 PM, Daniel Chudnov wrote: > I think it's up to spec. edsu, have you had a chance to look more > closely at testing? It's coming along. I now have a ruby unapi client library which includes a braindead command line validator that does most of what you outlined in the previous email. I'm going to clean up the validator code and then abstract it so it can be called in different contexts (command line, web app, irc?) and then see about putting up a little webapp in the next few days. In the meantime I've made the code available: svn co http://www.textualize.com/svn/unapi/trunk/ unapi browse online: http://www.textualize.com/trac/browser/unapi/trunk Here's the output of turning it loose on the canary. I'm not sure if the (few) errors are legit. But it's a start I think. I should be uploading the gem shortly to ease installation...once the project gets approved on rubyforge. //Ed -- % unapi_validator.rb http://canarydatabase.org/record/403?view=canary validating unapi page at http://canarydatabase.org/record/403? view=canary 1 - OK: url found for unapi service: http://canarydatabase.org/ unapi 2 - OK: formats request for unapi service has content-type application/xml 3 - OK: formats request for unapi service returned 200 status code 4 - OK: found 4 formats for unapi service 5 - OK: format 1 for unapi service has name=endnote 6 - OK: format 1 for unapi service has type=text/plain 7 - OK: format 2 for unapi service has name=bibtex 8 - OK: format 2 for unapi service has type=text/plain 9 - OK: format 3 for unapi service has name=ris 10 - OK: format 3 for unapi service has type=text/plain 11 - OK: format 4 for unapi service has name=mods 12 - OK: format 4 for unapi service has type=application/xml 13 - OK: found 1 unapi-uris on the page 14 - OK: got unapi-uri http://canarydatabase.org/record/403 15 - OK: formats request for http://canarydatabase.org/record/403 has content-type application/xml 16 - OK: formats request for http://canarydatabase.org/record/403 return 300 status code 17 - OK: found 4 formats for http://canarydatabase.org/record/403 18 - OK: format 1 for http://canarydatabase.org/record/403 has name=endnote 19 - OK: format 1 for http://canarydatabase.org/record/403 has type=text/plain 20 - OK: format 2 for http://canarydatabase.org/record/403 has name=bibtex 21 - OK: format 2 for http://canarydatabase.org/record/403 has type=text/plain 22 - OK: format 3 for http://canarydatabase.org/record/403 has name=ris 23 - OK: format 3 for http://canarydatabase.org/record/403 has type=text/plain 24 - OK: format 4 for http://canarydatabase.org/record/403 has name=mods 25 - OK: format 4 for http://canarydatabase.org/record/403 has type=application/xml 26 - OK: request for uri http://canarydatabase.org/record/403 with bad format returns 415 27 - OK: request for http://canarydatabase.org/record/403 content responded with 200 status code 28 - OK: request for http://canarydatabase.org/record/403 content returned data (560 bytes) 29 - OK: request for http://canarydatabase.org/record/403 returned mime type text/plain 30 - ERROR: request for invalid uri with valid format endnote returned 400 31 - OK: request for http://canarydatabase.org/record/403 content responded with 200 status code 32 - OK: request for http://canarydatabase.org/record/403 content returned data (726 bytes) 33 - OK: request for http://canarydatabase.org/record/403 returned mime type text/plain 34 - ERROR: request for invalid uri with valid format bibtex returned 400 35 - OK: request for http://canarydatabase.org/record/403 content responded with 200 status code 36 - OK: request for http://canarydatabase.org/record/403 content returned data (645 bytes) 37 - OK: request for http://canarydatabase.org/record/403 returned mime type text/plain 38 - ERROR: request for invalid uri with valid format ris returned 400 39 - OK: request for http://canarydatabase.org/record/403 content responded with 200 status code 40 - OK: request for http://canarydatabase.org/record/403 content returned data (2256 bytes) 41 - OK: request for http://canarydatabase.org/record/403 returned mime type application/xml 42 - ERROR: request for invalid uri with valid format mods returned 400 tests=42 errors=4 From daniel.chudnov at yale.edu Wed Mar 8 01:24:37 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Wed Mar 8 01:25:42 2006 Subject: [gcs-pcs-list] unapi.info up Message-ID: Have a look: http://unapi.info/ I started this up several days ago after Eric's usability suggestion. I think it links to all the known implementations on the examples page. I took a few liberties with "marketing copy" and spec formatting. Nothing drastic and nothing that changes the specifics. Some list members and spec development participants in #code4lib suggested that I assign the copyright of the site and spec in my own name under a CC license. Please let me know if that concerns you. I would prefer that it not be solely in my name but the CC license allows fairly liberal rights anyway. Seemed important to get done tonight, but tweaks/fixes/updates are easily managed. :) -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From azaroth at liverpool.ac.uk Wed Mar 8 06:43:36 2006 From: azaroth at liverpool.ac.uk (Rob Sanderson) Date: Wed Mar 8 06:48:03 2006 Subject: [gcs-pcs-list] Schema/Location etc In-Reply-To: References: Message-ID: <1141818216.23631.36.camel@helmsdeep> To add to queue: * Simplify unapi? document in terms of formats to JUST list format names * Add unapi?format=FORMAT which returns a descriptive document concerning that format. In this way we don't have to trouble people with schema_location (etc) in the main introspection document, but the information is still discoverable. Rob -- Dr Robert Sanderson Dept of Computer Science, University of Liverpool Home: http://www.csc.liv.ac.uk/~azaroth/ Cheshire: http://www.cheshire3.org/ From ehs at pobox.com Wed Mar 8 08:46:46 2006 From: ehs at pobox.com (Edward Summers) Date: Wed Mar 8 08:47:21 2006 Subject: [gcs-pcs-list] unapi.info up In-Reply-To: References: Message-ID: On Mar 8, 2006, at 12:24 AM, Daniel Chudnov wrote: > Have a look: > > http://unapi.info/ > > I started this up several days ago after Eric's usability > suggestion. I think it links to all the known implementations on > the examples page. Nice lookin' -- dchud++. //Ed From ross.singer at library.gatech.edu Wed Mar 8 09:32:57 2006 From: ross.singer at library.gatech.edu (Ross Singer) Date: Wed Mar 8 09:34:03 2006 Subject: [gcs-pcs-list] unapi.info up In-Reply-To: References: Message-ID: <23b83f160603080632s2a00bbccp879e2ff1a2a5a4cc@mail.gmail.com> Agreed, this is a slick site. Thanks, Dan! -Ross. On 3/8/06, Edward Summers wrote: > > On Mar 8, 2006, at 12:24 AM, Daniel Chudnov wrote: > > Have a look: > > > > http://unapi.info/ > > > > I started this up several days ago after Eric's usability > > suggestion. I think it links to all the known implementations on > > the examples page. > > Nice lookin' -- dchud++. > > //Ed > _______________________________________________ > gcs-pcs-list mailing list > gcs-pcs-list@cipolo.med.yale.edu > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://cipolo.med.yale.edu/pipermail/gcs-pcs-list/attachments/20060308/35f1b959/attachment.htm From daniel.chudnov at yale.edu Wed Mar 8 11:10:04 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Wed Mar 8 11:10:06 2006 Subject: vote: status codes (was Re: [gcs-pcs-list] (possible) issue: what to do for redirects?) In-Reply-To: <20060306160036.GB8742@sildin.med.yale.edu> References: <20060303173902.GD26227@sildin.med.yale.edu> <20060305210440.GG3728@sildin.med.yale.edu> <20060306160036.GB8742@sildin.med.yale.edu> Message-ID: <20060308161002.GB10725@sildin.med.yale.edu> See below for background. This thread seems like a lifetime ago somehow. :) I know I said we shouldn't revisit decisions we've already made, but it seems best to first consider removing all mentions of particular status codes from the normative portion of the spec. Please vote on this whole change as a full diff; if you don't like part of it for any reason, vote it down, and we'll amend for another vote. -Dan Proposed change: - Change the last para under How it works which now reads: "To minimize the scope of this specification, unAPI uses existing HTTP status codes with the meaning most appropriate for a particular unAPI response. See the section "Notes on HTTP status codes and error handling" below for a detailed summary." ...to instead read: "unAPI uses the response status codes defined in HTTP [RFC 2616] to indicate the success or failure of an operation. See the section "Recommended HTTP status codes and error handling (non-normative)" below for suggestions of particularly useful status codes." (note: the first line is verbatim from APP.) - In the UNAPI (no parameters) response section, first para, remove the text: "status code should be 200." - In the UNAPI?uri=URI response section, second para, remove the text: "status code should be 300 (Multiple Choices)" - Retitle the "Notes on HTTP status codes and error handling" to: "Recommended HTTP status codes and error handling (non-normative)" ...and rewrite its content to say: "unAPI defers to the response status codes already defined in HTTP [RFC 2616]. In particular, it is recommended that unAPI implementors utilize the following: * 300 Multiple Choices - the UNAPI?uri=URI function * 404 Not Found - requests for a URI that is not available on the server * 415 Unsupported Media Type - requests for a URI that is available on the server but for a format that is not available for that URI Note that this list is provided as a guideline to encourage consistency across implementations. All HTTP status codes are relevant for any web resource; these status codes are particularly germane for unAPI." Daniel Chudnov wrote, on Mon, Mar 06, 2006 at 11:00:36AM -0500: > Xiaoming Liu wrote, on Mon, Mar 06, 2006 at 08:04:05AM -0700: > > > > Thanks for catching key point for me. It's really about whether these > > status code are recommendation/best practice, or mandatory. I am much > > comfortable if we put them as recommendation, therefore not part of > > compliance check. > > Okay, so, I think we're converging on the same point here: we defer > to HTTP itself, but maybe suggest a few particular codes. Maybe the > suggestions are even non-normative, and we don't require specific response > codes for "unAPI compliance". > > Does anyone want to take a stab at rewriting that final bit on HTTP codes? -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From ehs at pobox.com Wed Mar 8 11:16:16 2006 From: ehs at pobox.com (Ed Summers) Date: Wed Mar 8 11:17:21 2006 Subject: vote: status codes (was Re: [gcs-pcs-list] (possible) issue: what to do for redirects?) In-Reply-To: <20060308161002.GB10725@sildin.med.yale.edu> References: <20060303173902.GD26227@sildin.med.yale.edu> <20060305210440.GG3728@sildin.med.yale.edu> <20060306160036.GB8742@sildin.med.yale.edu> <20060308161002.GB10725@sildin.med.yale.edu> Message-ID: +1 I particularly like the collection of status codes in one place and making them recommended. Using language from the atom-publishing-protocol also is nice :-) //Ed From leigh at ldodds.com Wed Mar 8 12:02:52 2006 From: leigh at ldodds.com (Leigh Dodds) Date: Wed Mar 8 12:06:49 2006 Subject: vote: status codes (was Re: [gcs-pcs-list] (possible) issue: what to do for redirects?) In-Reply-To: <20060308161002.GB10725@sildin.med.yale.edu> References: <20060303173902.GD26227@sildin.med.yale.edu> <20060305210440.GG3728@sildin.med.yale.edu> <20060306160036.GB8742@sildin.med.yale.edu> <20060308161002.GB10725@sildin.med.yale.edu> Message-ID: <440F0E3C.6090507@ldodds.com> Hi all, My first post to the list, having signed up to catch up on latest unAPI discussions. Apologies for jumping in, especially if this has already been debated, but I noticed this: > * 415 Unsupported Media Type - requests for a URI that is available > on the server but for a format that is not available for that URI 415 isn't really suitable here. It's for use when the server is "refusing to service the request because the entity of the request is in a format not supported by the request resource for the requested method". There's no entity being sent here. I think 406 Not Acceptable is erm, more acceptable: "The resource identified by the request is only capable of generating response entities which have content characteristics not acceptable according to the accept headers sent in the request". Granted unAPI isn't using Content Negotiation (i.e. Accept headers), but it is a form of "poor man's content negotiation" (thats not meant to be derogatory!) in that that the desired content is being specified in the URL parameters rather than the HTTP protocol. Cheers, L. -- Home: http://www.ldodds.com | "Simplicity is the ultimate Blog: http://www.ldodds.com/blog | sophistication" -- Leonardo da Vinci From azaroth at liverpool.ac.uk Wed Mar 8 12:04:50 2006 From: azaroth at liverpool.ac.uk (Rob Sanderson) Date: Wed Mar 8 12:09:13 2006 Subject: vote: status codes (was Re: [gcs-pcs-list] (possible) issue: what to do for redirects?) In-Reply-To: <20060308161002.GB10725@sildin.med.yale.edu> References: <20060303173902.GD26227@sildin.med.yale.edu> <20060305210440.GG3728@sildin.med.yale.edu> <20060306160036.GB8742@sildin.med.yale.edu> <20060308161002.GB10725@sildin.med.yale.edu> Message-ID: <1141837490.23631.76.camel@helmsdeep> +1 Is it even able to be put in a table: Identifier: | Known Unknown -------------------------------------------- Format Known | 200 404 Format Unknown | 415 415? 404? No parameters: 300 Rob On Wed, 2006-03-08 at 11:10 -0500, Daniel Chudnov wrote: > "unAPI defers to the response status codes already defined in HTTP > [RFC 2616]. In particular, it is recommended that unAPI implementors > utilize the following: > * 300 Multiple Choices - the UNAPI?uri=URI function > * 404 Not Found - requests for a URI that is not available on the > server > * 415 Unsupported Media Type - requests for a URI that is available > on the server but for a format that is not available for that URI > Note that this list is provided as a guideline to encourage consistency > across implementations. All HTTP status codes are relevant for any > web resource; these status codes are particularly germane for unAPI." -- Dr Robert Sanderson Dept of Computer Science, University of Liverpool Home: http://www.csc.liv.ac.uk/~azaroth/ Cheshire: http://www.cheshire3.org/ From liu_x at lanl.gov Wed Mar 8 12:24:47 2006 From: liu_x at lanl.gov (Xiaoming Liu) Date: Wed Mar 8 12:24:05 2006 Subject: vote: status codes (was Re: [gcs-pcs-list] (possible) issue: what to do for redirects?) In-Reply-To: <20060308161002.GB10725@sildin.med.yale.edu> References: <20060303173902.GD26227@sildin.med.yale.edu> <20060305210440.GG3728@sildin.med.yale.edu> <20060306160036.GB8742@sildin.med.yale.edu> <20060308161002.GB10725@sildin.med.yale.edu> Message-ID: +1 On Wed, 8 Mar 2006, Daniel Chudnov wrote: > See below for background. This thread seems like a lifetime ago > somehow. :) I know I said we shouldn't revisit decisions we've already > made, but it seems best to first consider removing all mentions of > particular status codes from the normative portion of the spec. > > Please vote on this whole change as a full diff; if you don't like > part of it for any reason, vote it down, and we'll amend for another > vote. > > -Dan > > > Proposed change: > > - Change the last para under How it works which now reads: > > "To minimize the scope of this specification, unAPI uses existing > HTTP status codes with the meaning most appropriate for a particular > unAPI response. See the section "Notes on HTTP status codes and error > handling" below for a detailed summary." > > ...to instead read: > > "unAPI uses the response status codes defined in HTTP [RFC 2616] to > indicate the success or failure of an operation. See the section > "Recommended HTTP status codes and error handling (non-normative)" > below for suggestions of particularly useful status codes." > > (note: the first line is verbatim from APP.) > > - In the UNAPI (no parameters) response section, first para, remove the > text: > > "status code should be 200." > > - In the UNAPI?uri=URI response section, second para, remove the text: > > "status code should be 300 (Multiple Choices)" > > - Retitle the "Notes on HTTP status codes and error handling" to: > > "Recommended HTTP status codes and error handling (non-normative)" > > ...and rewrite its content to say: > > "unAPI defers to the response status codes already defined in HTTP > [RFC 2616]. In particular, it is recommended that unAPI implementors > utilize the following: > > * 300 Multiple Choices - the UNAPI?uri=URI function > > * 404 Not Found - requests for a URI that is not available on the > server > > * 415 Unsupported Media Type - requests for a URI that is available > on the server but for a format that is not available for that URI > > Note that this list is provided as a guideline to encourage consistency > across implementations. All HTTP status codes are relevant for any > web resource; these status codes are particularly germane for unAPI." > > > > > > Daniel Chudnov wrote, on Mon, Mar 06, 2006 at 11:00:36AM -0500: >> Xiaoming Liu wrote, on Mon, Mar 06, 2006 at 08:04:05AM -0700: >>> >>> Thanks for catching key point for me. It's really about whether these >>> status code are recommendation/best practice, or mandatory. I am much >>> comfortable if we put them as recommendation, therefore not part of >>> compliance check. >> >> Okay, so, I think we're converging on the same point here: we defer >> to HTTP itself, but maybe suggest a few particular codes. Maybe the >> suggestions are even non-normative, and we don't require specific response >> codes for "unAPI compliance". >> >> Does anyone want to take a stab at rewriting that final bit on HTTP codes? > > From azaroth at liverpool.ac.uk Wed Mar 8 12:50:15 2006 From: azaroth at liverpool.ac.uk (Rob Sanderson) Date: Wed Mar 8 12:54:49 2006 Subject: vote: status codes (was Re: [gcs-pcs-list] (possible) issue: what to do for redirects?) In-Reply-To: <440F0E3C.6090507@ldodds.com> References: <20060303173902.GD26227@sildin.med.yale.edu> <20060305210440.GG3728@sildin.med.yale.edu> <20060306160036.GB8742@sildin.med.yale.edu> <20060308161002.GB10725@sildin.med.yale.edu> <440F0E3C.6090507@ldodds.com> Message-ID: <1141840215.23631.82.camel@helmsdeep> On Wed, 2006-03-08 at 17:02 +0000, Leigh Dodds wrote: > > * 415 Unsupported Media Type - requests for a URI that is available > > on the server but for a format that is not available for that URI > > 415 isn't really suitable here. It's for use when the server is > "refusing to service the request because the entity of the request is > in a format not supported by the request resource for the requested > method". There's no entity being sent here. Isn't the 'entity' here the object identified by the URI? eg, one description I quickly found: Your Web server thinks that the HTTP data stream sent by the client identifies a resource whose actual media type 1) does not agree with the media type specified on the request or 2) is incompatible with the current data for the resource or 3) is incompatible with the HTTP method specified on the request. The media type in the request (by the format param) is not compatible with the object identified (by the URI param). Which is countered by a second description equally quickly found: This code is returned when a server refuses a request because the message body is in an inappropriate format. Which talks explicitly about the message body. I guess that's the downside with using HTTP error codes for non HTTP errors! Rob From mrylander at gmail.com Wed Mar 8 13:12:03 2006 From: mrylander at gmail.com (Mike Rylander) Date: Wed Mar 8 13:13:06 2006 Subject: vote: status codes (was Re: [gcs-pcs-list] (possible) issue: what to do for redirects?) In-Reply-To: <20060308161002.GB10725@sildin.med.yale.edu> References: <20060303173902.GD26227@sildin.med.yale.edu> <20060305210440.GG3728@sildin.med.yale.edu> <20060306160036.GB8742@sildin.med.yale.edu> <20060308161002.GB10725@sildin.med.yale.edu> Message-ID: +1 On 3/8/06, Daniel Chudnov wrote: > See below for background. This thread seems like a lifetime ago > somehow. :) I know I said we shouldn't revisit decisions we've already > made, but it seems best to first consider removing all mentions of > particular status codes from the normative portion of the spec. > > Please vote on this whole change as a full diff; if you don't like > part of it for any reason, vote it down, and we'll amend for another > vote. > > -Dan > > > Proposed change: > > - Change the last para under How it works which now reads: > > "To minimize the scope of this specification, unAPI uses existing > HTTP status codes with the meaning most appropriate for a particular > unAPI response. See the section "Notes on HTTP status codes and error > handling" below for a detailed summary." > > ...to instead read: > > "unAPI uses the response status codes defined in HTTP [RFC 2616] to > indicate the success or failure of an operation. See the section > "Recommended HTTP status codes and error handling (non-normative)" > below for suggestions of particularly useful status codes." > > (note: the first line is verbatim from APP.) > > - In the UNAPI (no parameters) response section, first para, remove the > text: > > "status code should be 200." > > - In the UNAPI?uri=URI response section, second para, remove the text: > > "status code should be 300 (Multiple Choices)" > > - Retitle the "Notes on HTTP status codes and error handling" to: > > "Recommended HTTP status codes and error handling (non-normative)" > > ...and rewrite its content to say: > > "unAPI defers to the response status codes already defined in HTTP > [RFC 2616]. In particular, it is recommended that unAPI implementors > utilize the following: > > * 300 Multiple Choices - the UNAPI?uri=URI function > > * 404 Not Found - requests for a URI that is not available on the > server > > * 415 Unsupported Media Type - requests for a URI that is available > on the server but for a format that is not available for that URI > > Note that this list is provided as a guideline to encourage consistency > across implementations. All HTTP status codes are relevant for any > web resource; these status codes are particularly germane for unAPI." > > > > > > Daniel Chudnov wrote, on Mon, Mar 06, 2006 at 11:00:36AM -0500: > > Xiaoming Liu wrote, on Mon, Mar 06, 2006 at 08:04:05AM -0700: > > > > > > Thanks for catching key point for me. It's really about whether these > > > status code are recommendation/best practice, or mandatory. I am much > > > comfortable if we put them as recommendation, therefore not part of > > > compliance check. > > > > Okay, so, I think we're converging on the same point here: we defer > > to HTTP itself, but maybe suggest a few particular codes. Maybe the > > suggestions are even non-normative, and we don't require specific response > > codes for "unAPI compliance". > > > > Does anyone want to take a stab at rewriting that final bit on HTTP codes? > > -- > Daniel Chudnov > Yale Center for Medical Informatics > (203) 737-5789 > _______________________________________________ > gcs-pcs-list mailing list > gcs-pcs-list@cipolo.med.yale.edu > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list > -- Mike Rylander mrylander@gmail.com GPLS -- PINES Development Database Developer http://open-ils.org From leftwing at alumni.rutgers.edu Wed Mar 8 14:00:54 2006 From: leftwing at alumni.rutgers.edu (Michael J. Giarlo) Date: Wed Mar 8 14:02:00 2006 Subject: vote: status codes (was Re: [gcs-pcs-list] (possible) issue: what to do for redirects?) In-Reply-To: References: <20060303173902.GD26227@sildin.med.yale.edu> <20060305210440.GG3728@sildin.med.yale.edu> <20060306160036.GB8742@sildin.med.yale.edu> <20060308161002.GB10725@sildin.med.yale.edu> Message-ID: <22dbc4ae0603081100u349058edjccb28f94e5a5f2f3@mail.gmail.com> +1 On 3/8/06, Mike Rylander wrote: > > +1 > > On 3/8/06, Daniel Chudnov wrote: > > See below for background. This thread seems like a lifetime ago > > somehow. :) I know I said we shouldn't revisit decisions we've already > > made, but it seems best to first consider removing all mentions of > > particular status codes from the normative portion of the spec. > > > > Please vote on this whole change as a full diff; if you don't like > > part of it for any reason, vote it down, and we'll amend for another > > vote. > > > > -Dan > > > > > > Proposed change: > > > > - Change the last para under How it works which now reads: > > > > "To minimize the scope of this specification, unAPI uses existing > > HTTP status codes with the meaning most appropriate for a particular > > unAPI response. See the section "Notes on HTTP status codes and error > > handling" below for a detailed summary." > > > > ...to instead read: > > > > "unAPI uses the response status codes defined in HTTP [RFC 2616] to > > indicate the success or failure of an operation. See the section > > "Recommended HTTP status codes and error handling (non-normative)" > > below for suggestions of particularly useful status codes." > > > > (note: the first line is verbatim from APP.) > > > > - In the UNAPI (no parameters) response section, first para, remove the > > text: > > > > "status code should be 200." > > > > - In the UNAPI?uri=URI response section, second para, remove the text: > > > > "status code should be 300 (Multiple Choices)" > > > > - Retitle the "Notes on HTTP status codes and error handling" to: > > > > "Recommended HTTP status codes and error handling (non-normative)" > > > > ...and rewrite its content to say: > > > > "unAPI defers to the response status codes already defined in HTTP > > [RFC 2616]. In particular, it is recommended that unAPI implementors > > utilize the following: > > > > * 300 Multiple Choices - the UNAPI?uri=URI function > > > > * 404 Not Found - requests for a URI that is not available on the > > server > > > > * 415 Unsupported Media Type - requests for a URI that is available > > on the server but for a format that is not available for that URI > > > > Note that this list is provided as a guideline to encourage > consistency > > across implementations. All HTTP status codes are relevant for any > > web resource; these status codes are particularly germane for unAPI." > > > > > > > > > > > > Daniel Chudnov wrote, on Mon, Mar 06, 2006 at 11:00:36AM -0500: > > > Xiaoming Liu wrote, on Mon, Mar 06, 2006 at 08:04:05AM -0700: > > > > > > > > Thanks for catching key point for me. It's really about whether > these > > > > status code are recommendation/best practice, or mandatory. I am > much > > > > comfortable if we put them as recommendation, therefore not part of > > > > compliance check. > > > > > > Okay, so, I think we're converging on the same point here: we defer > > > to HTTP itself, but maybe suggest a few particular codes. Maybe the > > > suggestions are even non-normative, and we don't require specific > response > > > codes for "unAPI compliance". > > > > > > Does anyone want to take a stab at rewriting that final bit on HTTP > codes? > > > > -- > > Daniel Chudnov > > Yale Center for Medical Informatics > > (203) 737-5789 > > _______________________________________________ > > gcs-pcs-list mailing list > > gcs-pcs-list@cipolo.med.yale.edu > > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list > > > > > -- > Mike Rylander > mrylander@gmail.com > GPLS -- PINES Development > Database Developer > http://open-ils.org > _______________________________________________ > gcs-pcs-list mailing list > gcs-pcs-list@cipolo.med.yale.edu > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://cipolo.med.yale.edu/pipermail/gcs-pcs-list/attachments/20060308/191888e6/attachment-0001.htm From daniel.chudnov at yale.edu Wed Mar 8 14:21:15 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Wed Mar 8 14:21:16 2006 Subject: vote: status codes (was Re: [gcs-pcs-list] (possible) issue: what to do for redirects?) In-Reply-To: <1141840215.23631.82.camel@helmsdeep> References: <20060303173902.GD26227@sildin.med.yale.edu> <20060305210440.GG3728@sildin.med.yale.edu> <20060306160036.GB8742@sildin.med.yale.edu> <20060308161002.GB10725@sildin.med.yale.edu> <440F0E3C.6090507@ldodds.com> <1141840215.23631.82.camel@helmsdeep> Message-ID: <20060308192114.GB10803@sildin.med.yale.edu> Welcome Leigh! First - as a point of information, see this thread: http://cipolo.med.yale.edu/pipermail/gcs-pcs-list/2006-March/000473.html Rob Sanderson wrote, on Wed, Mar 08, 2006 at 05:50:15PM +0000: > On Wed, 2006-03-08 at 17:02 +0000, Leigh Dodds wrote: > > > > * 415 Unsupported Media Type - requests for a URI that is available > > > on the server but for a format that is not available for that URI > > > > 415 isn't really suitable here. It's for use when the server is > > "refusing to service the request because the entity of the request is > > in a format not supported by the request resource for the requested > > method". There's no entity being sent here. > > Isn't the 'entity' here the object identified by the URI? I think the "entity" here should be "UNAPI?uri=URI&format=FORMAT", which is to say, please, server, give me URI in FORMAT, or, "this server's representation of URI in FORMAT". That contrasting with "the object identified by the URI." If it's what I think it is, it seems reasonable to say "the server is refusing to service the request because the entity of the request is not in a supported format by the request format." But, seeing as it's not clear that this is the correct interpretation, and we're on a not-specifying codes kick, I'll flag "revisit 415 vs. 406" for a later revision for now. -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From daniel.chudnov at yale.edu Wed Mar 8 14:33:14 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Wed Mar 8 14:33:16 2006 Subject: [gcs-pcs-list] next issue on the list Message-ID: <20060308193314.GC10803@sildin.med.yale.edu> The next item is actually what we were just discussing, too. It looks like it will pass, though it hasn't been very long so I'll hold it open for 24 hours before closing it in case there's any major dissent. But, since it looks like it will pass, I'll go ahead and close off this next item: "What is the appropriate status code for a successful URI+FORMAT response resulting in a redirect? "301 Moved Permanently" doesn't seem right. Perhaps 302 Found? Or should we not specify?" ...since we (have so far practically) agreed that it's not our business to specify. -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From daniel.chudnov at yale.edu Wed Mar 8 14:38:54 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Wed Mar 8 14:38:56 2006 Subject: [gcs-pcs-list] next next issue: Location header? Message-ID: <20060308193854.GA11171@sildin.med.yale.edu> The issue is this: "Should we specify anything about server having the option of adding a Location header to URI+FORMAT response?" ...or, for the sake of conversation: s/URI+FORMAT/any unAPI/ I think the one common thing we found earlier about having a Location header is that when it's there, with the most commonly used 3xx responses, most common clients (IE, FX, Safari, wget) just go straight to the Location header value. This is a tricky issue. On one hand, our burgeoning "defer to HTTP" strategy has me wanting to "specify nothing" here. On the other hand, maybe there's a common use case we can add a recommendation for, at least. -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From daniel.chudnov at yale.edu Wed Mar 8 14:58:16 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Wed Mar 8 14:58:18 2006 Subject: [gcs-pcs-list] fyi for newer folks re: recordkeeping Message-ID: <20060308195816.GB11171@sildin.med.yale.edu> For folks who've joined recently who might think I'm making up "next issues" out of thin air, I'm not. There's a basecamp group for unAPI which has restricted access where we manage milestone dates, todos, and the working version of the spec. When new issues come up I do a rough sort into a reasonable place in the existing list. Stuff like the tabled identifier debate can occasionally be requeued from front to back, too. All are welcome to have access... write me if you want it (send a username, email, and password to get you in... call, email, or im me if you want to do it privately, though it's not particularly secure). But, there is nothing we do there that isn't formally discussed here on-list... this list is the formal list of record for all development activies. Indeed use of the commenting functions in basecamp aren't tracked very closely, if at all. The basecamp group is about record-keeping and not losing track of what we've done or need to do. So, if you're not in it, you won't miss anything. I'm currently culling to-do issues from the last week of discussion. Rest assured... there's still lots to discuss. I'm also adding a "consider interoperation with MS live clipboard technique" issue. Alf, could I trouble you to tell us a bit more about your latest hublog post? -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From leigh at ldodds.com Wed Mar 8 15:29:10 2006 From: leigh at ldodds.com (Leigh Dodds) Date: Wed Mar 8 15:33:10 2006 Subject: [gcs-pcs-list] Revisiting 415 vs 406 In-Reply-To: <20060308192114.GB10803@sildin.med.yale.edu> References: <20060303173902.GD26227@sildin.med.yale.edu> <20060305210440.GG3728@sildin.med.yale.edu> <20060306160036.GB8742@sildin.med.yale.edu> <20060308161002.GB10725@sildin.med.yale.edu> <440F0E3C.6090507@ldodds.com> <1141840215.23631.82.camel@helmsdeep> <20060308192114.GB10803@sildin.med.yale.edu> Message-ID: <440F3E96.2010003@ldodds.com> (assigned a new subject line to keep discussion separate from voting) Daniel Chudnov wrote: > First - as a point of information, see this thread: > > http://cipolo.med.yale.edu/pipermail/gcs-pcs-list/2006-March/000473.html Thanks for the pointer! >Rob Sanderson wrote, on Wed, Mar 08, 2006 at 05:50:15PM +0000: >>Isn't the 'entity' here the object identified by the URI? >Daniel Chudnov wrote: > I think the "entity" here should be "UNAPI?uri=URI&format=FORMAT", which > is to say, please, server, give me URI in FORMAT, or, "this server's > representation of URI in FORMAT". That contrasting with "the object > identified by the URI." The relevant section of RFC 2616 is Section 7, http://rfc.net/rfc2616.html#p42: "Request and Response messages MAY transfer an entity if not otherwise restricted by the request method or response status code. An entity consists of entity-header fields and an entity-body, although some responses will only include the entity-headers." And an Entity is decomposed into Entity headers (e.g. Content-* headers) and an Entity Body, e.g. contents of a POST request, response from a GET request. The Request URL is therefore not formally part of the Entity. It identifies the resource to which the request is addressed. So typically a "415 Unsupported Media Type" would be returned by a server to which you'd POST'd (say) an Atom document and that server only understood RSS. And that doesn't fit the unAPI use case. "406 Not Acceptable" is defined for use where the client wants a specific format and the server can't provide it. Reading, http://rfc.net/rfc2616.html#p67 we get: " The resource identified by the request is only capable of generating response entities which have content characteristics not acceptable according to the accept headers sent in the request. " Which seems a good fit for an unAPI implementation not being able to fulfill a particular FORMAT request. That section also includes some best practice advice: " ...the response SHOULD include an entity containing a list of available entity characteristics and location(s) from which the user or user agent can choose the one most appropriate. " So you might want to consider encouraging implementations to return the 406 status code AND the same response body as they would for GET UNAPI?uri=URI, i.e. the list of available formats for that URI. "Sorry guv, can't do that, try one of these instead" :) Cheers, L. -- Home: http://www.ldodds.com | "Simplicity is the ultimate Blog: http://www.ldodds.com/blog | sophistication" -- Leonardo da Vinci From leigh at ldodds.com Wed Mar 8 15:44:41 2006 From: leigh at ldodds.com (Leigh Dodds) Date: Wed Mar 8 15:44:50 2006 Subject: [gcs-pcs-list] next next issue: Location header? In-Reply-To: <20060308193854.GA11171@sildin.med.yale.edu> References: <20060308193854.GA11171@sildin.med.yale.edu> Message-ID: <440F4239.5010707@ldodds.com> Daniel Chudnov wrote: > The issue is this: > > "Should we specify anything about server having the option of adding > a Location header to URI+FORMAT response?" > > ...or, for the sake of conversation: s/URI+FORMAT/any unAPI/ > > I think the one common thing we found earlier about having a Location > header is that when it's there, with the most commonly used 3xx > responses, most common clients (IE, FX, Safari, wget) just go straight > to the Location header value. Yes, they're legimately allowed to do so by the HTTP specification. (aside for 301 and none GET/HEAD requests, anyway) > This is a tricky issue. On one hand, our burgeoning "defer to HTTP" > strategy has me wanting to "specify nothing" here. On the other hand, > maybe there's a common use case we can add a recommendation for, at least. The Location header is for use with 201 (Created) and the 3XX redirect responses. I'd hazard that the common use case for needing a Location header, i.e. communicating to the client that a there's data "over there" is handled by one of the HTTP redirect statuses. 302 Found seems the best fit for this use case (leaving 301/307 for redirects relating to the unAPI impl itself: "we've moved, please go here in future") Cheers, L. -- Home: http://www.ldodds.com | "Simplicity is the ultimate Blog: http://www.ldodds.com/blog | sophistication" -- Leonardo da Vinci From azaroth at liverpool.ac.uk Wed Mar 8 15:51:42 2006 From: azaroth at liverpool.ac.uk (Robert Sanderson) Date: Wed Mar 8 15:54:57 2006 Subject: [gcs-pcs-list] Re: Revisiting 415 vs 406 In-Reply-To: <440F3E96.2010003@ldodds.com> References: <20060303173902.GD26227@sildin.med.yale.edu> <20060305210440.GG3728@sildin.med.yale.edu> <20060306160036.GB8742@sildin.med.yale.edu> <20060308161002.GB10725@sildin.med.yale.edu> <440F0E3C.6090507@ldodds.com> <1141840215.23631.82.camel@helmsdeep> <20060308192114.GB10803@sildin.med.yale.edu> <440F3E96.2010003@ldodds.com> Message-ID: >"Request and Response messages MAY transfer an entity if >not otherwise restricted by the request method or response status >code. An entity consists of entity-header fields and an entity-body, >although some responses will only include the entity-headers." >So typically a "415 Unsupported Media Type" would be returned by a >server to which you'd POST'd (say) an Atom document and that >server only understood RSS. And that doesn't fit the unAPI use >case. Yep, I'm convinced :) Rob From mrylander at gmail.com Wed Mar 8 17:52:13 2006 From: mrylander at gmail.com (Mike Rylander) Date: Wed Mar 8 17:53:16 2006 Subject: [gcs-pcs-list] next issue on the list In-Reply-To: <20060308193314.GC10803@sildin.med.yale.edu> References: <20060308193314.GC10803@sildin.med.yale.edu> Message-ID: On 3/8/06, Daniel Chudnov wrote: > The next item is actually what we were just discussing, too. It looks > like it will pass, though it hasn't been very long so I'll hold it open > for 24 hours before closing it in case there's any major dissent. > > But, since it looks like it will pass, I'll go ahead and close off this > next item: > > "What is the appropriate status code for a successful URI+FORMAT > response resulting in a redirect? "301 Moved Permanently" doesn't seem > right. Perhaps 302 Found? Or should we not specify?" > > ...since we (have so far practically) agreed that it's not our business > to specify. I vote for moving this to the non-normative Recommended Responses document, and recommending 302. That's what, at least, 2 implementations do today. > > -Dan > > > -- > Daniel Chudnov > Yale Center for Medical Informatics > (203) 737-5789 > _______________________________________________ > gcs-pcs-list mailing list > gcs-pcs-list@cipolo.med.yale.edu > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list > -- Mike Rylander mrylander@gmail.com GPLS -- PINES Development Database Developer http://open-ils.org From mrylander at gmail.com Wed Mar 8 18:28:36 2006 From: mrylander at gmail.com (Mike Rylander) Date: Wed Mar 8 18:29:40 2006 Subject: [gcs-pcs-list] next next issue: Location header? In-Reply-To: <440F4239.5010707@ldodds.com> References: <20060308193854.GA11171@sildin.med.yale.edu> <440F4239.5010707@ldodds.com> Message-ID: On 3/8/06, Leigh Dodds wrote: > Daniel Chudnov wrote: > > > The issue is this: > > > > "Should we specify anything about server having the option of adding > > a Location header to URI+FORMAT response?" > > > > ...or, for the sake of conversation: s/URI+FORMAT/any unAPI/ > > > > I think the one common thing we found earlier about having a Location > > header is that when it's there, with the most commonly used 3xx > > responses, most common clients (IE, FX, Safari, wget) just go straight > > to the Location header value. > > Yes, they're legimately allowed to do so by the HTTP specification. > (aside for 301 and none GET/HEAD requests, anyway) > > > This is a tricky issue. On one hand, our burgeoning "defer to HTTP" > > strategy has me wanting to "specify nothing" here. On the other hand, > > maybe there's a common use case we can add a recommendation for, at least. > > The Location header is for use with 201 (Created) and the 3XX redirect > responses. > > I'd hazard that the common use case for needing a Location header, i.e. > communicating to the client that a there's data "over there" is handled > by one of the HTTP redirect statuses. 302 Found seems the best fit for > this use case (leaving 301/307 for redirects relating to the unAPI > impl itself: "we've moved, please go here in future") This aligns well with what is currently implemented in at least 2 places... so, again, I vote for recommending what existing implementations do (read: we know it's useful and, nominally, non-confusing). > > Cheers, > > L. > > -- > Home: http://www.ldodds.com | "Simplicity is the ultimate > Blog: http://www.ldodds.com/blog | sophistication" -- Leonardo da Vinci > _______________________________________________ > gcs-pcs-list mailing list > gcs-pcs-list@cipolo.med.yale.edu > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list > -- Mike Rylander mrylander@gmail.com GPLS -- PINES Development Database Developer http://open-ils.org From lists at hubmed.org Wed Mar 8 20:24:42 2006 From: lists at hubmed.org (Alf Eaton) Date: Wed Mar 8 20:27:51 2006 Subject: [gcs-pcs-list] fyi for newer folks re: recordkeeping In-Reply-To: <20060308195816.GB11171@sildin.med.yale.edu> References: <20060308195816.GB11171@sildin.med.yale.edu> Message-ID: <545823EA-B7F6-496C-BC0C-EEE8345CF02D@hubmed.org> On 08 Mar 2006, at 14:58, Daniel Chudnov wrote: > I'm also adding a "consider interoperation with MS live clipboard > technique" issue. Alf, could I trouble you to tell us a bit more > about > your latest hublog post? Sure, though I'm still trying to decide how useful it is. After seeing the Live Clipboard demonstration I wondered if there was a way to make it use URIs (and unAPI in the background) instead of carrying around chunks of XML, so I made a demo that lets you copy a URI from one page and paste it into another, fetching the details for that object via unAPI in the background. Ideally, I suppose, it should do the fetching at the point where you copy the item, but at that time you don't know what format the place you're pasting it into is going to want. Live Clipboard gets around this by using one standard format for each type of microcontent (hCal for events, hCard for personal details, etc); some people suggest using RDF as the transport format; unAPI seems to suggest just using the URI as the transport format and letting the recipient figure out what to do with it. If you were using any old identifiers while copy/pasting using this method, not just URIs, you'd have to attach the base URL for the unAPI server to the identifier at the point where it's copied to the clipboard (or let the recipient of the pasted identifer know which page it came from so it could go and look up the base unAPI URL for itself). alf. From mrylander at gmail.com Wed Mar 8 20:50:14 2006 From: mrylander at gmail.com (Mike Rylander) Date: Wed Mar 8 20:51:18 2006 Subject: [gcs-pcs-list] fyi for newer folks re: recordkeeping In-Reply-To: <545823EA-B7F6-496C-BC0C-EEE8345CF02D@hubmed.org> References: <20060308195816.GB11171@sildin.med.yale.edu> <545823EA-B7F6-496C-BC0C-EEE8345CF02D@hubmed.org> Message-ID: On 3/9/06, Alf Eaton wrote: > On 08 Mar 2006, at 14:58, Daniel Chudnov wrote: > > > I'm also adding a "consider interoperation with MS live clipboard > > technique" issue. Alf, could I trouble you to tell us a bit more > > about > > your latest hublog post? > > Sure, though I'm still trying to decide how useful it is. After > seeing the Live Clipboard demonstration I wondered if there was a way > to make it use URIs (and unAPI in the background) instead of carrying > around chunks of XML, so I made a demo archives/001324.html> that lets you copy a URI from one page and > paste it into another, fetching the details for that object via unAPI > in the background. > > Ideally, I suppose, it should do the fetching at the point where you > copy the item, but at that time you don't know what format the place > you're pasting it into is going to want. Live Clipboard gets around > this by using one standard format for each type of microcontent (hCal > for events, hCard for personal details, etc); some people suggest > using RDF as the transport format; unAPI seems to suggest just using > the URI as the transport format and letting the recipient figure out > what to do with it. > > If you were using any old identifiers while copy/pasting using this > method, not just URIs, you'd have to attach the base URL for the > unAPI server to the identifier at the point where it's copied to the > clipboard (or let the recipient of the pasted identifer know which > page it came from so it could go and look up the base unAPI URL for > itself). Don't you have to do this with URIs as well? I just assumed that the demo was wired up to go to the hubmed unAPI server with all identifiers that you pasted into the text box. Is that not true? > > alf. > _______________________________________________ > gcs-pcs-list mailing list > gcs-pcs-list@cipolo.med.yale.edu > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list > -- Mike Rylander mrylander@gmail.com GPLS -- PINES Development Database Developer http://open-ils.org From lists at hubmed.org Wed Mar 8 20:58:28 2006 From: lists at hubmed.org (Alf Eaton) Date: Wed Mar 8 20:58:28 2006 Subject: [gcs-pcs-list] fyi for newer folks re: recordkeeping In-Reply-To: References: <20060308195816.GB11171@sildin.med.yale.edu> <545823EA-B7F6-496C-BC0C-EEE8345CF02D@hubmed.org> Message-ID: <41AD532C-6969-4DF0-A72D-41015A03A06E@hubmed.org> On 08 Mar 2006, at 20:50, Mike Rylander wrote: > On 3/9/06, Alf Eaton wrote: >> ... >> If you were using any old identifiers while copy/pasting using this >> method, not just URIs, you'd have to attach the base URL for the >> unAPI server to the identifier at the point where it's copied to the >> clipboard (or let the recipient of the pasted identifer know which >> page it came from so it could go and look up the base unAPI URL for >> itself). > > Don't you have to do this with URIs as well? I just assumed that the > demo was wired up to go to the hubmed unAPI server with all > identifiers that you pasted into the text box. Is that not true? It is wired that way, but if I knew of other unAPI servers that could deal with other URI formats then I could make the javascript in that page call them instead. If local identifiers were pasted in then they'd have to have something associated with them (essentially making them into URIs) so that the script would know where to fetch the data from. alf. From liu_x at lanl.gov Thu Mar 9 00:06:11 2006 From: liu_x at lanl.gov (Xiaoming Liu) Date: Thu Mar 9 00:05:27 2006 Subject: [gcs-pcs-list] fyi for newer folks re: recordkeeping In-Reply-To: <545823EA-B7F6-496C-BC0C-EEE8345CF02D@hubmed.org> References: <20060308195816.GB11171@sildin.med.yale.edu> <545823EA-B7F6-496C-BC0C-EEE8345CF02D@hubmed.org> Message-ID: On Wed, 8 Mar 2006, Alf Eaton wrote: > On 08 Mar 2006, at 14:58, Daniel Chudnov wrote: > >> I'm also adding a "consider interoperation with MS live clipboard >> technique" issue. Alf, could I trouble you to tell us a bit more about >> your latest hublog post? > > Sure, though I'm still trying to decide how useful it is. After seeing the > Live Clipboard demonstration I wondered if there was a way to make it use > URIs (and unAPI in the background) instead of carrying around chunks of XML, > so I made a demo that lets > you copy a URI from one page and paste it into another, fetching the details > for that object via unAPI in the background. > > Ideally, I suppose, it should do the fetching at the point where you copy the > item, but at that time you don't know what format the place you're pasting it > into is going to want. Live Clipboard gets around this by using one standard > format for each type of microcontent (hCal for events, hCard for personal > details, etc); some people suggest using RDF as the transport format; unAPI > seems to suggest just using the URI as the transport format and letting the > recipient figure out what to do with it. I am not sure how much I got live Clipboard, but looking at their demos really helps a lot [http://spaces.msn.com/editorial/rayozzie/demo/liveclip/screencast/liveclipdemo.html], so perhaps helpful to others too. The last three examples are more advanced than microcontent copy, they are about copying RSS feeds URL, and in the pasted site these RSS feeds are dynamically loaded. Put it another way, the data is "live" in pasted site. Well, I think this is associated with our discussion of unAPI here. It seems like we can use Clipboard to copy URI+unAPI baseURL, and, the data is also "live" in pasted site in two senses: (a) the pasted site can decide which formats to use (b) the pasted site can decide to use other unAPI baseURL. I guess the question is about how to plug URI+unAPI into live clipboard, like the hcalendar or RSS feed. Not sure if there is going to be an API or have to read the source code, lots to learn here. But my initial impression is that they are compensative technologies, similar to the relationsahip between RSS and Clipboard. xiaoming > > If you were using any old identifiers while copy/pasting using this method, > not just URIs, you'd have to attach the base URL for the unAPI server to the > identifier at the point where it's copied to the clipboard (or let the > recipient of the pasted identifer know which page it came from so it could go > and look up the base unAPI URL for itself). > > alf. > _______________________________________________ > gcs-pcs-list mailing list > gcs-pcs-list@cipolo.med.yale.edu > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list -- Xiaoming From liu_x at lanl.gov Thu Mar 9 01:11:27 2006 From: liu_x at lanl.gov (Xiaoming Liu) Date: Thu Mar 9 01:10:42 2006 Subject: [gcs-pcs-list] next issue on the list In-Reply-To: <20060308193314.GC10803@sildin.med.yale.edu> References: <20060308193314.GC10803@sildin.med.yale.edu> Message-ID: On Wed, 8 Mar 2006, Daniel Chudnov wrote: > The next item is actually what we were just discussing, too. It looks > like it will pass, though it hasn't been very long so I'll hold it open > for 24 hours before closing it in case there's any major dissent. > > But, since it looks like it will pass, I'll go ahead and close off this > next item: > > "What is the appropriate status code for a successful URI+FORMAT > response resulting in a redirect? "301 Moved Permanently" doesn't seem > right. Perhaps 302 Found? Or should we not specify?" > > ...since we (have so far practically) agreed that it's not our business > to specify. I would vote to ingore this issue, for following reasons: (1) keep the spec in one page. (2) we didn't say more than rfc2616 has specified. xiaoming > > -Dan > > > From lists at hubmed.org Thu Mar 9 01:33:42 2006 From: lists at hubmed.org (Alf Eaton) Date: Thu Mar 9 01:36:46 2006 Subject: [gcs-pcs-list] fyi for newer folks re: recordkeeping In-Reply-To: References: <20060308195816.GB11171@sildin.med.yale.edu> <545823EA-B7F6-496C-BC0C-EEE8345CF02D@hubmed.org> Message-ID: <08D4ABAA-0504-4B1B-8ED5-C8E036A58DEC@hubmed.org> On 09 Mar 2006, at 00:06, Xiaoming Liu wrote: > The last three examples are more advanced than microcontent copy, > they are about copying RSS feeds URL, and in the pasted site these > RSS feeds are dynamically loaded. Put it another way, the data is > "live" in pasted site. I still don't really understand why the RSS subscription/live updates thing was in the Live Clipboard demo (I suppose it's the Live bit, but they're not really related). If there was ever a perfect place for demonstrating the utility of copying/pasting a URL and not microcontent XML, feed subscription would be it. alf. From liu_x at lanl.gov Thu Mar 9 01:40:37 2006 From: liu_x at lanl.gov (Xiaoming Liu) Date: Thu Mar 9 01:39:51 2006 Subject: [gcs-pcs-list] next next issue: Location header? In-Reply-To: <440F4239.5010707@ldodds.com> References: <20060308193854.GA11171@sildin.med.yale.edu> <440F4239.5010707@ldodds.com> Message-ID: On Wed, 8 Mar 2006, Leigh Dodds wrote: >> "Should we specify anything about server having the option of adding >> a Location header to URI+FORMAT response?" >> >> ...or, for the sake of conversation: s/URI+FORMAT/any unAPI/ >> >> I think the one common thing we found earlier about having a Location >> header is that when it's there, with the most commonly used 3xx responses, >> most common clients (IE, FX, Safari, wget) just go straight >> to the Location header value. > > Yes, they're legimately allowed to do so by the HTTP specification. > (aside for 301 and none GET/HEAD requests, anyway) > >> This is a tricky issue. On one hand, our burgeoning "defer to HTTP" >> strategy has me wanting to "specify nothing" here. On the other hand, >> maybe there's a common use case we can add a recommendation for, at least. > > The Location header is for use with 201 (Created) and the 3XX redirect > responses. > > I'd hazard that the common use case for needing a Location header, i.e. > communicating to the client that a there's data "over there" is handled > by one of the HTTP redirect statuses. 302 Found seems the best fit for > this use case (leaving 301/307 for redirects relating to the unAPI > impl itself: "we've moved, please go here in future") for related issues, please check thread http://cipolo.med.yale.edu/pipermail/gcs-pcs-list/2006-February/000393.html and http://cipolo.med.yale.edu/pipermail/gcs-pcs-list/2006-March/000503.html This is particularly related to using 300 as an indicator of "multiple choices", and how to handle Location header in 300. Please share your insight about this problem. Myself will vote to "specify nothing", besides keeping things simple, I also think this is eventually an implementor's choice (remember we have some 10+ opinions about what "go" means). Although this can be a good topic for FAQ. xiaoming From liu_x at lanl.gov Thu Mar 9 02:46:15 2006 From: liu_x at lanl.gov (Xiaoming Liu) Date: Thu Mar 9 02:45:29 2006 Subject: [gcs-pcs-list] Revisiting 415 vs 406 In-Reply-To: <440F3E96.2010003@ldodds.com> References: <20060303173902.GD26227@sildin.med.yale.edu> <20060305210440.GG3728@sildin.med.yale.edu> <20060306160036.GB8742@sildin.med.yale.edu> <20060308161002.GB10725@sildin.med.yale.edu> <440F0E3C.6090507@ldodds.com> <1141840215.23631.82.camel@helmsdeep> <20060308192114.GB10803@sildin.med.yale.edu> <440F3E96.2010003@ldodds.com> Message-ID: On Wed, 8 Mar 2006, Leigh Dodds wrote: > (assigned a new subject line to keep discussion separate > from voting) > > > So typically a "415 Unsupported Media Type" would be returned by a > server to which you'd POST'd (say) an Atom document and that > server only understood RSS. And that doesn't fit the unAPI use > case. > > "406 Not Acceptable" is defined for use where the client wants a > specific format and the server can't provide it. Reading, > http://rfc.net/rfc2616.html#p67 we get: > > The resource identified by the request is only capable of > generating response entities which have content characteristics > not acceptable according to the accept headers sent in the > request. > " > > Which seems a good fit for an unAPI implementation not being able > to fulfill a particular FORMAT request. > > That section also includes some best practice advice: > > " > ...the response SHOULD include an entity containing a list of > available entity characteristics and location(s) from which > the user or user agent can choose the one most appropriate. > " > > So you might want to consider encouraging implementations > to return the 406 status code AND the same response body > as they would for GET UNAPI?uri=URI, i.e. the list of > available formats for that URI. > > "Sorry guv, can't do that, try one of these instead" :) > Thanks for the clear analysis, I got a better understanding now. Agree 415 is not appropriate in this case. But Dan's concern about 406 still remains: > Note that we are not currently addressing accept headers in unAPI > (not that it hasn't come up :). 400 is perhaps another candidate but too broad: 10.4.1 400 Bad Request The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications. I guess discussion will go on with this issue. xiaoming From jyoung at oclc.org Thu Mar 9 07:14:28 2006 From: jyoung at oclc.org (Young,Jeff (OR)) Date: Thu Mar 9 07:14:58 2006 Subject: [gcs-pcs-list] Cool URLs Message-ID: Sorry if this has been covered before. It occurred to me this morning that there would be numerous advantages if the unAPI "resolver" mechanism was based on "Cool URLs" (http://www.w3.org/Provider/Style/URI). For example, instead of this: http://UNAPISERVER?uri=IDENTIFIER&format=FORMAT You could use this instead: http://UNAPISERVER/IDENTIFIER and http://UNAPISERVER/IDENTIFIER.FORMAT This approach produces natural looking URLs, it avoids the smell of OpenURL Lite, the fuss about URIs could become moot, and (if the response codes don't get out-of-hand) it could be implemented with nothing more than a series of documents stored on a bare Apache server. There are other advantages, but that's enough for now. This seems ideal to me. Sorry I didn't think of it sooner, though. Jeff > -----Original Message----- > From: gcs-pcs-list-bounces@cipolo.med.yale.edu [mailto:gcs-pcs-list- > bounces@cipolo.med.yale.edu] On Behalf Of Xiaoming Liu > Sent: Thursday, March 09, 2006 2:46 AM > To: Leigh Dodds > Cc: gcs-pcs-list@cipolo.med.yale.edu > Subject: Re: [gcs-pcs-list] Revisiting 415 vs 406 > > On Wed, 8 Mar 2006, Leigh Dodds wrote: > > > (assigned a new subject line to keep discussion separate > > from voting) > > > > > > So typically a "415 Unsupported Media Type" would be returned by a > > server to which you'd POST'd (say) an Atom document and that > > server only understood RSS. And that doesn't fit the unAPI use > > case. > > > > "406 Not Acceptable" is defined for use where the client wants a > > specific format and the server can't provide it. Reading, > > http://rfc.net/rfc2616.html#p67 we get: > > > > The resource identified by the request is only capable of > > generating response entities which have content characteristics > > not acceptable according to the accept headers sent in the > > request. > > " > > > > Which seems a good fit for an unAPI implementation not being able > > to fulfill a particular FORMAT request. > > > > That section also includes some best practice advice: > > > > " > > ...the response SHOULD include an entity containing a list of > > available entity characteristics and location(s) from which > > the user or user agent can choose the one most appropriate. > > " > > > > So you might want to consider encouraging implementations > > to return the 406 status code AND the same response body > > as they would for GET UNAPI?uri=URI, i.e. the list of > > available formats for that URI. > > > > "Sorry guv, can't do that, try one of these instead" :) > > > > > Thanks for the clear analysis, I got a better understanding now. Agree 415 > is not appropriate in this case. > > But Dan's concern about 406 still remains: > > > Note that we are not currently addressing accept headers in unAPI > > (not that it hasn't come up :). > > 400 is perhaps another candidate but too broad: > 10.4.1 400 Bad Request > The request could not be understood by the server due to malformed > syntax. The client SHOULD NOT repeat the request without > modifications. > > I guess discussion will go on with this issue. > > xiaoming > _______________________________________________ > gcs-pcs-list mailing list > gcs-pcs-list@cipolo.med.yale.edu > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list From azaroth at liverpool.ac.uk Thu Mar 9 07:35:38 2006 From: azaroth at liverpool.ac.uk (Robert Sanderson) Date: Thu Mar 9 07:38:50 2006 Subject: [gcs-pcs-list] Cool URLs (& Introspection) In-Reply-To: References: Message-ID: Jeff wrote: >Instead of http://UNAPISERVER?uri=IDENTIFIER&format=FORMAT >You could use this instead: >http://UNAPISERVER/IDENTIFIER >http://UNAPISERVER/IDENTIFIER.FORMAT If we had an OpenSearch like introspection document, you could say: http://UNAPISERVER/{identifier}.{format} :) My list of Url styles is now: http://server/path?query={identifier}&recordSchema={format} http://server/path?rft_id={identifier}&rft_fmt={format} http://server/path?identifier={identifier}&metadataPrefix={format} http://server/path?uri={identifier}&format={format} http://server/{identifier}.{format} (No need to have a map to OpenSearch as it already has arbitrary field names, and no prizes for matching protocol to url style) Rob From leigh at ldodds.com Thu Mar 9 07:51:41 2006 From: leigh at ldodds.com (Leigh Dodds) Date: Thu Mar 9 07:55:35 2006 Subject: [gcs-pcs-list] Cool URLs In-Reply-To: References: Message-ID: <441024DD.1030800@ldodds.com> Young,Jeff (OR) wrote: > http://UNAPISERVER?uri=IDENTIFIER&format=FORMAT > > You could use this instead: > > http://UNAPISERVER/IDENTIFIER > and > http://UNAPISERVER/IDENTIFIER.FORMAT Except file name extensions are less cool than parameters see "What to leave out" in the Cool URIs doc. The FORMAT bit can be made cooler by encouraging use of appropriate media type (if available) rather than arbitrary strings. E.g. format=application/xml. Cooler still would be encouraging support for Accept: headers. Then an unAPI implementation would allow ?uri=IDENTIFIER assuming there was an appropriate Accept header. This too is easy to handle with flat files and Apache configs. Cheers, L. -- Home: http://www.ldodds.com | "Simplicity is the ultimate Blog: http://www.ldodds.com/blog | sophistication" -- Leonardo da Vinci From daniel.chudnov at yale.edu Thu Mar 9 08:32:52 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Thu Mar 9 08:33:57 2006 Subject: [gcs-pcs-list] Cool URLs In-Reply-To: References: Message-ID: <00655F3E-0BFE-4E9C-B70C-7BBD6C66C1D5@yale.edu> On Mar 9, 2006, at 7:14 AM, Young,Jeff (OR) wrote: > Sorry if this has been covered before. > > It occurred to me this morning that there would be numerous advantages > if the unAPI "resolver" mechanism was based on "Cool URLs" > (http://www.w3.org/Provider/Style/URI). For example, instead of this: > > http://UNAPISERVER?uri=IDENTIFIER&format=FORMAT > > You could use this instead: > > http://UNAPISERVER/IDENTIFIER > and > http://UNAPISERVER/IDENTIFIER.FORMAT I'd refer you all to earlier discussion where we overwhelmingly agreed to switch to GET parameters for several reasons. This is not an open issue. -Dan From jyoung at oclc.org Thu Mar 9 08:44:27 2006 From: jyoung at oclc.org (Young,Jeff (OR)) Date: Thu Mar 9 08:45:03 2006 Subject: [gcs-pcs-list] Cool URLs Message-ID: This is the section of "Cool URLs" I had in mind: http://www.w3.org/Provider/Style/URI#remove In the case of unAPI, I could interpret "content negotiation" as producing the format selection list that points at "References which do have the extension [which] will still work". This has nothing to do with unAPIs mandate, but some clients can't handle parameters. For example, imagine I have a document with format=xsl. I can't use such a URL as a reference in an XML stylesheet reference (at least using XERCES). It simply won't accept URLs references with parameters. I have no idea why, but it sometimes forces me to munge my URLs to satisfy it. Rob informs me that unAPI started down this path early on, and changed directions. It seems I'm merely echoing the past with this idea. Sorry. Jeff > -----Original Message----- > From: Leigh Dodds [mailto:leigh@ldodds.com] > Sent: Thursday, March 09, 2006 7:52 AM > To: Young,Jeff (OR) > Cc: gcs-pcs-list@cipolo.med.yale.edu > Subject: Re: [gcs-pcs-list] Cool URLs > > Young,Jeff (OR) wrote: > > > http://UNAPISERVER?uri=IDENTIFIER&format=FORMAT > > > > You could use this instead: > > > > http://UNAPISERVER/IDENTIFIER > > and > > http://UNAPISERVER/IDENTIFIER.FORMAT > > Except file name extensions are less cool than parameters > see "What to leave out" in the Cool URIs doc. > > The FORMAT bit can be made cooler by encouraging use of appropriate > media type (if available) rather than arbitrary strings. E.g. > format=application/xml. > > Cooler still would be encouraging support for Accept: headers. > > Then an unAPI implementation would allow ?uri=IDENTIFIER > assuming there was an appropriate Accept header. This too is > easy to handle with flat files and Apache configs. > > Cheers, > > L. > > -- > Home: http://www.ldodds.com | "Simplicity is the ultimate > Blog: http://www.ldodds.com/blog | sophistication" -- Leonardo da Vinci From eric at openly.com Thu Mar 9 11:06:38 2006 From: eric at openly.com (Eric Hellman) Date: Thu Mar 9 11:10:52 2006 Subject: [gcs-pcs-list] Process documentation- was Cool URLs In-Reply-To: <00655F3E-0BFE-4E9C-B70C-7BBD6C66C1D5@yale.edu> References: <00655F3E-0BFE-4E9C-B70C-7BBD6C66C1D5@yale.edu> Message-ID: One thing I am learning from the ongoing rollout of the COinS spec is that there is a very important audience that wants to know the justifications for all the important design choices. The typical member of this audience is a technical guru at an organization that can afford to have a technical guru. If you haven't clearly spelled out all the decisions that were made and the reasons behind them in a FAQ behind the spec, you need to fight to regain credibility with this audience. In other words, people like Leigh and Jeff would have gone away if they didn't already know and respect the people involved. Since the hoped-for audience for unAPI is mostly people both within and without the library business who don't already know and respect this disorderly group of individuals. This needs to be worked on. Yes, I know it's coming, but the FAQ should be there BEFORE issues get closed down. Eric At 8:32 AM -0500 3/9/06, Daniel Chudnov wrote: >On Mar 9, 2006, at 7:14 AM, Young,Jeff (OR) wrote: > >>Sorry if this has been covered before. >> >>It occurred to me this morning that there would be numerous advantages >>if the unAPI "resolver" mechanism was based on "Cool URLs" >>(http://www.w3.org/Provider/Style/URI). For example, instead of this: >> >>http://UNAPISERVER?uri=IDENTIFIER&format=FORMAT >> >>You could use this instead: >> >>http://UNAPISERVER/IDENTIFIER >>and >>http://UNAPISERVER/IDENTIFIER.FORMAT > >I'd refer you all to earlier discussion where we overwhelmingly >agreed to switch to GET parameters for several reasons. > >This is not an open issue. > > -Dan -- Eric Hellman, Director OCLC Openly Informatics Division eric@openly.com 2 Broad St., Suite 208 tel 1-973-509-7800 fax 1-734-468-6216 Bloomfield, NJ 07003 http://www.openly.com/1cate/ 1 Click Access To Everything From daniel.chudnov at yale.edu Thu Mar 9 13:49:03 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Thu Mar 9 13:49:04 2006 Subject: [gcs-pcs-list] COinS and the live clipboard Message-ID: <20060309184902.GA13702@sildin.med.yale.edu> I think somebody said it already somewhere (on #code4lib?) but COinS + Live Clipboard might just be magical. -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From lists at hubmed.org Thu Mar 9 14:16:56 2006 From: lists at hubmed.org (Alf Eaton) Date: Thu Mar 9 14:20:01 2006 Subject: [gcs-pcs-list] COinS and the live clipboard In-Reply-To: <20060309184902.GA13702@sildin.med.yale.edu> References: <20060309184902.GA13702@sildin.med.yale.edu> Message-ID: On 09 Mar 2006, at 13:49, Daniel Chudnov wrote: > I think somebody said it already somewhere (on #code4lib?) but COinS + > Live Clipboard might just be magical. The trouble with COinS, or ContextObjects in general, with Live Clipboard is that there just aren't any defined OpenURL schema for all the different microcontent types. The people involved in microformats have done all this work, which is why the current Live Clipboard demo uses their XML schema (even if they didn't credit them for it ;-), whereas OpenURL doesn't have formats for addresses, events, reviews, audio, etc (at least not as far as I know). alf. From daniel.chudnov at yale.edu Thu Mar 9 14:26:33 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Thu Mar 9 14:26:35 2006 Subject: [gcs-pcs-list] COinS and the live clipboard In-Reply-To: References: <20060309184902.GA13702@sildin.med.yale.edu> Message-ID: <20060309192633.GC13702@sildin.med.yale.edu> Alf Eaton wrote, on Thu, Mar 09, 2006 at 02:16:56PM -0500: > On 09 Mar 2006, at 13:49, Daniel Chudnov wrote: > > The trouble with COinS, or ContextObjects in general, with Live > Clipboard is that there just aren't any defined OpenURL schema for > all the different microcontent types. The people involved in > microformats have done all this work, which is why the current Live > Clipboard demo uses their XML schema (even if they didn't credit them > for it ;-), whereas OpenURL doesn't have formats for addresses, > events, reviews, audio, etc (at least not as far as I know). Totally true. I meant more for journal and book references, though. :) -dc -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From jyoung at oclc.org Thu Mar 9 14:31:12 2006 From: jyoung at oclc.org (Young,Jeff (OR)) Date: Thu Mar 9 14:31:58 2006 Subject: [gcs-pcs-list] COinS and the live clipboard Message-ID: Dan Chudnov wrote, on Thu, Mar 09, 2006 at 02:27:00PM -0500: > > Alf Eaton wrote, on Thu, Mar 09, 2006 at 02:16:56PM -0500: > > On 09 Mar 2006, at 13:49, Daniel Chudnov wrote: > > > > The trouble with COinS, or ContextObjects in general, with Live > > Clipboard is that there just aren't any defined OpenURL schema for > > all the different microcontent types. The people involved in > > microformats have done all this work, which is why the current Live > > Clipboard demo uses their XML schema (even if they didn't credit them > > for it ;-), whereas OpenURL doesn't have formats for addresses, > > events, reviews, audio, etc (at least not as far as I know). > > Totally true. I meant more for journal and book references, though. :) These formats aren't currently registered, but they could be. OCLC has applied to become the OpenURL Registry maintenance agency, and once that happens officially I expect to open it up for contributions as soon as I can. Jeff From liu_x at lanl.gov Thu Mar 9 14:39:02 2006 From: liu_x at lanl.gov (Xiaoming Liu) Date: Thu Mar 9 14:38:17 2006 Subject: [gcs-pcs-list] COinS and the live clipboard In-Reply-To: <20060309192633.GC13702@sildin.med.yale.edu> References: <20060309184902.GA13702@sildin.med.yale.edu> <20060309192633.GC13702@sildin.med.yale.edu> Message-ID: On Thu, 9 Mar 2006, Daniel Chudnov wrote: > Alf Eaton wrote, on Thu, Mar 09, 2006 at 02:16:56PM -0500: >> On 09 Mar 2006, at 13:49, Daniel Chudnov wrote: >> >> The trouble with COinS, or ContextObjects in general, with Live >> Clipboard is that there just aren't any defined OpenURL schema for >> all the different microcontent types. The people involved in >> microformats have done all this work, which is why the current Live >> Clipboard demo uses their XML schema (even if they didn't credit them >> for it ;-), whereas OpenURL doesn't have formats for addresses, >> events, reviews, audio, etc (at least not as far as I know). > > Totally true. I meant more for journal and book references, though. :) > I think you can just copy ContextObject as a string using Live Clipboard, it indeed opens the window for copying/pasting ContextObject (which can be anything) between applications. xiaoming From daniel.chudnov at yale.edu Fri Mar 10 10:41:02 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Fri Mar 10 10:41:09 2006 Subject: [gcs-pcs-list] demo: unapi+atom == copy/paste Message-ID: <20060310154101.GB18260@sildin.med.yale.edu> I worked up a demo screencast of copying out with unAPI and pasting with the Atom Publishing Protocol. Two great tastes that taste great together, imho. :) http://tinyurl.com/ehtdv There are several issues needing work before fully rolling this out in unalog, but it's much closer now. -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From yee at berkeley.edu Fri Mar 10 11:05:33 2006 From: yee at berkeley.edu (Raymond Yee) Date: Fri Mar 10 11:08:50 2006 Subject: [gcs-pcs-list] concerns about the heavy use of http response codes in unAPI Message-ID: <4411A3CD.2090502@berkeley.edu> Hi everyone, I've been pondering one thing that has nagged me about unAPI: the use of http response codes in unAPI. Even though the proposed usage seems to be very much in the spirit (and law) of the http protocol, it was nonetheless unfamiliar to me. I've spent a lot of time looking at various web services APIs and from what I could recall, they largely tended to shy away from heavy use of http response codes and largely reported status and errors in custom XML messages. To test my suspicions, I spent some time going through the 170+ APIs recorded at http://www.programmableweb.com/apis, looking for uses of http response codes. By looking at is recorded at the site, I see the following use of "HTTP response codes are explicitly used by this protocol. Note that this does not include 'ordinary' HTTP responses, such as a normal 404, with no API-specific meaning": blogger: 401, 204 blogmarks: 401, 404, 500 (with details in XML body) delicious: 503 hotornot: 401 MSN spaces: 400, 403 Plaxo: 205, 211, 400, 401, other 400 and 500 level codes Raw Sugar: 401, 404, 501, 503 (throttled) upcoming.org: 403, 404 Yahoo image search/local search/: 400, 403, 503 I also looked for sites that use XML-based error reporting. I've not compiled a nice list yet, but found at least the following: backpack in XML with error codes [http://www.backpackit.com/api/ Backpack API: Build your own apps on Backpack] blogmarks [http://dev.blogmarks.net/wiki/AtomApiSpec AtomApiSpec - Blogmarks.net - Trac]: "Server returning a 4xx or 5xx HTTP code means that an error occured while processing the request. If so, response body describes the error as XML." box.net [http://dev.box.net/api-documentation Box.net :: API Documentation] "Custom XML response" easyutil in XML http://www.easyutil.com/rec_api_ref.html EVDB in XML [http://api.evdb.com/docs/errors EVDB API - /events/new] feedburner error in XML e.g., [http://api.feedburner.com/awareness/1.0/GetFeedData?uri=burnthisRSS2x ] geocoder.ca error code in XML [http://geocoder.ca/?api=1 geocoder.ca: a free Canadian address geocoder] Flickr [http://www.flickr.com/services/api/response.rest.html Flickr Services] hotornot [http://dev.hotornot.com/wiki/ErrorCodes ErrorCodes - HOTorNOT Developer Site] 401 User is not authorized for this method onlywire in XML [http://www.onlywire.com/index?api OnlyWire: The Only BookMarklet You'll Ever Need!] openomy.com in XML [http://documentation.openomy.com/index.php/How_Web_Apps_Work#Failure How Web Apps Work - OpenomyDocumentation] pixagogo in XML [http://www.pixagogo.com/tools/api/apihelp.aspx?p=data#error Pixagogo - API Help Pixagogo] prodigem in XML [http://torrentocracy.com/mediawiki/index.php/Prodigem_API_REST_Errors Prodigem API REST Errors - TorrentocracyWiki] shadows just like delicious [http://www.shadows.com/features/site/help/api.htm Shadows - Tag, comment, and rate your favorite web pages.]: Errors are reported using standard HTTP error codes. simpy in XML [http://www.simpy.com/simpy/service/api/rest/Status.jsp Simpy Services: REST API : Status] syndic8 xml-rpc error codes What do I see: * there is some usage of http response codes * I think there is still greater usage of xml error codes. I think a lot about how Flickr works -- and it doesn't use http response codes to report status. Neither do a lot of web services. * Yahoo uses both It was later in the day that it occurred to me that maybe I've been seeing unAPI from a conceptual frame that is not that of unAPI: unAPI isn't really cast as an XML over HTTP web service protocol but a HTTP-centric protocol with happens to spit out XML on occassions. Also, after looking briefly at the Atom Publishing Protocol, which strikes me as avowedly RESTful and therefore heavily into using the ins and outs of http, I'm starting to understand the logic of the http response codes. I do wonder, however, whether this logic will be foreign to our target audience of developers though -- that's one concern I have. I learned a lot about http response codes the last few days because I wanted to understand unAPI. I suspect that there are a lot of people out there who don't know that much about http (even if they should to be a self-respecting web developer) and who won't invest the effort to learn to implement unAPI. Another concern I have is technical. Dan Chudnov wrote (http://cipolo.med.yale.edu/pipermail/gcs-pcs-list/2006-March/000499.html): Probably the biggest issue we agreed to track carefully is browser /language/framework support for 300 Multiple Choices response. In this iteration of the spec we'd like to be reasonably thorough in testing the pattern with a variety of popular tools to see how easily this response pattern can be implemented. So please block off a few hours in the next few weeks to try it out with your own favorite toolchain. I've not looked at a broad range of tools -- but I can say in Python's urllib2 library (the one an Mark Pilgrim identified as a good way to do http) will throw an HTTPError exception on receipt of the 300 code. According to http://diveintopython.org/http_web_services/etags.html: urllib2 also raises an HTTPError exception for conditions that you would think of as errors, such as 404 (page not found). In fact, it will raise HTTPError for any status code other than 200 (OK), 301 (permanent redirect), or 302 (temporary redirect). It would be more helpful for your purposes to capture the status code and simply return it, without throwing an exception. To do that, you'll need to define a custom URL handler. Not an insurmountable barrier by any means -- but something that might throw developers for a loop. This type of behavior might be similar to those in other libraries..... I'll end with other links that I found helpful: * [http://www.oreillynet.com/pub/wlg/4009 RESTful Error Handling] -- the article + the disagreeing comments * [http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html HTTP/1.1: Status Code Definitions] * http://cipolo.med.yale.edu/pipermail/gcs-pcs-list/2006-March/000499.html -- Eric Hellman's comment on 300 * [http://diveintomark.org/archives/2003/07/21/atom_aggregator_behavior_http_level Atom aggregator behavior (HTTP level) [dive into mark]] -- Mark Pilgrim on use of http codes in building an atom aggregator -Raymond -- -- Raymond Yee 2195 Hearst (250-22) Technology Architect UC Berkeley Interactive University Project Berkeley, CA 94720-3810 yee@uclink.berkeley.edu 510-642-0476 (work) http://iu.berkeley.edu/rdhyee 413-541-5683 (fax) -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3166 bytes Desc: S/MIME Cryptographic Signature Url : http://cipolo.med.yale.edu/pipermail/gcs-pcs-list/attachments/20060310/18028ef6/smime.bin From leigh at ldodds.com Fri Mar 10 15:27:55 2006 From: leigh at ldodds.com (Leigh Dodds) Date: Fri Mar 10 15:28:36 2006 Subject: [gcs-pcs-list] concerns about the heavy use of http response codes in unAPI In-Reply-To: <4411A3CD.2090502@berkeley.edu> References: <4411A3CD.2090502@berkeley.edu> Message-ID: <4411E14B.2060807@ldodds.com> Hi Raymond, > To test my suspicions, I spent some time going through the 170+ APIs > recorded at http://www.programmableweb.com/apis, looking for uses of > http response codes. Very thorough job! I looked at this and other aspects of protocol design in "social content services" in a paper I wrote last year: http://www.idealliance.org/proceedings/xtech05/papers/02-07-04/ See the sections entitled "use of status codes" for a similar breakdown of code usage, and some analysis of the various practices. The use of HTTP status codes and XML documents to indicate errors is not actually mutually exclusive. In fact they're orthogonal. Where an HTTP response can have a body, it's generally the case that APIs return XML in some format. E.g. an unAPI implementation might return an 500 error with an XML document containing a specific error message and possibly further details including an application specific error code. A lot of sites mimic Flickr which uses 200 almost exclusively. This is a Bad Idea. A key reason to use HTTP response codes is that web intermediaries (e.g. caching proxies) and other generic web clients (e.g. a browser or web crawler) will have some understanding of the semantics of the response: it's an error; it's a (permanent) redirect; everything worked fine. This is almost as important as correctly using HTTP request methods. The response codes licence in intermediaries to apply generic processing to API responses. E.g. caching the data. The ability to do this is a key aspect of the REST architecture and is an important aspect of enabling scaling of distributed systems to the level of the 'net. If an API returns a 200 OK response for all interactions then clients must understand the specific XML formats of that service in order to interpret the message. > It was later in the day that it occurred to me that maybe I've been > seeing unAPI from a conceptual frame that is not that of unAPI: unAPI > isn't really cast as an XML over HTTP web service protocol but a > HTTP-centric protocol with happens to spit out XML on occassions. Also, > after looking briefly at the Atom Publishing Protocol, which strikes me > as avowedly RESTful and therefore heavily into using the ins and outs of > http, I'm starting to understand the logic of the http response codes. I'm not sure I see the difference. An important thing to grok is that HTTP is an *application protocol*. It's not a transport protocol or something to be abstracted away. It has clear, generic semantics that apply to almost all applications: it worked; please try later; you need to authenticate; there was an error, etc. Understanding that this is the role that HTTP plays in web architecture means that you can design applications and APIs that get the most out of that architecture (e.g. caching, proxying). It also makes it easier to write generic client toolkits (e.g. browsers, curl, wget) that can usefully interact with services that properly integrate with HTTP. Consider the fact that most HTTP clients will helpfully follow 3XX redirects from a server and do a GET to retrieve the indicated resource. If you were serving responses as a 200, you'd have to define a custom message in your protocol in order to indicate when a client may have to consult some other resource, and all client developers would need to implement support for your bespoke mechanism. With HTTP some things come for "free". > I do wonder, however, whether this logic will be foreign to our target > audience of developers though -- that's one concern I have. I learned a > lot about http response codes the last few days because I wanted to > understand unAPI. I suspect that there are a lot of people out there > who don't know that much about http (even if they should to be a > self-respecting web developer) and who won't invest the effort to learn > to implement unAPI. I think what we're seeing in the move to simpler, RESTful protocols and a rejection of SOAP and WS-* services is that these add unnecessarily complex layers on top of HTTP. So I agree that there's a slightly different mindset, but I think the requisite shift is already underway and that developers are climbing the learning curve of how to get the most of out existing web architecture. > Another concern I have is technical. Dan Chudnov wrote > (http://cipolo.med.yale.edu/pipermail/gcs-pcs-list/2006-March/000499.html): > > Probably the biggest issue we agreed to track carefully is browser > /language/framework support for 300 Multiple Choices response. One for a separate thread. I wanted to raise this as an issue also, as I think in this case a 200 response is more suitable. (I'd also like to see the response include explicit links to the alternate format documents, but will raise that separately also). Cheers, L. -- From leigh at ldodds.com Fri Mar 10 15:48:04 2006 From: leigh at ldodds.com (Leigh Dodds) Date: Fri Mar 10 15:48:39 2006 Subject: [gcs-pcs-list] Anchors in Spec Message-ID: <4411E604.2070903@ldodds.com> Hi, Any chance we can get anchors added to the spec for each of the major section headings? Cheers, L. -- Home: http://www.ldodds.com | "Simplicity is the ultimate Blog: http://www.ldodds.com/blog | sophistication" -- Leonardo da Vinci From leigh at ldodds.com Fri Mar 10 16:04:07 2006 From: leigh at ldodds.com (Leigh Dodds) Date: Fri Mar 10 16:04:44 2006 Subject: [gcs-pcs-list] Links in metadata formats document Message-ID: <4411E9C7.10603@ldodds.com> Hi, The current spec includes an example of a response listing available metadata formats, similar to the following: info:sid/example.com/12345 oai_dc application/xml http://www.openarchives.org/OAI/2.0/oai_dc/ http://www.openarchives.org/OAI/2.0/oai_dc.xsd This document is basically an index document that lists all formats available for a given URI. The client can then construct ?format=FORMAT calls using one of the named formats. I'd like to suggest that the format include a link to the relevant API call also, e.g: oai_dc application/xml http://www.openarchives.org/OAI/2.0/oai_dc/ http://www.openarchives.org/OAI/2.0/oai_dc.xsd http://www.example.org/unapi?uri=info:sid/example.com/12345&format=oai_dc The name then becomes just a useful label, e.g. for display to a user. A client application need only select the appropriate link value for a subsequent GET request. In some cases it'll also remove the need for a further interaction with the unAPI implementation: if the server was going to redirect the ?format=oai_dc request, then this alternate location can instead be directly indicated in the response document and the client can GET it directly. Where the response document include links (i.e. the two from the original example, plus my proposal) it might be useful to consider use of XLink, see: http://www.w3.org/TR/webarch/#xml-links (the following section recommending use of namespaces is also relevant) Cheers, L. -- Home: http://www.ldodds.com | "Simplicity is the ultimate Blog: http://www.ldodds.com/blog | sophistication" -- Leonardo da Vinci From daniel.chudnov at yale.edu Fri Mar 10 16:28:04 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Fri Mar 10 16:28:06 2006 Subject: [gcs-pcs-list] Anchors in Spec In-Reply-To: <4411E604.2070903@ldodds.com> References: <4411E604.2070903@ldodds.com> Message-ID: <20060310212803.GL18260@sildin.med.yale.edu> Leigh Dodds wrote, on Fri, Mar 10, 2006 at 08:48:04PM +0000: > > Any chance we can get anchors added to the spec for each of the > major section headings? A goal of this process is to produce a spec that fits on one page. In such a spec, we wouldn't need intra-doc links. In a way, then, if we need anchors, we've failed. Separately, the writeboard feature within basecamp that i've been using to edit the spec wasn't designed for writing specs. I knew that going in, but due to the point in the previous paragraph, I thought it would be okay. So, um, to sum: I hear you. I'll make sure the specs that go up to unapi.info are increasingly usable. (But the spec's still too long. :) -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From eric at openly.com Fri Mar 10 16:22:11 2006 From: eric at openly.com (Eric Hellman) Date: Fri Mar 10 16:49:06 2006 Subject: [gcs-pcs-list] Links in metadata formats document In-Reply-To: <4411E9C7.10603@ldodds.com> References: <4411E9C7.10603@ldodds.com> Message-ID: I was going to ask for the same thing. ++ At 9:04 PM +0000 3/10/06, Leigh Dodds wrote: >Hi, > >The current spec includes an example of a response listing >available metadata formats, similar to the following: > > >info:sid/example.com/12345 > >oai_dc >application/xml >http://www.openarchives.org/OAI/2.0/oai_dc/ >http://www.openarchives.org/OAI/2.0/oai_dc.xsd > > > >This document is basically an index document that lists all >formats available for a given URI. The client can then construct >?format=FORMAT calls using one of the named formats. > >I'd like to suggest that the format include a link to the relevant >API call also, e.g: > > >oai_dc >application/xml >http://www.openarchives.org/OAI/2.0/oai_dc/ >http://www.openarchives.org/OAI/2.0/oai_dc.xsd >http://www.example.org/unapi?uri=info:sid/example.com/12345&format=oai_dc > > >The name then becomes just a useful label, e.g. for display to a user. A >client application need only select the appropriate link value for a >subsequent GET request. > >In some cases it'll also remove the need for a further interaction >with the unAPI implementation: if the server was going to redirect the >?format=oai_dc request, then this alternate location can instead be >directly indicated in the response document and the client can >GET it directly. > >Where the response document include links (i.e. the two from >the original example, plus my proposal) it might be useful to >consider use of XLink, see: > >http://www.w3.org/TR/webarch/#xml-links > >(the following section recommending use of namespaces is also >relevant) > >Cheers, > >L. > >-- >Home: http://www.ldodds.com | "Simplicity is the ultimate >Blog: http://www.ldodds.com/blog | sophistication" -- Leonardo da Vinci >_______________________________________________ >gcs-pcs-list mailing list >gcs-pcs-list@cipolo.med.yale.edu >http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list From eric at openly.com Fri Mar 10 16:53:13 2006 From: eric at openly.com (Eric Hellman) Date: Fri Mar 10 16:57:05 2006 Subject: [gcs-pcs-list] Anchors in Spec In-Reply-To: <20060310212803.GL18260@sildin.med.yale.edu> References: <4411E604.2070903@ldodds.com> <20060310212803.GL18260@sildin.med.yale.edu> Message-ID: Even my 12 year old knows that adjusting font size is the solution to all target-length issues! At 4:28 PM -0500 3/10/06, Daniel Chudnov wrote: >Leigh Dodds wrote, on Fri, Mar 10, 2006 at 08:48:04PM +0000: >> >> Any chance we can get anchors added to the spec for each of the >> major section headings? > >A goal of this process is to produce a spec that fits on one page. >In such a spec, we wouldn't need intra-doc links. In a way, then, >if we need anchors, we've failed. > >Separately, the writeboard feature within basecamp that i've been using >to edit the spec wasn't designed for writing specs. I knew that going >in, but due to the point in the previous paragraph, I thought it would >be okay. > >So, um, to sum: I hear you. I'll make sure the specs that go up to >unapi.info are increasingly usable. > >(But the spec's still too long. :) > > -Dan -- Eric Hellman, Director OCLC Openly Informatics Division eric@openly.com 2 Broad St., Suite 208 tel 1-973-509-7800 fax 1-734-468-6216 Bloomfield, NJ 07003 http://www.openly.com/1cate/ 1 Click Access To Everything From daniel.chudnov at yale.edu Fri Mar 10 16:57:06 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Fri Mar 10 16:57:10 2006 Subject: [gcs-pcs-list] Links in metadata formats document In-Reply-To: <4411E9C7.10603@ldodds.com> References: <4411E9C7.10603@ldodds.com> Message-ID: <20060310215705.GM18260@sildin.med.yale.edu> Leigh Dodds wrote, on Fri, Mar 10, 2006 at 09:04:07PM +0000: > > This document is basically an index document that lists all > formats available for a given URI. The client can then construct > ?format=FORMAT calls using one of the named formats. > > I'd like to suggest that the format include a link to the relevant API > call also, e.g: ... > > The name then becomes just a useful label, e.g. for display to a user. A > client application need only select the appropriate link value for a > subsequent GET request. We have considered this before; the name already is a useful label for display to a user, and an appropriate param value. How does this suggestion change that? > In some cases it'll also remove the need for a further interaction > with the unAPI implementation: if the server was going to redirect the > ?format=oai_dc request, then this alternate location can instead be > directly indicated in the response document and the client can > GET it directly. I struggled with this some while writing OPA: should, e.g., the flickr image formats simply be direct responses out of OPA (the unAPI server in this instance, proxy or no) wherein they fetch the image remotely and *then* send it back out directly within its response? Or should it redirect? Or should it just set Location: and be done? Etc. There was consensus that redirects were best, and that the unAPI service should itself remain the front-line request target for unAPI requests. Back to your point, then, there's a risk here of disassociating the format for which the unAPI service advertises available for an object from the ability of the service to retrieve that object. The use case I have in mind is the eventual Atom-pasting of json-wrapped data from unAPI services which I demoed in the screencast I posted earlier. There's a fundamental problem with that, in that I want to be able to show user Foo the nice image that user Bar pasted in earlier, but as a service provider I cannot safely assume that Bar has the right to repost the image. A safe stance, then, is to allow Bar to get all the data Bar herself pasted back out later, and even see it inline, but not to do the same for Foo. Instead, for Foo, I can indicate that Bar posted an image, and I can provide links for Foo back to where Bar got the image. I'd do this by re-using the unAPI links and format names from which the data came in the first place. If unAPI implementers were *not* in the habit of actually fully developing the ability to answer UNAPI?uri=URI&format=FORMAT requests (even if they just redirect), then there might not be a way for me to re-associate Foo or other unalog users with the unAPI-source from which Bar originally got the data. I could point Foo to the redirected link (say, the flickr url) but then that loses the unAPI-source info. If I know the request came from the unAPI service, I can re-compose the UNAPI?uri=URI&format=FORMAT url for Foo, and Foo can either get it or not depending on access rights at the unAPI-source. Of course, I haven't done all this yet, this is just how I think I'm going to do it. There's also a whole wedge in the middle for third-party extensions (like the oh-so-many you see for del.icio.us) to assemble, route, package, reassemble, reroute, and repackage the data before sending over to my own service which I'm not addressing here. Maybe I'm over-thinking it all, but I'm trying to imagine a world wherein copying and pasting across webapps and desktop apps happens so commonly that objects could get copied-and-pasted so many times there's no clear way of being sure who got it where first. In that world, which is demonstrably nigh upon us, if a lot of unAPI servers didn't answer their own unAPI queries, I think we'd be worse off. > Where the response document include links (i.e. the two from > the original example, plus my proposal) it might be useful to > consider use of XLink, see: I've already had my arm repeatedly twisted prior to accepting XML as the output format. :) I'm loathe grow the XML response format into anything more than a namespaceless and schemaless handful of elements countable on one hand. We'd need a clearly broken scenario demonstrated by code to go any further with the response format part of the spec. -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From daniel.chudnov at yale.edu Fri Mar 10 17:06:57 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Fri Mar 10 17:06:58 2006 Subject: [gcs-pcs-list] new issue: who's the author? Message-ID: <20060310220657.GN18260@sildin.med.yale.edu> Eric raised a question of listing author info in the spec. I'm not sure what to do about that. My gut response is to list all the contributors, which is, everybody who's participated actively in moving the spec forward from day one on. We can generate this list objectively from the list archive. As of yet this list also includes everybody who's implemented the spec, I think, although I don't know if that set will remain a proper subset of the full list of contributors easily parsed from the list archives, so I'd tend to not set that as an entry-condition. I would list all names alphabetically by last name. Each person listed could optionally provide a single email address and an institution name. Anyone not wanting their name on the list would need to inform me. What say? -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From daniel.chudnov at yale.edu Fri Mar 10 17:09:37 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Fri Mar 10 17:09:39 2006 Subject: [gcs-pcs-list] new issue: switch from info-URI examples Message-ID: <20060310220937.GO18260@sildin.med.yale.edu> Eric suggested switching some of the info URI examples to something more people outside of our community would recognize. This is a good idea, and I'd probably go for at least one ordinary HTTP URL and maybe a urn:isbn:123456789X. This seems so obvious I doubt anyone would object, so please speak up soon if you do object. -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From mrylander at gmail.com Fri Mar 10 17:11:12 2006 From: mrylander at gmail.com (Mike Rylander) Date: Fri Mar 10 17:12:15 2006 Subject: [gcs-pcs-list] new issue: who's the author? In-Reply-To: <20060310220657.GN18260@sildin.med.yale.edu> References: <20060310220657.GN18260@sildin.med.yale.edu> Message-ID: +1 On 3/10/06, Daniel Chudnov wrote: > Eric raised a question of listing author info in the spec. I'm not > sure what to do about that. > > My gut response is to list all the contributors, which is, everybody > who's participated actively in moving the spec forward from day one on. > We can generate this list objectively from the list archive. As of yet > this list also includes everybody who's implemented the spec, I think, > although I don't know if that set will remain a proper subset of the > full list of contributors easily parsed from the list archives, so I'd > tend to not set that as an entry-condition. > > I would list all names alphabetically by last name. Each person listed > could optionally provide a single email address and an institution name. > Anyone not wanting their name on the list would need to inform me. > > What say? > > -Dan > > > -- > Daniel Chudnov > Yale Center for Medical Informatics > (203) 737-5789 > _______________________________________________ > gcs-pcs-list mailing list > gcs-pcs-list@cipolo.med.yale.edu > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list > -- Mike Rylander mrylander@gmail.com GPLS -- PINES Development Database Developer http://open-ils.org From daniel.chudnov at yale.edu Fri Mar 10 18:18:37 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Fri Mar 10 18:18:38 2006 Subject: [gcs-pcs-list] next next issue: Location header? In-Reply-To: References: <20060308193854.GA11171@sildin.med.yale.edu> <440F4239.5010707@ldodds.com> Message-ID: <20060310231837.GR18260@sildin.med.yale.edu> I'm above-the-copy interjecting here because this seems to be a real sticking point. We had very clearly positive vote to move *all* status code mentions *out* of the spec itself, and to instead include a list of recommended codes. Add to that this particular discussion (which seems to lead, following that vote's spirit, to the result of "add 302 Found as a recommended but non-normative status code for redirected responses from UNAPI?uri=URI&format=FORMAT requests") and the insightful comments from Raymond and Leigh and we have a pickle of a quandry. To describe this broadly, I think we're in good shape... what we're looking for is a very fine balance between Doing Things Right and Encouraging Worldwide Adoption. We've narrowed our oscillations down into a pretty narrow band somewhere between the two extremes (if mandating every codes is one extreme and setting 200 Ok for everything is the other). In other words, we're close to a hunch of a consensus, but we're not there yet. I suspect that we could go back and forth over this (much like the identifier discussion, which we will go back over at least once!), but we don't want to get stuck right now. So, I propose that what we need is to pick a position for rev2, which is due next week, and do a lot of implementing and testing. I don't mean to understate the value of the wisdom and honed-by-experience opinions of everyone involved here, but we really need to push on the implementation side of things if we're going to arrive at that fine line sooner rather than later. It was really interesting to implement OPA... I had to deal with the redirection issue, among others. Adding unAPI to the canary database gave me a chance to fiddle with wrapping unapi-format anchor links inside unapi-uri spans (and, it works!). Doing the unalog Atom paste thing and screencast brought some other issues in more focus. Jeff brought up the OpenURL similarity issues which (although we're not really discussing that anymore :) were very informative... the Open-ILS discussion of identifiers This isn't to say that I know the answers now... but just that maybe it's time to stop fiddling and get back to coding some more. I need some more time to finish up the unalog/atom implementation, for example. (And set up a news feed at unapi.info. And work on the FAQ. And edit the spec. :) What if we: - go along with the overwhelming vote to remove all status code mentions to the non-normative "recommendataion" section; - add 302 Found there as a note for UNAPI?uri=URI&format=FORMAT redirects - stop there on these issues for rev2 It seems likely that the combination of many more implementations and a fun-to-use testing script will drive these issues home much further for all of us. What say? Good enough for rev2? (remembering, of course, that there will be a rev3 in another month, and then a "ballot spec for version 1" a month after that...) -Dan Xiaoming Liu wrote, on Wed, Mar 08, 2006 at 11:40:37PM -0700: > On Wed, 8 Mar 2006, Leigh Dodds wrote: > > >> "Should we specify anything about server having the option of adding > >> a Location header to URI+FORMAT response?" > >> > >>...or, for the sake of conversation: s/URI+FORMAT/any unAPI/ > >> > >>I think the one common thing we found earlier about having a Location > >>header is that when it's there, with the most commonly used 3xx > >>responses, most common clients (IE, FX, Safari, wget) just go straight > >>to the Location header value. > > > >I'd hazard that the common use case for needing a Location header, i.e. > >communicating to the client that a there's data "over there" is handled > >by one of the HTTP redirect statuses. 302 Found seems the best fit for > >this use case (leaving 301/307 for redirects relating to the unAPI > >impl itself: "we've moved, please go here in future") > > Myself will vote to "specify nothing", besides keeping things simple, > I also think this is eventually an implementor's choice (remember we have > some 10+ opinions about what "go" means). Although this can be a good > topic for FAQ. -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From daniel.chudnov at yale.edu Mon Mar 13 01:17:40 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Mon Mar 13 01:18:49 2006 Subject: [gcs-pcs-list] unAPI faq first draft Message-ID: <8BC6F3D5-5F1C-4B1A-B86B-03023F2D5BAE@yale.edu> A first cut at a FAQ list is here: http://curtis.med.yale.edu/dchud/unapi/faq-2.html http://curtis.med.yale.edu/dchud/unapi/faq-2.txt Please send additions, corrections, etc. Thanks, -Dan From ehs at pobox.com Tue Mar 14 01:39:37 2006 From: ehs at pobox.com (Edward Summers) Date: Tue Mar 14 01:40:16 2006 Subject: [gcs-pcs-list] unapi validator Message-ID: <4FA12C4F-221C-41DC-AB46-DD9504C650A6@pobox.com> I've got the start of a unapi validator along the lines of what dan described in an earlier email. It's not very fancy at the moment, but you can find it here: http://validator.unapi.info Thanks to dan for staying up late to get this installed on unapi.info properly. The service is essentially a minimal rails app that uses a simple ruby client library [1] which you can get as a ruby gem: gem install unapi This is a work in progress, so I'm open to suggestions on how to improve the validator and/or the client library. //Ed [1] http://www.textualize.com/unapi From daniel.chudnov at yale.edu Tue Mar 14 08:51:02 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Tue Mar 14 08:51:06 2006 Subject: [gcs-pcs-list] unapi validator In-Reply-To: <4FA12C4F-221C-41DC-AB46-DD9504C650A6@pobox.com> References: <4FA12C4F-221C-41DC-AB46-DD9504C650A6@pobox.com> Message-ID: <20060314135102.GA16018@sildin.med.yale.edu> Edward Summers wrote, on Tue, Mar 14, 2006 at 12:39:37AM -0600: > I've got the start of a unapi validator along the lines of what dan > described in an earlier email. It's not very fancy at the moment, but > you can find it here: This is awesome, Ed. And, it's going to make a huge difference to have an easy way to tell implementors "you're right, and you're done." Thanks! -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From ross.singer at library.gatech.edu Tue Mar 14 09:33:31 2006 From: ross.singer at library.gatech.edu (Ross Singer) Date: Tue Mar 14 09:35:32 2006 Subject: [gcs-pcs-list] unapi validator In-Reply-To: <20060314135102.GA16018@sildin.med.yale.edu> References: <4FA12C4F-221C-41DC-AB46-DD9504C650A6@pobox.com> <20060314135102.GA16018@sildin.med.yale.edu> Message-ID: <23b83f160603140633v711aca59yedfb78fe34f144c6@mail.gmail.com> On 3/14/06, Daniel Chudnov wrote: > This is awesome, Ed. And, it's going to make a huge difference to have > an easy way to tell implementors "you're right, and you're done." "Until next month, when the next revision is due." ;) -Ross. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://cipolo.med.yale.edu/pipermail/gcs-pcs-list/attachments/20060314/447f8705/attachment.htm From liu_x at lanl.gov Tue Mar 14 11:08:07 2006 From: liu_x at lanl.gov (Xiaoming Liu) Date: Tue Mar 14 11:07:11 2006 Subject: [gcs-pcs-list] unapi validator In-Reply-To: <4FA12C4F-221C-41DC-AB46-DD9504C650A6@pobox.com> References: <4FA12C4F-221C-41DC-AB46-DD9504C650A6@pobox.com> Message-ID: This looks cool, maybe I am thinking ahead, but for next version of protocol maybe three levels of message are useful: pass, warning, error. warning can be used for problems not compliant with best-practices. xiaoming On Tue, 14 Mar 2006, Edward Summers wrote: > I've got the start of a unapi validator along the lines of what dan > described in an earlier email. It's not very fancy at the moment, but you > can find it here: > > http://validator.unapi.info > > Thanks to dan for staying up late to get this installed on unapi.info > properly. The service is essentially a minimal rails app that uses a > simple ruby client library [1] which you can get as a ruby gem: > gem install unapi > > This is a work in progress, so I'm open to suggestions on how to improve > the validator and/or the client library. > > //Ed > > [1] http://www.textualize.com/unapi > _______________________________________________ > gcs-pcs-list mailing list > gcs-pcs-list@cipolo.med.yale.edu > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list From ehs at pobox.com Tue Mar 14 11:27:26 2006 From: ehs at pobox.com (Ed Summers) Date: Tue Mar 14 11:28:28 2006 Subject: [gcs-pcs-list] unapi validator In-Reply-To: References: <4FA12C4F-221C-41DC-AB46-DD9504C650A6@pobox.com> Message-ID: On 3/14/06, Xiaoming Liu wrote: > This looks cool, maybe I am thinking ahead, but for next version of > protocol maybe three levels of message are useful: pass, warning, error. > warning can be used for problems not compliant with best-practices. Yes, I like that idea a lot. I'll take a look at adding that and making the HTTP Status Codes a warning level error :-) //Ed From yee at berkeley.edu Tue Mar 14 12:17:07 2006 From: yee at berkeley.edu (Raymond Yee) Date: Tue Mar 14 12:20:23 2006 Subject: [gcs-pcs-list] concerns about the heavy use of http response codes in unAPI In-Reply-To: <4411E14B.2060807@ldodds.com> References: <4411A3CD.2090502@berkeley.edu> <4411E14B.2060807@ldodds.com> Message-ID: <4416FA93.8080303@berkeley.edu> Hi Leigh, Hey, thanks for responding. Leigh Dodds wrote: > Hi Raymond, > >> To test my suspicions, I spent some time going through the 170+ APIs >> recorded at http://www.programmableweb.com/apis, looking for uses of >> http response codes. > > Very thorough job! I looked at this and other aspects of protocol design > in "social content services" in a paper I wrote last year: > > http://www.idealliance.org/proceedings/xtech05/papers/02-07-04/ > > See the sections entitled "use of status codes" for a similar breakdown > of code usage, and some analysis of the various practices. I see that you did a similar analysis to me-- one that is more in depth and focused on some particular apps. It's nice to know that we're thinking similarly about this topic. Thanks also for the reference to your article. I enjoyed reading it a lot and found it very helpful. I've since assigned it to my class on information remix and will be discussing it in class tomorrow. > > The use of HTTP status codes and XML documents to indicate errors is > not actually mutually exclusive. In fact they're orthogonal. Where an > HTTP response can have a body, it's generally the case that APIs return > XML in some format. Yes, you're certainly right that the use of HTTP status codes and XML documents are not mutually exclusive. I didn't mean to imply that. I don't believe that they are orthogonal though -- in the sense that there is not some practical interdependence. For instance, when I use Flickr's API, I've been trained to expect error handling to do done only at the XML "layer" and not to get error codes from the http response codes -- unless the transport of the XML is badly amiss. This expectation comes from not thinking of http as an *application protocol* as you point out below -- but more as a *transport layer*. > > E.g. an unAPI implementation might return an 500 error with an XML > document containing a specific error message and possibly further > details including an application specific error code. > > A lot of sites mimic Flickr which uses 200 almost exclusively. This is > a Bad Idea. A key reason to use HTTP response codes is that web > intermediaries (e.g. caching proxies) and other generic web clients > (e.g. a browser or web crawler) will have some understanding of the > semantics of the response: it's an error; it's a (permanent) redirect; > everything worked fine. This is almost as important as correctly > using HTTP request methods. It's too bad that a lot of sites mimic Flickr's "design pattern". We just need to be aware that there needs to be some sort of unlearning involved for developers who learn by studying things like Flickr.....(and I include myself in that camp!) > > I think what we're seeing in the move to simpler, RESTful protocols > and a rejection of SOAP and WS-* services is that these add unnecessarily > complex layers on top of HTTP. > > So I agree that there's a slightly different mindset, but I think the > requisite shift is already underway and that developers are climbing > the learning curve of how to get the most of out existing web > architecture. On this point, I've been reading Jon Udell: * http://www.infoworld.com/article/05/09/12/37FEsoaevolve_1.html * http://www.infoworld.com/article/06/01/11/73703_03OPstrategic_1.html * http://www.infoworld.com/article/06/03/08/76065_11OPstrategic_1.html Though I really appreciate the elegance and simplicity of REST, I do think that there is a role for SOAP and the whole WS-* stack. Not so much in my work -- but in a lot of enterprise application. Even for things like Flickr, I'd love for some type of WSDL-equivalent for REST -- where I could just feed a wsdl file to my client and be able to wire Flickr into my application w/o having to read the spec and do a lot more manual integration. It's interesting that Flickr has introspection methods: .e.g, http://www.flickr.com/services/api/flickr.reflection.getMethods.html Makes one wonder whether one could cook up some WSDL-equiv for Flickr here. -Raymond -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3166 bytes Desc: S/MIME Cryptographic Signature Url : http://cipolo.med.yale.edu/pipermail/gcs-pcs-list/attachments/20060314/0e058ddb/smime.bin From ehs at pobox.com Tue Mar 14 21:59:32 2006 From: ehs at pobox.com (Edward Summers) Date: Tue Mar 14 22:00:08 2006 Subject: [gcs-pcs-list] COinS and the live clipboard In-Reply-To: References: Message-ID: <232BDDEF-1C93-4413-BA35-6395CD83501F@pobox.com> On Mar 9, 2006, at 1:31 PM, Young,Jeff (OR) wrote: > These formats aren't currently registered, but they could be. OCLC has > applied to become the OpenURL Registry maintenance agency, and once > that > happens officially I expect to open it up for contributions as soon > as I > can. Are we talking about registering microformats for openurl? Can you provide any insight into how this registry would operate and be used in the wild? Or is this stuff still being worked out? //Ed From jyoung at oclc.org Wed Mar 15 10:37:09 2006 From: jyoung at oclc.org (Young,Jeff (OR)) Date: Wed Mar 15 10:38:08 2006 Subject: [gcs-pcs-list] COinS and the live clipboard Message-ID: I haven't been able to keep up with events here (what else is new?) so I appreciate the availability of the FAQ. Sorry if I step out of line on things that aren't covered there. This thread appears to explore the intersection of unAPI, Live Clipboard, and OpenURL, so I assume further discussion isn't out of line in this forum. As an aside, I continue to think there is a relationship between unAPI and OpenURL, but the solution I now envision is that developers who need interoperability between the two should be able to use "hybrid OpenURLs" to span both worlds (analogous to Appendix A.2 of http://alcme.oclc.org/openurl/docs/implementation_guidelines/KEV_Guideli nes-20041209.pdf). Last I heard, non-unAPI parameters "should" not "must" return code 400 Bad Request, so this solution isn't totally out of the question. Given that concession, the hybrid solution should have no impact on the unAPI spec, which can ignore the issue completely. The trick for using microformats with OpenURL will be to identify the serializations (currently Key/Encoded Values (KEV) or XML) and constraint languages (currently Matrix (MTX) or XSD) that can be used to represent them. If these existing options aren't adequate, then new serializations and constraint languages can be registered that are suitable. Once that happens, microformats can be added to the registry like any other metadata format. This should allow for some interesting interactions between OpenURL and Live Clipboard. As for how the registry will operate, it should have the same basic look and feel it has now, except there will be an option to create/edit entries. I assume there will be a vetting process, however, so things don't get out of hand. OTOH, I also want to allow people to use the registry to create local Community Profiles (applications) without the fuss of registering individual components. This will limit the interoperability of the profile, but I can imagine instances where this isn't important. Jeff > -----Original Message----- > From: gcs-pcs-list-bounces@cipolo.med.yale.edu [mailto:gcs-pcs-list- > bounces@cipolo.med.yale.edu] On Behalf Of Edward Summers > Sent: Tuesday, March 14, 2006 10:00 PM > To: gcs-pcs-list list > Subject: Re: [gcs-pcs-list] COinS and the live clipboard > > > On Mar 9, 2006, at 1:31 PM, Young,Jeff (OR) wrote: > > These formats aren't currently registered, but they could be. OCLC has > > applied to become the OpenURL Registry maintenance agency, and once > > that > > happens officially I expect to open it up for contributions as soon > > as I > > can. > > Are we talking about registering microformats for openurl? Can you > provide any insight into how this registry would operate and be used > in the wild? Or is this stuff still being worked out? > > //Ed > _______________________________________________ > gcs-pcs-list mailing list > gcs-pcs-list@cipolo.med.yale.edu > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list From daniel.chudnov at yale.edu Wed Mar 15 11:59:28 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Wed Mar 15 12:00:34 2006 Subject: [gcs-pcs-list] unapi.info downtime now Message-ID: <54022A6B-F7EB-4870-A149-37DD98977D95@yale.edu> I'm bringing unapi.info down temporarily to bring up a new backend for it. Hopefully it won't take long. -Dan From daniel.chudnov at yale.edu Wed Mar 15 17:30:33 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Wed Mar 15 17:31:39 2006 Subject: [gcs-pcs-list] unAPI news site. Message-ID: <1DC43C86-7D7E-4F04-8EF3-AF1AE9D10D81@yale.edu> http://unapi.info/news/ is up and running. Sorry for the downtime earlier. -Dan From daniel.chudnov at yale.edu Wed Mar 15 19:12:36 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Wed Mar 15 19:13:42 2006 Subject: [gcs-pcs-list] unAPI line item votes Message-ID: <36A80A3B-28A8-4558-9A52-2ABD619AA57E@yale.edu> I'm sorry to have been aloofish the past few days, there's a lot going on over here and in the middle of it it's taken longer than I expected to get the site at unapi.info up and going. Major points to Ed Summers for making the validator happen (and Ross for the new validator bookmarklet!) and for helping me to debug a failed tool install today. If you haven't noticed it, unAPI is starting to make the rounds some among the blogerati, so it seemed worthwhile to drop things for a few days to get the "public face" of unAPI up to speed. Tomorrow's supposed to be the release date for revision 2. There are still a lot of open issues. Several of them are quite small, though. To churn through some quickly, review the list below and vote inline after each proposed change with a +1/0/-1. Anything with sufficient + votes will get changed; sufficient - votes will be voted down, insufficient votes one way or the other will be dropped or promoted to a full thread as responses warrant. I will word most of the proposed resolutions as active changes to the spec, so if you don't want to see the change, vote it down. -Dan Issue: Should we specify anything about the server having the option of adding a Location header to URI+FORMAT response? Proposed change: No, but add a mention of it along with the 302 Found status code in the non-normative "recommended status codes" section. Issue: Should the root node of the formats response be "unapi" instead of "formats"? Proposed change: Yes, as it's more specific. Issue: Should we add a colophon explaining how the spec is being developed? Proposed change: No, but put it in the FAQ. Issue: Should uri-not-found or invalid-format responses return a formats list with the uri and no formats? Proposed change: Yes, because this way at least developers will see a predictable and "correct" unAPI response; otherwise, if we specify nothing, implementors can do anything, which will make it harder to code against implemented unAPI services. Issue: "URIs in unAPI HTTP calls must be url-encoded" is ambiguous Proposed change: Yes, it is. Remove this phrase. From lists at hubmed.org Wed Mar 15 19:26:31 2006 From: lists at hubmed.org (Alf Eaton) Date: Wed Mar 15 19:29:48 2006 Subject: [gcs-pcs-list] unAPI line item votes In-Reply-To: <36A80A3B-28A8-4558-9A52-2ABD619AA57E@yale.edu> References: <36A80A3B-28A8-4558-9A52-2ABD619AA57E@yale.edu> Message-ID: <77C28AA0-0E23-4366-8D41-5F3AD68088CC@hubmed.org> On 15 Mar 2006, at 19:12, Daniel Chudnov wrote: > > > Issue: Should we specify anything about the server having the > option of adding a Location header to URI+FORMAT response? > > Proposed change: No, but add a mention of it along with the 302 > Found status code in the non-normative "recommended status codes" > section. +1 I don't see that having a Location header would be helpful. > Issue: Should the root node of the formats response be "unapi" > instead of "formats"? > > Proposed change: Yes, as it's more specific. +1 But keep the formats node inside the unapi node. > Issue: Should we add a colophon explaining how the spec is being > developed? > > Proposed change: No, but put it in the FAQ. 0 Either's good. > Issue: Should uri-not-found or invalid-format responses return a > formats list with the uri and no formats? > > Proposed change: Yes, because this way at least developers will > see a predictable and "correct" unAPI response; otherwise, if we > specify nothing, implementors can do anything, which will make it > harder to code against implemented unAPI services. 0 Wouldn't it be better if uri-not-found returned the URI (with 404), but invalid-format returned the URI and a list of formats (with 300 perhaps)? > Issue: "URIs in unAPI HTTP calls must be url-encoded" is ambiguous > > Proposed change: Yes, it is. Remove this phrase. -1 They do need to be URL-encoded, don't they? alf. From eric at openly.com Wed Mar 15 22:19:56 2006 From: eric at openly.com (Eric Hellman) Date: Wed Mar 15 22:23:52 2006 Subject: [gcs-pcs-list] unAPI line item votes In-Reply-To: <36A80A3B-28A8-4558-9A52-2ABD619AA57E@yale.edu> References: <36A80A3B-28A8-4558-9A52-2ABD619AA57E@yale.edu> Message-ID: At 7:12 PM -0500 3/15/06, Daniel Chudnov wrote: >Issue: "URIs in unAPI HTTP calls must be url-encoded" is ambiguous > >Proposed change: Yes, it is. Remove this phrase. better to replace with an example, with a URI containing a "?" , an "=", or an "&" -- Eric Hellman, Director OCLC Openly Informatics Division eric@openly.com 2 Broad St., Suite 208 tel 1-973-509-7800 fax 1-734-468-6216 Bloomfield, NJ 07003 http://www.openly.com/1cate/ 1 Click Access To Everything From ehs at pobox.com Wed Mar 15 22:23:22 2006 From: ehs at pobox.com (Edward Summers) Date: Wed Mar 15 22:23:57 2006 Subject: [gcs-pcs-list] unAPI line item votes In-Reply-To: <36A80A3B-28A8-4558-9A52-2ABD619AA57E@yale.edu> References: <36A80A3B-28A8-4558-9A52-2ABD619AA57E@yale.edu> Message-ID: On Mar 15, 2006, at 6:12 PM, Daniel Chudnov wrote: > Issue: Should we specify anything about the server having the > option of adding a Location header to URI+FORMAT response? > > Proposed change: No, but add a mention of it along with the 302 > Found status code in the non-normative "recommended status codes" > section. -1 while this is useful during paste in APP it doesn't seem useful to me in unapi as it stands now, and could add to http status code confusion--should clients follow, etc... > Issue: Should the root node of the formats response be "unapi" > instead of "formats"? > > Proposed change: Yes, as it's more specific. +1 especially if the 2nd to last change happens, having a unapi envelope for responses would be nice > Issue: Should we add a colophon explaining how the spec is being > developed? > > Proposed change: No, but put it in the FAQ. +1 > Issue: Should uri-not-found or invalid-format responses return a > formats list with the uri and no formats? > > Proposed change: Yes, because this way at least developers will > see a predictable and "correct" unAPI response; otherwise, if we > specify nothing, implementors can do anything, which will make it > harder to code against implemented unAPI services. +1 > Issue: "URIs in unAPI HTTP calls must be url-encoded" is ambiguous > > Proposed change: Yes, it is. Remove this phrase. -1 i'm with alf on this //Ed From mrylander at gmail.com Wed Mar 15 22:32:10 2006 From: mrylander at gmail.com (Mike Rylander) Date: Wed Mar 15 22:33:13 2006 Subject: [gcs-pcs-list] unAPI line item votes In-Reply-To: <36A80A3B-28A8-4558-9A52-2ABD619AA57E@yale.edu> References: <36A80A3B-28A8-4558-9A52-2ABD619AA57E@yale.edu> Message-ID: On 3/16/06, Daniel Chudnov wrote: > I'm sorry to have been aloofish the past few days, there's a lot > going on over here and in the middle of it it's taken longer than I > expected to get the site at unapi.info up and going. Major points to > Ed Summers for making the validator happen (and Ross for the new > validator bookmarklet!) and for helping me to debug a failed tool > install today. If you haven't noticed it, unAPI is starting to make > the rounds some among the blogerati, so it seemed worthwhile to drop > things for a few days to get the "public face" of unAPI up to speed. > > Tomorrow's supposed to be the release date for revision 2. There are > still a lot of open issues. Several of them are quite small, > though. To churn through some quickly, review the list below and > vote inline after each proposed change with a +1/0/-1. Anything with > sufficient + votes will get changed; sufficient - votes will be voted > down, insufficient votes one way or the other will be dropped or > promoted to a full thread as responses warrant. > > I will word most of the proposed resolutions as active changes to the > spec, so if you don't want to see the change, vote it down. > > -Dan > > > > Issue: Should we specify anything about the server having the option > of adding a Location header to URI+FORMAT response? > > Proposed change: No, but add a mention of it along with the 302 > Found status code in the non-normative "recommended status codes" > section. > +1 for moving to a recommended status codes section > > > > Issue: Should the root node of the formats response be "unapi" > instead of "formats"? > > Proposed change: Yes, as it's more specific. > > +1 for future expansion > > > Issue: Should we add a colophon explaining how the spec is being > developed? > > Proposed change: No, but put it in the FAQ. > > +1 with the caveat that the spec should point to all non-normative reference docs (faq, response codes, etc) > > > Issue: Should uri-not-found or invalid-format responses return a > formats list with the uri and no formats? > > Proposed change: Yes, because this way at least developers will see > a predictable and "correct" unAPI response; otherwise, if we specify > nothing, implementors can do anything, which will make it harder to > code against implemented unAPI services. > +1 for invalid format / -1 for uri-not-found > > > > Issue: "URIs in unAPI HTTP calls must be url-encoded" is ambiguous > > Proposed change: Yes, it is. Remove this phrase. > -1 (modern HTTP servers give easy access to the decoded version anyway, and it avoids restricting the URI namespace (in light of the "anything goes" proposal)) > > > _______________________________________________ > gcs-pcs-list mailing list > gcs-pcs-list@cipolo.med.yale.edu > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list > -- Mike Rylander mrylander@gmail.com GPLS -- PINES Development Database Developer http://open-ils.org From liu_x at lanl.gov Wed Mar 15 22:35:33 2006 From: liu_x at lanl.gov (Xiaoming Liu) Date: Wed Mar 15 22:34:34 2006 Subject: [gcs-pcs-list] unAPI line item votes In-Reply-To: <36A80A3B-28A8-4558-9A52-2ABD619AA57E@yale.edu> References: <36A80A3B-28A8-4558-9A52-2ABD619AA57E@yale.edu> Message-ID: On Wed, 15 Mar 2006, Daniel Chudnov wrote: > > > Issue: Should we specify anything about the server having the option of > adding a Location header to URI+FORMAT response? > > Proposed change: No, but add a mention of it along with the 302 Found status > code in the non-normative "recommended status codes" section. > +1 > > > > Issue: Should the root node of the formats response be "unapi" instead of > "formats"? > > Proposed change: Yes, as it's more specific. > -1 I am thinking this issue may worth a full thread as it surfaced several times before. The standard way is by XML namespace, and XML namespace adds a flavor of extensibility, which is another big win (I am thinking RSS modules here). > > > > Issue: Should we add a colophon explaining how the spec is being developed? > > Proposed change: No, but put it in the FAQ. > +1 > > > > Issue: Should uri-not-found or invalid-format responses return a formats > list with the uri and no formats? > > Proposed change: Yes, because this way at least developers will see a > predictable and "correct" unAPI response; otherwise, if we specify nothing, > implementors can do anything, which will make it harder to code against > implemented unAPI services. > -1 I still see APP's approach is the cleanest -- only right behaviour is specified, and errors are in range of 4xx-5xx. Raymond and Leigh already gave very through analysis on this topic. I just want to add my 2 cents of running a OAI harvester a while ago. We know OAI-PMH had struggled to get error code correct, but in reality these error codes are rarely used -- because the harvester is also written in programming language. The majority of errors are XML or server related problems. > > > > Issue: "URIs in unAPI HTTP calls must be url-encoded" is ambiguous > > Proposed change: Yes, it is. Remove this phrase. > -1 second Alf's analysis. xiaoming > > > _______________________________________________ > gcs-pcs-list mailing list > gcs-pcs-list@cipolo.med.yale.edu > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list From ross.singer at library.gatech.edu Wed Mar 15 22:54:09 2006 From: ross.singer at library.gatech.edu (Ross Singer) Date: Wed Mar 15 22:55:12 2006 Subject: [gcs-pcs-list] unAPI line item votes In-Reply-To: <36A80A3B-28A8-4558-9A52-2ABD619AA57E@yale.edu> References: <36A80A3B-28A8-4558-9A52-2ABD619AA57E@yale.edu> Message-ID: <23b83f160603151954h4f6eb035t332bb8b85d4a0982@mail.gmail.com> On 3/15/06, Daniel Chudnov wrote: > > > Issue: Should we specify anything about the server having the option > of adding a Location header to URI+FORMAT response? > > Proposed change: No, but add a mention of it along with the 302 > Found status code in the non-normative "recommended status codes" > section. 0 - I don't even really know what this means or purpose it serves. Issue: Should the root node of the formats response be "unapi" > instead of "formats"? > > Proposed change: Yes, as it's more specific. Hmm, I can't even give a +/- on this... With it, what's different between this and OAI-PMH (or Atom) with a microformat for specifying the identifier? At the same time, I have argued for a wrapper... Issue: Should we add a colophon explaining how the spec is being > developed? > > Proposed change: No, but put it in the FAQ. +1 Issue: Should uri-not-found or invalid-format responses return a > formats list with the uri and no formats? > > Proposed change: Yes, because this way at least developers will see > a predictable and "correct" unAPI response; otherwise, if we specify > nothing, implementors can do anything, which will make it harder to > code against implemented unAPI services. -1, +1... uri-not-found should return a 404, I think... formats should return a 30x. Issue: "URIs in unAPI HTTP calls must be url-encoded" is ambiguous > > Proposed change: Yes, it is. Remove this phrase. -1 -Ross. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://cipolo.med.yale.edu/pipermail/gcs-pcs-list/attachments/20060315/78cf03ee/attachment-0001.htm From daniel.chudnov at yale.edu Wed Mar 15 23:21:27 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Wed Mar 15 23:22:32 2006 Subject: [gcs-pcs-list] unAPI line item votes In-Reply-To: <23b83f160603151954h4f6eb035t332bb8b85d4a0982@mail.gmail.com> References: <36A80A3B-28A8-4558-9A52-2ABD619AA57E@yale.edu> <23b83f160603151954h4f6eb035t332bb8b85d4a0982@mail.gmail.com> Message-ID: <10CED626-5B6E-4740-A5A6-FEA5DD8B3EE3@yale.edu> Just in case it matters (and surely this will be corrected if wrong :)... -dc On Mar 15, 2006, at 10:54 PM, Ross Singer wrote: > On 3/15/06, Daniel Chudnov wrote: > > Issue: Should we specify anything about the server having the option > of adding a Location header to URI+FORMAT response? > > Proposed change: No, but add a mention of it along with the 302 > Found status code in the non-normative "recommended status codes" > section. > > 0 - I don't even really know what this means or purpose it serves. When a redirect (i.e. most 3xx codes) is thrown, the new URL is included with the first response as the value in a Location: header. e.g. (newlines added to indicate separate requests): scott:~ dchud$ wget --spider http://curtis.med.yale.edu/~dchud --23:11:32-- http://curtis.med.yale.edu/~dchud => `~dchud' Resolving curtis.med.yale.edu... 128.36.123.51 Connecting to curtis.med.yale.edu|128.36.123.51|:80... connected. HTTP request sent, awaiting response... 302 Found Location: http://curtis.med.yale.edu/dchud [following] --23:11:32-- http://curtis.med.yale.edu/dchud => `dchud' Connecting to curtis.med.yale.edu|128.36.123.51|:80... connected. HTTP request sent, awaiting response... 301 Moved Permanently Location: http://curtis.med.yale.edu/dchud/ [following] --23:11:32-- http://curtis.med.yale.edu/dchud/ => `index.html' Connecting to curtis.med.yale.edu|128.36.123.51|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 7,854 (7.7K) [text/html] 200 OK The first response says: 302 Found, go to Location X (which wget follows). The second says: 301 Moved, go to Location Y (which wget follows). Because most web browsers will automatically "follow" a URL specified in the Location header of a response with code 3xx, but arbitrary unAPI client code might or might not, this proposed change was intended to remind people implementing unAPI services that it's best to set a Location header if a redirect really is intended. Most webapp frameworks I know will do this automatically, which is to say, if you call "myframework.redirect('http://some.example.com/')" the framework will set the 301 or 302 or whatever *and* set the Location header to http://some.example.com/. > Issue: Should uri-not-found or invalid-format responses return a > formats list with the uri and no formats? > > Proposed change: Yes, because this way at least developers will see > a predictable and "correct" unAPI response; otherwise, if we specify > nothing, implementors can do anything, which will make it harder to > code against implemented unAPI services. > > -1, +1... uri-not-found should return a 404, I think... formats > should return a 30x. The proposed change is only regarding the content of the http response, not the header or its status codes (none of which we're specifying). The entity content can contain most anything independent of the header's status code. -Dan From daniel.chudnov at yale.edu Thu Mar 16 18:07:34 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Thu Mar 16 18:07:37 2006 Subject: [gcs-pcs-list] unAPI line item votes In-Reply-To: References: <36A80A3B-28A8-4558-9A52-2ABD619AA57E@yale.edu> Message-ID: <20060316230734.GI19495@sildin.med.yale.edu> Eric Hellman wrote, on Wed, Mar 15, 2006 at 10:19:56PM -0500: > At 7:12 PM -0500 3/15/06, Daniel Chudnov wrote: > >Issue: "URIs in unAPI HTTP calls must be url-encoded" is ambiguous > > > >Proposed change: Yes, it is. Remove this phrase. > > better to replace with an example, with a URI containing a "?" , an > "=", or an "&" This is specified elsewhere... is RFC 3986 the correct reference? Wouldn't it be simpler to reference the correct RFC? -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From daniel.chudnov at yale.edu Thu Mar 16 18:15:57 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Thu Mar 16 18:15:59 2006 Subject: [gcs-pcs-list] unAPI line item votes In-Reply-To: References: <36A80A3B-28A8-4558-9A52-2ABD619AA57E@yale.edu> Message-ID: <20060316231557.GJ19495@sildin.med.yale.edu> Edward Summers wrote, on Wed, Mar 15, 2006 at 09:23:22PM -0600: > On Mar 15, 2006, at 6:12 PM, Daniel Chudnov wrote: > >Issue: Should we specify anything about the server having the > >option of adding a Location header to URI+FORMAT response? > > > >Proposed change: No, but add a mention of it along with the 302 > >Found status code in the non-normative "recommended status codes" > >section. > > -1 while this is useful during paste in APP it doesn't seem useful to > me in unapi as it stands now, and could add to http status code > confusion--should clients follow, etc... Sorry if I'm just being dense, but could you clarify what you mean here? A -1 vote against the proposed change means "yes we should specify something about adding a Location header". Which isn't what it sounds like you're saying. :) If you mean "No, don't specify anything", then it's +1, and the change passes as is. -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From daniel.chudnov at yale.edu Thu Mar 16 18:19:06 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Thu Mar 16 18:19:08 2006 Subject: [gcs-pcs-list] unAPI line item votes In-Reply-To: <36A80A3B-28A8-4558-9A52-2ABD619AA57E@yale.edu> References: <36A80A3B-28A8-4558-9A52-2ABD619AA57E@yale.edu> Message-ID: <20060316231906.GK19495@sildin.med.yale.edu> Reviewing each... Daniel Chudnov wrote, on Wed, Mar 15, 2006 at 07:12:36PM -0500: > > Issue: Should we specify anything about the server having the option > of adding a Location header to URI+FORMAT response? > > Proposed change: No, but add a mention of it along with the 302 > Found status code in the non-normative "recommended status codes" > section. This looks like it passes, modulo edsu's response, so it's pending his clarification. > Issue: Should the root node of the formats response be "unapi" > instead of "formats"? > > Proposed change: Yes, as it's more specific. This is controversial enough for a separate thread. > Issue: Should we add a colophon explaining how the spec is being > developed? > > Proposed change: No, but put it in the FAQ. This passes. > Issue: Should uri-not-found or invalid-format responses return a > formats list with the uri and no formats? > > Proposed change: Yes, because this way at least developers will see > a predictable and "correct" unAPI response; otherwise, if we specify > nothing, implementors can do anything, which will make it harder to > code against implemented unAPI services. This is controversial enough for a separate thread. > Issue: "URIs in unAPI HTTP calls must be url-encoded" is ambiguous > > Proposed change: Yes, it is. Remove this phrase. This fails, though adding a reference to the correct RFC should be uncontroversial, no? -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From daniel.chudnov at yale.edu Thu Mar 16 20:40:47 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Thu Mar 16 20:40:49 2006 Subject: [gcs-pcs-list] unAPI rev2 status core dump Message-ID: <20060317014046.GL19495@sildin.med.yale.edu> Here's where things stand: - The latest revision of the spec is here: http://curtis.med.yale.edu/dchud/unapi/latest.html http://curtis.med.yale.edu/dchud/unapi/latest.txt For easy comparison, here's the diff to rev1: http://curtis.med.yale.edu/dchud/unapi/compare.html (Ignore messed-up entity refs... sorry.) Please note the list of contributor names. I *think* I've added everybody's name from the past two months of discussion on gcs-pcs-list. If your name is missing, or you want your name listed with your institution, or a different spelling/form, or you want your name removed, please let me know. - Here's a dump of the current to-do list. I'd missed several suggestions for the queue from Xiaoming and Rob that are in there now. http://curtis.med.yale.edu/dchud/unapi/todo-latest.txt We have a busy month ahead of us. - The FAQ has been updated to include a blurb about how the spec is being developed. http://unapi.info/news/unapi-faq/ If this were a Big Hairy Standards-Making Body Initiative we would be nowhere near release. Good thing we're not! There's plenty left to discuss, but in a lot of ways, we already have a really good spec that does just what it says, which is a huge accomplishment. Please check over the current revision. I don't mind letting it slide overnight past today's deadline, but we should push rev2 out tomorrow. Let me know if anything is wrong or missing. Thanks, again, all, for sharing your time and wisdom to hammer this out. -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From daniel.chudnov at yale.edu Fri Mar 17 12:01:54 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Fri Mar 17 12:01:57 2006 Subject: [gcs-pcs-list] unAPI rev2 status core dump In-Reply-To: <20060317014046.GL19495@sildin.med.yale.edu> References: <20060317014046.GL19495@sildin.med.yale.edu> Message-ID: <20060317170153.GC24375@sildin.med.yale.edu> Daniel Chudnov wrote, on Thu, Mar 16, 2006 at 08:40:47PM -0500: > Here's where things stand: An update: nobody has responded. :) Could somebody/anybody ping me to say "yes go ahead" or "stop you madman" or "leave us alone already"? -dc -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From lists at hubmed.org Fri Mar 17 12:09:31 2006 From: lists at hubmed.org (Alf Eaton) Date: Fri Mar 17 12:12:49 2006 Subject: [gcs-pcs-list] unAPI rev2 status core dump In-Reply-To: <20060317170153.GC24375@sildin.med.yale.edu> References: <20060317014046.GL19495@sildin.med.yale.edu> <20060317170153.GC24375@sildin.med.yale.edu> Message-ID: On 17 Mar 2006, at 12:01, Daniel Chudnov wrote: > Daniel Chudnov wrote, on Thu, Mar 16, 2006 at 08:40:47PM -0500: >> Here's where things stand: > > An update: nobody has responded. :) > > Could somebody/anybody ping me to say "yes go ahead" or "stop you > madman" > or "leave us alone already"? I think you can go ahead with that - not much has changed really. Is there a reason why it's class="unapi-uri" and not just class="uri"? alf. From azaroth at liverpool.ac.uk Fri Mar 17 12:17:23 2006 From: azaroth at liverpool.ac.uk (Rob Sanderson) Date: Fri Mar 17 12:22:55 2006 Subject: [gcs-pcs-list] unAPI rev2 status core dump In-Reply-To: References: <20060317014046.GL19495@sildin.med.yale.edu> <20060317170153.GC24375@sildin.med.yale.edu> Message-ID: <1142615843.24337.47.camel@helmsdeep> +0 from me, as opposed to yes(+1)/no(-1)/go away(-inf) On Fri, 2006-03-17 at 12:09 -0500, Alf Eaton wrote: > Is there a reason why it's class="unapi-uri" and not just class="uri"? Namespace collision with other potential spans which happen to be URIs but have nothing to do with unapi. Rob -- Dr Robert Sanderson Dept of Computer Science, University of Liverpool Home: http://www.csc.liv.ac.uk/~azaroth/ Cheshire: http://www.cheshire3.org/ From leftwing at alumni.rutgers.edu Fri Mar 17 13:08:19 2006 From: leftwing at alumni.rutgers.edu (Michael J. Giarlo) Date: Fri Mar 17 13:09:23 2006 Subject: [gcs-pcs-list] unAPI rev2 status core dump In-Reply-To: <20060317170153.GC24375@sildin.med.yale.edu> References: <20060317014046.GL19495@sildin.med.yale.edu> <20060317170153.GC24375@sildin.med.yale.edu> Message-ID: <22dbc4ae0603171008m5217b77fkb85b97ce1efa1a2d@mail.gmail.com> On 3/17/06, Daniel Chudnov wrote: > > > An update: nobody has responded. :) > > Could somebody/anybody ping me to say "yes go ahead" or "stop you madman" > or "leave us alone already"? Go forth! -Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: http://cipolo.med.yale.edu/pipermail/gcs-pcs-list/attachments/20060317/e4b427cd/attachment.htm From daniel.chudnov at yale.edu Fri Mar 17 13:22:58 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Fri Mar 17 13:23:00 2006 Subject: [gcs-pcs-list] unAPI revision 2 published Message-ID: <20060317182257.GG24375@sildin.med.yale.edu> (Thanks, Alf, Rob, and Mike for the reassuring nudge.) Read all about it at: http://unapi.info/news/archives/9 Come Monday, we'll start in on that lengthy list. -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From eric at openly.com Mon Mar 20 15:33:11 2006 From: eric at openly.com (Eric Hellman) Date: Mon Mar 20 15:34:34 2006 Subject: [gcs-pcs-list] COinS in OpenWorldCat; Resolver registry integrated in OpenURL Referrer In-Reply-To: <20060316230734.GI19495@sildin.med.yale.edu> References: <36A80A3B-28A8-4558-9A52-2ABD619AA57E@yale.edu> <20060316230734.GI19495@sildin.med.yale.edu> Message-ID: In case anyone missed it, Lorcan has blogged the introduction of COinS in OpenWorldCat: http://orweblog.oclc.org/archives/000968.html See also notice from Tim O'Reilly http://radar.oreilly.com/archives/2006/03/link_list_reading_20_1.html and Adobe's Bill McCoy http://blogs.adobe.com/billmccoy/2006/03/reading_20_reca.html -- Eric Hellman, Director OCLC Openly Informatics Division eric@openly.com 2 Broad St., Suite 208 tel 1-973-509-7800 fax 1-734-468-6216 Bloomfield, NJ 07003 http://www.openly.com/1cate/ 1 Click Access To Everything From ehs at pobox.com Mon Mar 20 17:50:35 2006 From: ehs at pobox.com (Ed Summers) Date: Mon Mar 20 17:51:38 2006 Subject: [gcs-pcs-list] COinS in OpenWorldCat; Resolver registry integrated in OpenURL Referrer In-Reply-To: References: <36A80A3B-28A8-4558-9A52-2ABD619AA57E@yale.edu> <20060316230734.GI19495@sildin.med.yale.edu> Message-ID: On 3/20/06, Eric Hellman wrote: > See also notice from Tim O'Reilly > http://radar.oreilly.com/archives/2006/03/link_list_reading_20_1.html > and Adobe's Bill McCoy > http://blogs.adobe.com/billmccoy/2006/03/reading_20_reca.html Thanks for the pointer Eric. This totally slipped under my 'radar' ... pretty awesome to see library standards/technologies getting some exposure outside of library land. //Ed From ehs at pobox.com Tue Mar 21 08:28:20 2006 From: ehs at pobox.com (Edward Summers) Date: Tue Mar 21 08:28:55 2006 Subject: [gcs-pcs-list] unapi validator warnings Message-ID: I liked Xiaoming's suggestion for 3 levels of validatior results: pass, warn and fail [1] and the current validator [2] will do this...with a new color scheme courtesy of dchud. Currently the only warnings that are generated are for http status codes. Next I'm going to try to have the validator emit more helpful messages that assist in fixing identified problems...not just identifying them. //Ed [1] http://cipolo.med.yale.edu/pipermail/gcs-pcs-list/2006-March/ 000606.html [2] http://validator.unapi.info From daniel.chudnov at yale.edu Tue Mar 21 17:30:17 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Tue Mar 21 17:30:20 2006 Subject: [gcs-pcs-list] unAPI issue: rename root node? Message-ID: <20060321223017.GF3685@sildin.med.yale.edu> Back to the grind... we have lots to work through so I'll try to keep two issue threads going at once. I'm also putting in a big push to get the unalog unapi+atom thingy working for real soon. The first issue on the list right now is: should we rename the root node of the unAPI formats response, which is currently "formats", to "unapi"? There was some interest in this with last week's line item vote, but comments ranged from "yes" to "yes but keep 'formats' under it" to "no". If we wrap the whole response in a "unapi" root node, it might add some clarity for apps mixing up the data with other stuff. The argument for keeping the formats/format structure in tact under a new "unapi" wrapper I'm remembering just now went like this: "so we can add stuff to unapi later." I see the point of that. But, at present, we don't have anything on our agenda aside from the basic unAPI functions we've already agreed on. Not that descending/xpathing an extra level is terribly painful, but, it is more verbose than we need, technically, today. More arguments/elaborations either way? -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From azaroth at liverpool.ac.uk Tue Mar 21 17:35:18 2006 From: azaroth at liverpool.ac.uk (Robert Sanderson) Date: Tue Mar 21 17:38:30 2006 Subject: [gcs-pcs-list] unAPI issue: rename root node? In-Reply-To: <20060321223017.GF3685@sildin.med.yale.edu> References: <20060321223017.GF3685@sildin.med.yale.edu> Message-ID: -1 What would you ever want to put into a formats response that couldn't be under a element? Rob On Tue, 21 Mar 2006, Daniel Chudnov wrote: >Back to the grind... we have lots to work through so I'll try to keep >two issue threads going at once. I'm also putting in a big push to get >the unalog unapi+atom thingy working for real soon. > >The first issue on the list right now is: should we rename the >root node of the unAPI formats response, which is currently "formats", >to "unapi"? There was some interest in this with last week's line item >vote, but comments ranged from "yes" to "yes but keep 'formats' under >it" to "no". > >If we wrap the whole response in a "unapi" root node, it might add some >clarity for apps mixing up the data with other stuff. The argument for >keeping the formats/format structure in tact under a new "unapi" wrapper >I'm remembering just now went like this: > > "so we can add stuff to unapi later." > >I see the point of that. But, at present, we don't have anything on >our agenda aside from the basic unAPI functions we've already agreed >on. Not that descending/xpathing an extra level is terribly painful, >but, it is more verbose than we need, technically, today. > >More arguments/elaborations either way? > > -Dan > > >-- >Daniel Chudnov >Yale Center for Medical Informatics >(203) 737-5789 >_______________________________________________ >gcs-pcs-list mailing list >gcs-pcs-list@cipolo.med.yale.edu >http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list > From daniel.chudnov at yale.edu Tue Mar 21 17:43:44 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Tue Mar 21 17:43:47 2006 Subject: [gcs-pcs-list] unAPI issue: 404 and formats list Message-ID: <20060321224344.GH3685@sildin.med.yale.edu> Another unresolved question from the line item vote was: Should uri-not-found (recommended 404) responses return a formats list with the uri and no formats? It seems to add to the length of the specification, but as it doesn't add information, it only helps out one kind of implementation (the xml-modality-centric one Eric preferred). Other implementation types could just as easily check for 404 or non-application-xml content-type or a missing formats/unapi block. So, since we don't even have that many unAPI consuming apps to compare yet, it's hard to argue that we have a sense of best practices yet, so my instinct is to want to leave this unspecified unless/until we have a clearer, demonstrated use case for adding it. -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From liu_x at lanl.gov Tue Mar 21 17:51:27 2006 From: liu_x at lanl.gov (Xiaoming Liu) Date: Tue Mar 21 17:50:16 2006 Subject: [gcs-pcs-list] unAPI issue: rename root node? In-Reply-To: <20060321223017.GF3685@sildin.med.yale.edu> References: <20060321223017.GF3685@sildin.med.yale.edu> Message-ID: On Tue, 21 Mar 2006, Daniel Chudnov wrote: > Back to the grind... we have lots to work through so I'll try to keep > two issue threads going at once. I'm also putting in a big push to get > the unalog unapi+atom thingy working for real soon. > > The first issue on the list right now is: should we rename the > root node of the unAPI formats response, which is currently "formats", > to "unapi"? There was some interest in this with last week's line item > vote, but comments ranged from "yes" to "yes but keep 'formats' under > it" to "no". I would argue to use xml namespace for this purpose, such as . Maybe XML is evil but namespace is a good part of XML. With XML namespace we naturelly achieve: (1) distinguish from other XML -- topic of this thread. (2) extensibility, think about RSS modules. (3) it's a common practice used by RSS, Atom, and many more. Notice I am not supporting XML schema here. xiaoming > > If we wrap the whole response in a "unapi" root node, it might add some > clarity for apps mixing up the data with other stuff. The argument for > keeping the formats/format structure in tact under a new "unapi" wrapper > I'm remembering just now went like this: > > "so we can add stuff to unapi later." > > I see the point of that. But, at present, we don't have anything on > our agenda aside from the basic unAPI functions we've already agreed > on. Not that descending/xpathing an extra level is terribly painful, > but, it is more verbose than we need, technically, today. > > More arguments/elaborations either way? > > -Dan > > > From daniel.chudnov at yale.edu Tue Mar 21 17:53:04 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Tue Mar 21 17:53:06 2006 Subject: [gcs-pcs-list] unAPI issue: rename root node? In-Reply-To: References: <20060321223017.GF3685@sildin.med.yale.edu> Message-ID: <20060321225304.GI3685@sildin.med.yale.edu> Robert Sanderson wrote, on Tue, Mar 21, 2006 at 10:35:18PM +0000: > > -1 > > What would you ever want to put into a formats response that couldn't be > under a element? Erk, maybe I should clarify: there are two options, it seems. Should we rename the root node to "unapi"? Should we push the current schema, in tact, down under a new "unapi" wrapper element? I can't quite tell which of these two you're -1ing up there. :) -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From azaroth at liverpool.ac.uk Tue Mar 21 18:13:19 2006 From: azaroth at liverpool.ac.uk (Robert Sanderson) Date: Tue Mar 21 18:13:22 2006 Subject: [gcs-pcs-list] unAPI issue: rename root node? In-Reply-To: <20060321225304.GI3685@sildin.med.yale.edu> References: <20060321223017.GF3685@sildin.med.yale.edu> <20060321225304.GI3685@sildin.med.yale.edu> Message-ID: >> -1 >> What would you ever want to put into a formats response that couldn't be >> under a element? >Erk, maybe I should clarify: there are two options, it seems. > Should we rename the root node to "unapi"? -1 Maybe you could rename the unapi? document to unapi and push down formats in that, but ... it's the formats response, why would you want to call it unapi? > Should we push the current schema, in tact, down under a new "unapi" > wrapper element? -1, as above. Surely the formats response is about formats. >I can't quite tell which of these two you're -1ing up there. :) Both, it seems :) Rob From azaroth at liverpool.ac.uk Tue Mar 21 18:22:15 2006 From: azaroth at liverpool.ac.uk (Robert Sanderson) Date: Tue Mar 21 18:25:28 2006 Subject: [gcs-pcs-list] unAPI issue: rename root node? In-Reply-To: References: <20060321223017.GF3685@sildin.med.yale.edu> Message-ID: Normally, I would agree, but unapi is supposed to be the lowest possible barrier to entry and like it or not, namespaces raise that barrier quite a lot, both in limiting parsers and making it harder to work with. (namespaces in unapi: -1) Rob On Tue, 21 Mar 2006, Xiaoming Liu wrote: >On Tue, 21 Mar 2006, Daniel Chudnov wrote: > >> Back to the grind... we have lots to work through so I'll try to keep >> two issue threads going at once. I'm also putting in a big push to get >> the unalog unapi+atom thingy working for real soon. >> >> The first issue on the list right now is: should we rename the >> root node of the unAPI formats response, which is currently "formats", >> to "unapi"? There was some interest in this with last week's line item >> vote, but comments ranged from "yes" to "yes but keep 'formats' under >> it" to "no". > > >I would argue to use xml namespace for this purpose, such as xmlns="http://unapi.info">. Maybe XML is evil but namespace is a good >part of XML. With XML namespace we naturelly achieve: > >(1) distinguish from other XML -- topic of this thread. >(2) extensibility, think about RSS modules. >(3) it's a common practice used by RSS, Atom, and many more. > >Notice I am not supporting XML schema here. > >xiaoming > > >> >> If we wrap the whole response in a "unapi" root node, it might add some >> clarity for apps mixing up the data with other stuff. The argument for >> keeping the formats/format structure in tact under a new "unapi" wrapper >> I'm remembering just now went like this: >> >> "so we can add stuff to unapi later." >> >> I see the point of that. But, at present, we don't have anything on >> our agenda aside from the basic unAPI functions we've already agreed >> on. Not that descending/xpathing an extra level is terribly painful, >> but, it is more verbose than we need, technically, today. >> >> More arguments/elaborations either way? >> >> -Dan >> >> >> > > >_______________________________________________ >gcs-pcs-list mailing list >gcs-pcs-list@cipolo.med.yale.edu >http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list > From eric at openly.com Tue Mar 21 18:26:55 2006 From: eric at openly.com (Eric Hellman) Date: Tue Mar 21 18:28:17 2006 Subject: [gcs-pcs-list] unAPI issue: rename root node? In-Reply-To: References: <20060321223017.GF3685@sildin.med.yale.edu> Message-ID: I think a significant segment of developers will interpret the absence of an xml schema as evidence of amateurishness, instability, not-finished-yet-ness, or all of these, and they will go away. At 3:51 PM -0700 3/21/06, Xiaoming Liu wrote: >I would argue to use xml namespace for this purpose, such as >. Maybe XML is evil but namespace >is a good part of XML. With XML namespace we naturelly achieve: > >(1) distinguish from other XML -- topic of this thread. >(2) extensibility, think about RSS modules. (3) it's a common >practice used by RSS, Atom, and many more. > >Notice I am not supporting XML schema here. -- Eric Hellman, Director OCLC Openly Informatics Division eric@openly.com 2 Broad St., Suite 208 tel 1-973-509-7800 fax 1-734-468-6216 Bloomfield, NJ 07003 http://www.openly.com/1cate/ 1 Click Access To Everything From azaroth at liverpool.ac.uk Tue Mar 21 18:34:18 2006 From: azaroth at liverpool.ac.uk (Robert Sanderson) Date: Tue Mar 21 18:34:21 2006 Subject: [gcs-pcs-list] XML Schema In-Reply-To: References: <20060321223017.GF3685@sildin.med.yale.edu> Message-ID: I'm not sure that I agree. I think that if the xml gets to the point where it needs a schema, we've made things too complicated and need to re-evaluate how all of this stuff has crept into the spec. R On Tue, 21 Mar 2006, Eric Hellman wrote: >I think a significant segment of developers will interpret the >absence of an xml schema as evidence of amateurishness, instability, >not-finished-yet-ness, or all of these, and they will go away. > > > >At 3:51 PM -0700 3/21/06, Xiaoming Liu wrote: >>I would argue to use xml namespace for this purpose, such as >>. Maybe XML is evil but namespace >>is a good part of XML. With XML namespace we naturelly achieve: >> >>(1) distinguish from other XML -- topic of this thread. >>(2) extensibility, think about RSS modules. (3) it's a common >>practice used by RSS, Atom, and many more. >> >>Notice I am not supporting XML schema here. > >-- > >Eric Hellman, Director OCLC Openly >Informatics Division >eric@openly.com 2 Broad St., Suite 208 >tel 1-973-509-7800 fax 1-734-468-6216 Bloomfield, NJ 07003 >http://www.openly.com/1cate/ 1 Click Access To Everything >_______________________________________________ >gcs-pcs-list mailing list >gcs-pcs-list@cipolo.med.yale.edu >http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list > From daniel.chudnov at yale.edu Tue Mar 21 18:37:59 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Tue Mar 21 18:38:00 2006 Subject: [gcs-pcs-list] unAPI issue: rename root node? In-Reply-To: References: <20060321223017.GF3685@sildin.med.yale.edu> Message-ID: <20060321233758.GJ3685@sildin.med.yale.edu> Eric Hellman wrote, on Tue, Mar 21, 2006 at 06:26:55PM -0500: > I think a significant segment of developers will interpret the > absence of an xml schema as evidence of amateurishness, instability, > not-finished-yet-ness, or all of these, and they will go away. The Atom Publishing Protocol -- one of the hottest topics going, and led by some folks not typically described as amateurish -- only provides an informative schema. http://bitworking.org/projects/atom/draft-ietf-atompub-protocol-08.html#schema And, it's not finished yet. :) Let's stay on topic... I'll note the issues of "do we need a namespace" and "do we need a schema". -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From liu_x at lanl.gov Tue Mar 21 18:43:18 2006 From: liu_x at lanl.gov (Xiaoming Liu) Date: Tue Mar 21 18:42:06 2006 Subject: [gcs-pcs-list] unAPI issue: rename root node? In-Reply-To: References: <20060321223017.GF3685@sildin.med.yale.edu> Message-ID: On Tue, 21 Mar 2006, Eric Hellman wrote: > I think a significant segment of developers will interpret the absence of an > xml schema as evidence of amateurishness, instability, not-finished-yet-ness, > or all of these, and they will go away. I disagree, RSS and Atom don't have a mandatory schema. Atom said "the text of this specification provides the definition of conformance". Of course, interesting party can write a schema locally or put it online for comformance check, I just think they don't belong to the spec. xiaoming > > > > At 3:51 PM -0700 3/21/06, Xiaoming Liu wrote: >> I would argue to use xml namespace for this purpose, such as > xmlns="http://unapi.info">. Maybe XML is evil but namespace is a good part >> of XML. With XML namespace we naturelly achieve: >> >> (1) distinguish from other XML -- topic of this thread. >> (2) extensibility, think about RSS modules. (3) it's a common practice used >> by RSS, Atom, and many more. >> >> Notice I am not supporting XML schema here. > > -- Xiaoming From ehs at pobox.com Tue Mar 21 20:23:01 2006 From: ehs at pobox.com (Edward Summers) Date: Tue Mar 21 21:24:52 2006 Subject: [gcs-pcs-list] unAPI issue: 404 and formats list Message-ID: <749D12D0-029F-4D09-A321-E8DA5EE1BD9B@pobox.com> On Mar 21, 2006, at 4:43 PM, Daniel Chudnov wrote: > So, since we don't even have that many unAPI consuming apps to compare > yet, it's hard to argue that we have a sense of best practices yet, so > my instinct is to want to leave this unspecified unless/until we have > a clearer, demonstrated use case for adding it. +1 less to implement //Ed From ksclarke at gmail.com Tue Mar 21 21:50:08 2006 From: ksclarke at gmail.com (Kevin S. Clarke) Date: Tue Mar 21 21:51:29 2006 Subject: [gcs-pcs-list] XML Schema In-Reply-To: References: <20060321223017.GF3685@sildin.med.yale.edu> Message-ID: <3557b8d0603211850v1ede622kfc42eec29a0c79b3@mail.gmail.com> I agree with Eric Hellman. I think the level of simplicity that would warrant no schema would also be the level at which XML itself would be unnecessary. If you can describe something in less than 5 key-value pairs, okay. If you need XML, I think you need something that says what it should look like. I'd suggest RELAX NG instead of W3C Schema though. fwiw, Kevin On 3/21/06, Robert Sanderson wrote: > > I'm not sure that I agree. > I think that if the xml gets to the point where it needs a schema, we've > made things too complicated and need to re-evaluate how all of this > stuff has crept into the spec. > > R > > > > On Tue, 21 Mar 2006, Eric Hellman wrote: > > >I think a significant segment of developers will interpret the > >absence of an xml schema as evidence of amateurishness, instability, > >not-finished-yet-ness, or all of these, and they will go away. > > > > > > > >At 3:51 PM -0700 3/21/06, Xiaoming Liu wrote: > >>I would argue to use xml namespace for this purpose, such as > >>. Maybe XML is evil but namespace > >>is a good part of XML. With XML namespace we naturelly achieve: > >> > >>(1) distinguish from other XML -- topic of this thread. > >>(2) extensibility, think about RSS modules. (3) it's a common > >>practice used by RSS, Atom, and many more. > >> > >>Notice I am not supporting XML schema here. > > > >-- > > > >Eric Hellman, Director OCLC Openly > >Informatics Division > >eric@openly.com 2 Broad St., Suite 208 > >tel 1-973-509-7800 fax 1-734-468-6216 Bloomfield, NJ 07003 > >http://www.openly.com/1cate/ 1 Click Access To Everything > >_______________________________________________ > >gcs-pcs-list mailing list > >gcs-pcs-list@cipolo.med.yale.edu > >http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list > > > _______________________________________________ > gcs-pcs-list mailing list > gcs-pcs-list@cipolo.med.yale.edu > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list > From liu_x at lanl.gov Tue Mar 21 22:26:13 2006 From: liu_x at lanl.gov (Xiaoming Liu) Date: Tue Mar 21 22:25:01 2006 Subject: [gcs-pcs-list] unAPI issue: 404 and formats list In-Reply-To: <20060321224344.GH3685@sildin.med.yale.edu> References: <20060321224344.GH3685@sildin.med.yale.edu> Message-ID: +1 There is another interesting observation about atom protocol error processing, I spent some time reading atom email list but didn't get a clear answer, so perhaps someone can englight me here. There is a simialr change of http error code between app 0.2 and app 0.4 http://bitworking.org/projects/atom/draft-ietf-atompub-protocol-02.html http://bitworking.org/projects/atom/draft-ietf-atompub-protocol-04.html in app0.2 all kinds of http error code are suggested, in 0.4 all these errors are dropped and take current shape of app0.8. I am trying to find arguments/rational behind this decision because it's very much related to discussion here. However the only relavant thing I got is http://www.imc.org/atom-protocol/mail-archive/msg00323.html, It would be very helpful to find their insight of this issue. xiaoming On Tue, 21 Mar 2006, Daniel Chudnov wrote: > Another unresolved question from the line item vote was: > > Should uri-not-found (recommended 404) responses return a formats list > with the uri and no formats? > > It seems to add to the length of the specification, but as it doesn't > add information, it only helps out one kind of implementation (the > xml-modality-centric one Eric preferred). Other implementation types > could just as easily check for 404 or non-application-xml content-type > or a missing formats/unapi block. > > So, since we don't even have that many unAPI consuming apps to compare > yet, it's hard to argue that we have a sense of best practices yet, so > my instinct is to want to leave this unspecified unless/until we have > a clearer, demonstrated use case for adding it. > > -Dan > > > From daniel.chudnov at yale.edu Wed Mar 22 00:12:39 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Wed Mar 22 00:13:41 2006 Subject: [gcs-pcs-list] XML Schema In-Reply-To: <3557b8d0603211850v1ede622kfc42eec29a0c79b3@mail.gmail.com> References: <20060321223017.GF3685@sildin.med.yale.edu> <3557b8d0603211850v1ede622kfc42eec29a0c79b3@mail.gmail.com> Message-ID: <74C4754C-2891-499F-BF03-095CDB61A6EA@yale.edu> On Mar 21, 2006, at 9:50 PM, Kevin S. Clarke wrote: > If you need XML, I think you need something that says > what it should look like. I'd suggest RELAX NG instead of W3C Schema > though. Rather than all of us debating this, could you do this? It seems sensible to consider including an informative RNG schema (as that's what APP does); it will be easier to decide if it's already in front of us. :) Starting with the spec as currently written would probably be best. Thanks, -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From ksclarke at gmail.com Wed Mar 22 00:34:56 2006 From: ksclarke at gmail.com (Kevin S. Clarke) Date: Wed Mar 22 00:36:04 2006 Subject: [gcs-pcs-list] XML Schema In-Reply-To: <74C4754C-2891-499F-BF03-095CDB61A6EA@yale.edu> References: <20060321223017.GF3685@sildin.med.yale.edu> <3557b8d0603211850v1ede622kfc42eec29a0c79b3@mail.gmail.com> <74C4754C-2891-499F-BF03-095CDB61A6EA@yale.edu> Message-ID: <3557b8d0603212134k640f9615w1979aa0f3470c718@mail.gmail.com> Sure, be glad to... Kevin On 3/22/06, Daniel Chudnov wrote: > On Mar 21, 2006, at 9:50 PM, Kevin S. Clarke wrote: > > > If you need XML, I think you need something that says > > what it should look like. I'd suggest RELAX NG instead of W3C Schema > > though. > > Rather than all of us debating this, could you do this? It seems > sensible to consider including an informative RNG schema (as that's > what APP does); it will be easier to decide if it's already in front > of us. :) > > Starting with the spec as currently written would probably be best. > > Thanks, -Dan > > > -- > Daniel Chudnov > Yale Center for Medical Informatics > (203) 737-5789 > > > > From ehs at pobox.com Wed Mar 22 07:08:36 2006 From: ehs at pobox.com (Edward Summers) Date: Wed Mar 22 07:10:11 2006 Subject: [gcs-pcs-list] unAPI issue: rename root node? Message-ID: <728D07B7-5D9C-4966-94EE-D4F64CB05E24@pobox.com> On Mar 21, 2006, at 4:53 PM, Daniel Chudnov wrote: > Should we rename the root node to "unapi"? -1 > Should we push the current schema, intact, down under a new "unapi" > wrapper element? -1 //Ed From mrylander at gmail.com Wed Mar 22 08:35:22 2006 From: mrylander at gmail.com (Mike Rylander) Date: Wed Mar 22 08:36:29 2006 Subject: [gcs-pcs-list] unAPI issue: rename root node? In-Reply-To: <20060321223017.GF3685@sildin.med.yale.edu> References: <20060321223017.GF3685@sildin.med.yale.edu> Message-ID: The way I look at the current formats responses, there are two mostly orthogonal situations. The first, and the one that is generating most of the -1s AFAICT, is the response to a URI request with no format specified. In that case, I can see the point of not changing the schema. The only reasonable implied question is "what are the formats that I can get this resource in," and the current formats schema answers that question succinctly. The second, which I think requires more debate, is a bare request to the base URL. In that case I would love to see a wrapper element, for the "so we can add stuff" reason. Is it unreasonable to imagine that we'll want to extend the base response in the future, especially when (and if) we decide to tackle paste? I'd hate to see another GET param when an extension of the current framework would do what we need and cause no more trouble than adding an extra "/" at the front of any XPath that looks for elements. Now, I suppose there is an argument to be made for consistency in the non-resource responses. But as Dan pointed out, it isn't that much trouble to deal with an extra node at the top of the tree, and the schema isn't being broken, just embedded in a more useful node, not to mention the fact that I view the two responses as entirely different functions ("formats for this" and "tell me about your service"). For that reason, I'd like to propose that the base response be reconsidered at the end of the queue with regard to an root node. And, for the reasons above, on the issue of URI-specific formats responses I'll vote -0.5 on both counts to stop the change. On 3/21/06, Daniel Chudnov wrote: > Back to the grind... we have lots to work through so I'll try to keep > two issue threads going at once. I'm also putting in a big push to get > the unalog unapi+atom thingy working for real soon. > > The first issue on the list right now is: should we rename the > root node of the unAPI formats response, which is currently "formats", > to "unapi"? There was some interest in this with last week's line item > vote, but comments ranged from "yes" to "yes but keep 'formats' under > it" to "no". > > If we wrap the whole response in a "unapi" root node, it might add some > clarity for apps mixing up the data with other stuff. The argument for > keeping the formats/format structure in tact under a new "unapi" wrapper > I'm remembering just now went like this: > > "so we can add stuff to unapi later." > > I see the point of that. But, at present, we don't have anything on > our agenda aside from the basic unAPI functions we've already agreed > on. Not that descending/xpathing an extra level is terribly painful, > but, it is more verbose than we need, technically, today. > > More arguments/elaborations either way? > > -Dan > > > -- > Daniel Chudnov > Yale Center for Medical Informatics > (203) 737-5789 > _______________________________________________ > gcs-pcs-list mailing list > gcs-pcs-list@cipolo.med.yale.edu > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list > -- Mike Rylander mrylander@gmail.com GPLS -- PINES Development Database Developer http://open-ils.org From azaroth at liverpool.ac.uk Wed Mar 22 08:54:27 2006 From: azaroth at liverpool.ac.uk (Rob Sanderson) Date: Wed Mar 22 09:00:37 2006 Subject: [gcs-pcs-list] unAPI issue: rename root node? In-Reply-To: References: <20060321223017.GF3685@sildin.med.yale.edu> Message-ID: <1143035667.15246.33.camel@helmsdeep> On Wed, 2006-03-22 at 08:35 -0500, Mike Rylander wrote: > The first, and the one that is generating most of the -1s AFAICT, is > the response to a URI request with no format specified. In that case, > I can see the point of not changing the schema. The only reasonable > implied question is "what are the formats that I can get this resource > in," and the current formats schema answers that question succinctly. The question could be: Please give me all of the metadata associated with this object, which would include the available formats but might also have information such as creationTime, lastModificiationTime, owner, bla bla bla.... I'm not saying this is a good idea, note, just that there is extra metadata beyond formats that some people might consider useful. > The second, which I think requires more debate, is a bare request to > the base URL. In that case I would love to see a wrapper > element, for the "so we can add stuff" reason. I agree. There's a lot more metadata that can be attached to a service, rather than to a record available within that service. For the main introspection/service description document at unapi? I think there should be significantly more discussion as to exactly what is useful or appropriate to go into it. Z39.92 for example (yeah yeah, obligatory disclaimer) has a lot more information in it for describing exactly this sort of service than just formats. Rob -- Dr Robert Sanderson Dept of Computer Science, University of Liverpool Home: http://www.csc.liv.ac.uk/~azaroth/ Cheshire: http://www.cheshire3.org/ From azaroth at liverpool.ac.uk Wed Mar 22 08:59:03 2006 From: azaroth at liverpool.ac.uk (Rob Sanderson) Date: Wed Mar 22 09:05:17 2006 Subject: [gcs-pcs-list] Params: Empty vs not present In-Reply-To: <1143035667.15246.33.camel@helmsdeep> References: <20060321223017.GF3685@sildin.med.yale.edu> <1143035667.15246.33.camel@helmsdeep> Message-ID: <1143035943.15246.39.camel@helmsdeep> To add to the queue: Is an empty parameter the same as the parameter not being present? For example: Is: unapi?uri=&format= the same as: unapi? Is: unapi?uri=abc&format= the same as: unapi?uri=abc If not, then what are the semantics of a null value in uri and format? Rob -- Dr Robert Sanderson Dept of Computer Science, University of Liverpool Home: http://www.csc.liv.ac.uk/~azaroth/ Cheshire: http://www.cheshire3.org/ From mrylander at gmail.com Wed Mar 22 10:48:38 2006 From: mrylander at gmail.com (Mike Rylander) Date: Wed Mar 22 10:49:42 2006 Subject: [gcs-pcs-list] Params: Empty vs not present In-Reply-To: <1143035943.15246.39.camel@helmsdeep> References: <20060321223017.GF3685@sildin.med.yale.edu> <1143035667.15246.33.camel@helmsdeep> <1143035943.15246.39.camel@helmsdeep> Message-ID: On 3/22/06, Rob Sanderson wrote: > To add to the queue: > > Is an empty parameter the same as the parameter not being present? > > For example: > > Is: unapi?uri=&format= > the same as: unapi? > > Is: unapi?uri=abc&format= > the same as: unapi?uri=abc I think, for simplicity's sake, they are the same unless there's a suggested semantic meaning (which there is not in the OP). But it's a good point to bring up. :) > > If not, then what are the semantics of a null value in uri and format? > > Rob > -- > Dr Robert Sanderson > Dept of Computer Science, University of Liverpool > Home: http://www.csc.liv.ac.uk/~azaroth/ > Cheshire: http://www.cheshire3.org/ > > _______________________________________________ > gcs-pcs-list mailing list > gcs-pcs-list@cipolo.med.yale.edu > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list > -- Mike Rylander mrylander@gmail.com GPLS -- PINES Development Database Developer http://open-ils.org From eric at openly.com Wed Mar 22 11:10:41 2006 From: eric at openly.com (Eric Hellman) Date: Wed Mar 22 11:12:05 2006 Subject: [gcs-pcs-list] XML Schema In-Reply-To: <3557b8d0603212134k640f9615w1979aa0f3470c718@mail.gmail.com> References: <20060321223017.GF3685@sildin.med.yale.edu> <3557b8d0603211850v1ede622kfc42eec29a0c79b3@mail.gmail.com> <74C4754C-2891-499F-BF03-095CDB61A6EA@yale.edu> <3557b8d0603212134k640f9615w1979aa0f3470c718@mail.gmail.com> Message-ID: an informative RNG would address the "perception" aspect of my concern. At 12:34 AM -0500 3/22/06, Kevin S. Clarke wrote: >Sure, be glad to... > >Kevin > >On 3/22/06, Daniel Chudnov wrote: >> On Mar 21, 2006, at 9:50 PM, Kevin S. Clarke wrote: >> >> > If you need XML, I think you need something that says >> > what it should look like. I'd suggest RELAX NG instead of W3C Schema >> > though. >> >> Rather than all of us debating this, could you do this? It seems >> sensible to consider including an informative RNG schema (as that's >> what APP does); it will be easier to decide if it's already in front >> of us. :) >> >> Starting with the spec as currently written would probably be best. >> > > Thanks, -Dan -- Eric Hellman, Director OCLC Openly Informatics Division eric@openly.com 2 Broad St., Suite 208 tel 1-973-509-7800 fax 1-734-468-6216 Bloomfield, NJ 07003 http://www.openly.com/1cate/ 1 Click Access To Everything From liu_x at lanl.gov Wed Mar 22 11:25:34 2006 From: liu_x at lanl.gov (Xiaoming Liu) Date: Wed Mar 22 11:24:44 2006 Subject: [gcs-pcs-list] unAPI issue: rename root node? In-Reply-To: <1143035667.15246.33.camel@helmsdeep> References: <20060321223017.GF3685@sildin.med.yale.edu> <1143035667.15246.33.camel@helmsdeep> Message-ID: On Wed, 22 Mar 2006, Rob Sanderson wrote: > > The question could be: Please give me all of the metadata associated > with this object, which would include the available formats but might > also have information such as creationTime, lastModificiationTime, > owner, bla bla bla.... > > I'm not saying this is a good idea, note, just that there is extra > metadata beyond formats that some people might consider useful. yes, and I think XML namespace is good solution to this problem. I don't think we want to bloat unAPI, but interesting party can add more information to experiment without breaking unAPI. e.g. in Flickr it might be good to have photo resolution information inside of unAPI root: 200x200, one service can choose to ignore all namespace it doesn't recognize; and another service might be particularly interested in flickr and use it. So eventually there might be consensus on what metadata are useful, such as RSS modules; or one producer is so powerful that many services support it. The detail is beyond the scope of unAPI, however unAPI should provide a mechanism for this kind of natural evoluation by XML namespace. > > > >> The second, which I think requires more debate, is a bare request to >> the base URL. In that case I would love to see a wrapper >> element, for the "so we can add stuff" reason. > > I agree. There's a lot more metadata that can be attached to a service, > rather than to a record available within that service. For the main > introspection/service description document at unapi? I think there > should be significantly more discussion as to exactly what is useful or > appropriate to go into it. > Yes, I can imagine a lot of information are also useful here. Still my point is to support a mechanism for extensibility, but not extending it inside of unAPI. xiaoming > Z39.92 for example (yeah yeah, obligatory disclaimer) has a lot more > information in it for describing exactly this sort of service than just > formats. > > Rob > > From liu_x at lanl.gov Wed Mar 22 11:44:57 2006 From: liu_x at lanl.gov (Xiaoming Liu) Date: Wed Mar 22 11:43:45 2006 Subject: [gcs-pcs-list] Params: Empty vs not present In-Reply-To: <1143035943.15246.39.camel@helmsdeep> References: <20060321223017.GF3685@sildin.med.yale.edu> <1143035667.15246.33.camel@helmsdeep> <1143035943.15246.39.camel@helmsdeep> Message-ID: On Wed, 22 Mar 2006, Rob Sanderson wrote: > To add to the queue: > > Is an empty parameter the same as the parameter not being present? Before coming to the topic, I think I got some points of the philoshpy of Atom error processing. I even wrote a blog for it ;-) http://lxming.blogspot.com/2006/03/producer-and-consumer-economy-of-unapi.html Anyhow, I think we want to encourage as many as data providers by lowering the bar, one promising way is to define correct behaviour only, therefore both dumb and smart provider can survive; the complexity shifts to service because service _can_ afford it, service _can_ support many rules of error handling. Think about nasty HTML all around, and how much efforts browser takes to fix these errors. So I think unAPI should be silent about this, let data providers decide what to do best, and let service deals with these complexity. xiaoming > > For example: > > Is: unapi?uri=&format= > the same as: unapi? > > Is: unapi?uri=abc&format= > the same as: unapi?uri=abc > > If not, then what are the semantics of a null value in uri and format? > > Rob > From ksclarke at gmail.com Wed Mar 22 11:59:29 2006 From: ksclarke at gmail.com (Kevin S. Clarke) Date: Wed Mar 22 12:00:35 2006 Subject: [gcs-pcs-list] XML Schema In-Reply-To: References: <20060321223017.GF3685@sildin.med.yale.edu> <3557b8d0603211850v1ede622kfc42eec29a0c79b3@mail.gmail.com> <74C4754C-2891-499F-BF03-095CDB61A6EA@yale.edu> <3557b8d0603212134k640f9615w1979aa0f3470c718@mail.gmail.com> Message-ID: <3557b8d0603220859g6e16b977o66ca6124bbe85a11@mail.gmail.com> Hi all, I didn't really start paying attention to this thread until Robert's response, which quoted Eric (maybe not the full email?), so I may have missed something if there was more than just the perception aspect mentioned in the previous email. Here is a straw man schema for the formats XML as described on the revision 2 page ---------cut----------- #default namespace = "http://unapi.info/ns/0.2" #datatypes xsd = "http://www.w3.org/2001/XMLSchema-datatypes" start = element formats { element format { element name { text }, element type { text }, element docs { URL }?, element namespace_uri { URL }?, element schema_location { URL }? }+ } URL = text #URL = xsd:anyURI ------end cut------------- As you can see I commented out the namespace though I know it's been discussed here. I also followed ATOM's lead and didn't datatype the URLs thinking that would be the preference of this group (but left in that option too, commented out... you could also use a regexp pattern for URLs instead of the built in xsd:anyURI). I did this in .rnc (this can be easily converted to .rng or W3C schema if needed/desired). Btw, I tested against the XML example on the unapi revision 2 page and found that that actually isn't well formed :-) application/xml happens in two places Kevin On 3/22/06, Eric Hellman wrote: > an informative RNG would address the "perception" aspect of my concern. > > > At 12:34 AM -0500 3/22/06, Kevin S. Clarke wrote: > >Sure, be glad to... > > > >Kevin > > > >On 3/22/06, Daniel Chudnov wrote: > >> On Mar 21, 2006, at 9:50 PM, Kevin S. Clarke wrote: > >> > >> > If you need XML, I think you need something that says > >> > what it should look like. I'd suggest RELAX NG instead of W3C Schema > >> > though. > >> > >> Rather than all of us debating this, could you do this? It seems > >> sensible to consider including an informative RNG schema (as that's > >> what APP does); it will be easier to decide if it's already in front > >> of us. :) > >> > >> Starting with the spec as currently written would probably be best. > >> > > > Thanks, -Dan > > -- > > Eric Hellman, Director OCLC Openly > Informatics Division > eric@openly.com 2 Broad St., Suite 208 > tel 1-973-509-7800 fax 1-734-468-6216 Bloomfield, NJ 07003 > http://www.openly.com/1cate/ 1 Click Access To Everything > From ksclarke at gmail.com Wed Mar 22 12:07:45 2006 From: ksclarke at gmail.com (Kevin S. Clarke) Date: Wed Mar 22 12:08:48 2006 Subject: [gcs-pcs-list] XML Schema In-Reply-To: <3557b8d0603220859g6e16b977o66ca6124bbe85a11@mail.gmail.com> References: <20060321223017.GF3685@sildin.med.yale.edu> <3557b8d0603211850v1ede622kfc42eec29a0c79b3@mail.gmail.com> <74C4754C-2891-499F-BF03-095CDB61A6EA@yale.edu> <3557b8d0603212134k640f9615w1979aa0f3470c718@mail.gmail.com> <3557b8d0603220859g6e16b977o66ca6124bbe85a11@mail.gmail.com> Message-ID: <3557b8d0603220907w3d303ebeufc3494eda481efe6@mail.gmail.com> Oops, I see I missed the UNAPI?uri=URI option where there is a "uri (required, should be the requested URI)" The straw man schema for that (I'd actually move the format element out into a file that could be shared by both versions, but that is something I'll do if it is decided that having a schema is actually desired): ---------cut----------- #default namespace = "http://unapi.info/ns/0.2" datatypes xsd = "http://www.w3.org/2001/XMLSchema-datatypes" start = element formats { element uri { xsd:anyURI }, element format { element name { text }, element type { text }, element docs { URL }?, element namespace_uri { URL }?, element schema_location { URL }? }+ } URL = text #URL = xsd:anyURI ------end cut------------- From lists at hubmed.org Wed Mar 22 12:24:36 2006 From: lists at hubmed.org (Alf Eaton) Date: Wed Mar 22 12:28:04 2006 Subject: [gcs-pcs-list] Params: Empty vs not present In-Reply-To: References: <20060321223017.GF3685@sildin.med.yale.edu> <1143035667.15246.33.camel@helmsdeep> <1143035943.15246.39.camel@helmsdeep> Message-ID: <64503B21-2BD7-4B43-8B2C-1C1FBA456E2E@hubmed.org> On 22 Mar 2006, at 10:48, Mike Rylander wrote: > On 3/22/06, Rob Sanderson wrote: >> To add to the queue: >> >> Is an empty parameter the same as the parameter not being present? >> >> For example: >> >> Is: unapi?uri=&format= >> the same as: unapi? >> >> Is: unapi?uri=abc&format= >> the same as: unapi?uri=abc > > I think, for simplicity's sake, they are the same unless there's a > suggested semantic meaning (which there is not in the OP). But it's a > good point to bring up. :) > Yes, I think they would be the same (I think in Perl's CGI.pm both would pass through 'format' as undefined, at least). They're perhaps not equivalent as URIs, but that's not important here. alf. From daniel.chudnov at yale.edu Thu Mar 23 08:44:16 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Thu Mar 23 08:44:18 2006 Subject: [gcs-pcs-list] XML Schema In-Reply-To: <3557b8d0603220859g6e16b977o66ca6124bbe85a11@mail.gmail.com> References: <20060321223017.GF3685@sildin.med.yale.edu> <3557b8d0603211850v1ede622kfc42eec29a0c79b3@mail.gmail.com> <74C4754C-2891-499F-BF03-095CDB61A6EA@yale.edu> <3557b8d0603212134k640f9615w1979aa0f3470c718@mail.gmail.com> <3557b8d0603220859g6e16b977o66ca6124bbe85a11@mail.gmail.com> Message-ID: <20060323134416.GA12311@sildin.med.yale.edu> Kevin S. Clarke wrote, on Wed, Mar 22, 2006 at 11:59:29AM -0500: > > Btw, I tested against the XML example on the unapi revision 2 page and > found that that actually isn't well formed :-) > > application/xml happens in two places Fixed, thanks! And, you win a free t-shirt. T-shirts also go to others who catch typos or other editorial malfeasance. :) Now, to design a t-shirt... -dc (in a mtg and on a train all day) -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From daniel.chudnov at yale.edu Mon Mar 27 10:54:09 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Mon Mar 27 10:55:23 2006 Subject: [gcs-pcs-list] unAPI issue: 404 and formats list In-Reply-To: References: <20060321224344.GH3685@sildin.med.yale.edu> Message-ID: <46FF3A43-7B41-40A6-8959-2326F9230D1D@yale.edu> On Mar 21, 2006, at 10:26 PM, Xiaoming Liu wrote: > +1 My initial post suggested no changes, and there were two +1s, and no other comments. Issue closed, with no changes, for now. -Dan From daniel.chudnov at yale.edu Mon Mar 27 10:59:32 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Mon Mar 27 11:00:41 2006 Subject: [gcs-pcs-list] unAPI issue: vary unapi-uri class name? Message-ID: <63A93F61-DF4E-4340-9971-0DF20E0B7FA7@yale.edu> An earlier message from Eric suggested the possibility of varying unAPI class names and target servers to help with the multiple- provider issue, e.g. : and in the body: PMID 12345678 ISBN 123456789X ...which is copied (with incomplete URIs in titles :) from the message at: http://cipolo.med.yale.edu/pipermail/gcs-pcs-list/2006-March/ 000491.html This seems complicated, especially if it means we have to take on a role of registering unapi class name variations. It also means more of a burden on publishers to specify these options according to identifier types. But... any takers, still? -Dan From daniel.chudnov at yale.edu Mon Mar 27 11:19:33 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Mon Mar 27 11:20:40 2006 Subject: [gcs-pcs-list] unAPI issue: rename root node? In-Reply-To: <20060321223017.GF3685@sildin.med.yale.edu> References: <20060321223017.GF3685@sildin.med.yale.edu> Message-ID: This thread broke down rather quickly into something we cannot decide on. Some quick observations: - If you want ZeeRex / Z39.92, use it. We're not duplicating it in unAPI. - If you want paste, use the Atom Publishing Protocol, or the new Live Clipboard spec, until you can prove that these are insufficient. We're not working on it and it's not a goal of unAPI version 1. - "Clarify the relationship between UNAPI and UNAPI?uri=URI" is a little further down the to-do list. - Refactoring the spec to be less redundant about the formats response is a little further down the to-do list. - I agree with Xiaoming's insight about lowering the bar for data providers. - Kevin's informative schema is useful. I'm curious to see if we can resolve all this with some compromises. I'll post separately with a proposed set of changes for a vote. -Dan From daniel.chudnov at yale.edu Mon Mar 27 11:28:36 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Mon Mar 27 11:29:42 2006 Subject: [gcs-pcs-list] unAPI vote: changes to formats response Message-ID: Please vote up or down on both changes, together, as one unit. - Leave the root node of the formats response named "formats", but add a namespace, such as "http://unapi.info/ns/1" (for unAPI version 1). It's easy to add to the output response and allows for cleaner remixing into other structures. - Add Kevin's schema to the spec as an informative appendix, with namespace, but without datatypes. (To resolve, though: should it be RNG? And, shouldn't the URI element be optional?) That's all. :) -Dan From daniel.chudnov at yale.edu Mon Mar 27 11:32:56 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Mon Mar 27 11:34:03 2006 Subject: [gcs-pcs-list] unAPI issue: close reading/editing. Message-ID: It's down near the bottom of the to-do list, but now's a good time to raise it: we need to edit the spec. There are awkward phrases here and there, and areas were prose can be tighter or flow better. Please use this thread to suggest any changes to grammar, phrasing, wording, or flow which might help to make the spec tighter, simpler, or more readable (ignoring, in this thread, substantive changes to the meat of the spec itself). Note also that rewriting the intro (currently, "Background" and "Objectives") is on the to-do list, so let's make that fair game here too. Thanks, -Dan From ross.singer at library.gatech.edu Mon Mar 27 11:39:34 2006 From: ross.singer at library.gatech.edu (Ross Singer) Date: Mon Mar 27 11:41:47 2006 Subject: [gcs-pcs-list] unAPI issue: vary unapi-uri class name? In-Reply-To: <63A93F61-DF4E-4340-9971-0DF20E0B7FA7@yale.edu> References: <63A93F61-DF4E-4340-9971-0DF20E0B7FA7@yale.edu> Message-ID: <23b83f160603270839m3e63b600k2b3700f5fba5044f@mail.gmail.com> -1 On 3/27/06, Daniel Chudnov wrote: > > An earlier message from Eric suggested the possibility of varying > unAPI class names and target servers to help with the multiple- > provider issue, e.g. : > > href="http://example.com/unapi/" /> > href="http://isbn.example.org/unapi" /> > > and in the body: > PMID 12345678 > ISBN > 123456789X > > ...which is copied (with incomplete URIs in titles :) from the > message at: > > http://cipolo.med.yale.edu/pipermail/gcs-pcs-list/2006-March/ > 000491.html > > > This seems complicated, especially if it means we have to take on a > role of registering unapi class name variations. It also means more > of a burden on publishers to specify these options according to > identifier types. > > But... any takers, still? > > -Dan > _______________________________________________ > gcs-pcs-list mailing list > gcs-pcs-list@cipolo.med.yale.edu > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://cipolo.med.yale.edu/pipermail/gcs-pcs-list/attachments/20060327/b5cf30a0/attachment.htm From liu_x at lanl.gov Mon Mar 27 12:50:19 2006 From: liu_x at lanl.gov (Xiaoming Liu) Date: Mon Mar 27 12:48:56 2006 Subject: [gcs-pcs-list] unAPI issue: vary unapi-uri class name? In-Reply-To: <63A93F61-DF4E-4340-9971-0DF20E0B7FA7@yale.edu> References: <63A93F61-DF4E-4340-9971-0DF20E0B7FA7@yale.edu> Message-ID: -1 On Mon, 27 Mar 2006, Daniel Chudnov wrote: > An earlier message from Eric suggested the possibility of varying unAPI class > names and target servers to help with the multiple-provider issue, e.g. : > > href="http://example.com/unapi/" /> > href="http://isbn.example.org/unapi" /> > > and in the body: > PMID 12345678 > ISBN 123456789X > > ...which is copied (with incomplete URIs in titles :) from the message at: > > http://cipolo.med.yale.edu/pipermail/gcs-pcs-list/2006-March/000491.html > > > This seems complicated, especially if it means we have to take on a role of > registering unapi class name variations. It also means more of a burden on > publishers to specify these options according to identifier types. > > But... any takers, still? > > -Dan > _______________________________________________ > gcs-pcs-list mailing list > gcs-pcs-list@cipolo.med.yale.edu > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list From liu_x at lanl.gov Mon Mar 27 12:57:29 2006 From: liu_x at lanl.gov (Xiaoming Liu) Date: Mon Mar 27 12:56:06 2006 Subject: [gcs-pcs-list] unAPI vote: changes to formats response In-Reply-To: References: Message-ID: On Mon, 27 Mar 2006, Daniel Chudnov wrote: > Please vote up or down on both changes, together, as one unit. > > - Leave the root node of the formats response named "formats", but add a > namespace, such as > "http://unapi.info/ns/1" (for unAPI version 1). It's easy to add to the > output response > and allows for cleaner remixing into other structures. +1 > > - Add Kevin's schema to the spec as an informative appendix, with namespace, > but without > datatypes. > > (To resolve, though: should it be RNG? And, shouldn't the URI element be > optional?) +1, I think whether to use URI element is in todo list? xiaoming > > > That's all. :) > > -Dan > _______________________________________________ > gcs-pcs-list mailing list > gcs-pcs-list@cipolo.med.yale.edu > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list From azaroth at liverpool.ac.uk Mon Mar 27 14:50:55 2006 From: azaroth at liverpool.ac.uk (Robert Sanderson) Date: Mon Mar 27 14:54:09 2006 Subject: [gcs-pcs-list] unAPI issue: vary unapi-uri class name? In-Reply-To: <63A93F61-DF4E-4340-9971-0DF20E0B7FA7@yale.edu> References: <63A93F61-DF4E-4340-9971-0DF20E0B7FA7@yale.edu> Message-ID: >An earlier message from Eric suggested the possibility of varying >unAPI class names and target servers to help with the multiple- >provider issue, e.g. : -1 Rob From azaroth at liverpool.ac.uk Mon Mar 27 14:55:22 2006 From: azaroth at liverpool.ac.uk (Robert Sanderson) Date: Mon Mar 27 14:55:25 2006 Subject: [gcs-pcs-list] unAPI issue: rename root node? In-Reply-To: References: <20060321223017.GF3685@sildin.med.yale.edu> Message-ID: >This thread broke down rather quickly into something we cannot decide >on. Some quick observations: > - If you want ZeeRex / Z39.92, use it. We're not duplicating it in >unAPI. You are, in the formats response, in that formats is directly equivalent to explain/schemaInfo. But I think that the response for the unapi? is on the to-do list, with respect to introspection, so we'll wait till then to discuss it. > - I agree with Xiaoming's insight about lowering the bar for data >providers. Namespaces don't lower the bar for many people at the level of bar we're talking about. Derek Lane reported with respect to OpenSearch vs SRU, that apart from the semantics of CQL, the hardest thing to implement for SRU was the namespaces. Which isn't to say that I disagree with Xiaoming that namespaces are a possible way to extend the results, but it's something to consider ... either we want easy, or we want extensible, but extensibility will always make things less easy and vice versa. Rob From azaroth at liverpool.ac.uk Mon Mar 27 14:56:12 2006 From: azaroth at liverpool.ac.uk (Robert Sanderson) Date: Mon Mar 27 14:56:26 2006 Subject: [gcs-pcs-list] unAPI vote: changes to formats response In-Reply-To: References: Message-ID: > - Leave the root node of the formats response named "formats", but >add a namespace, such as > "http://unapi.info/ns/1" (for unAPI version 1). It's easy to add >to the output response > and allows for cleaner remixing into other structures. -1 > - Add Kevin's schema to the spec as an informative appendix, with >namespace, but without > datatypes. -1 Rob From mrylander at gmail.com Mon Mar 27 15:09:21 2006 From: mrylander at gmail.com (Mike Rylander) Date: Mon Mar 27 15:10:27 2006 Subject: [gcs-pcs-list] unAPI issue: vary unapi-uri class name? In-Reply-To: <63A93F61-DF4E-4340-9971-0DF20E0B7FA7@yale.edu> References: <63A93F61-DF4E-4340-9971-0DF20E0B7FA7@yale.edu> Message-ID: -1 On 3/27/06, Daniel Chudnov wrote: > An earlier message from Eric suggested the possibility of varying > unAPI class names and target servers to help with the multiple- > provider issue, e.g. : > > href="http://example.com/unapi/" /> > href="http://isbn.example.org/unapi" /> > > and in the body: > PMID 12345678 > ISBN > 123456789X > > ...which is copied (with incomplete URIs in titles :) from the > message at: > > http://cipolo.med.yale.edu/pipermail/gcs-pcs-list/2006-March/ > 000491.html > > > This seems complicated, especially if it means we have to take on a > role of registering unapi class name variations. It also means more > of a burden on publishers to specify these options according to > identifier types. > > But... any takers, still? > > -Dan > _______________________________________________ > gcs-pcs-list mailing list > gcs-pcs-list@cipolo.med.yale.edu > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list > -- Mike Rylander mrylander@gmail.com GPLS -- PINES Development Database Developer http://open-ils.org From bdarcus.lists at gmail.com Mon Mar 27 15:49:47 2006 From: bdarcus.lists at gmail.com (Bruce D'Arcus) Date: Mon Mar 27 15:50:55 2006 Subject: [gcs-pcs-list] formats schema Message-ID: HI All, Just joined the list, after seeing a bit of the formats schema discussion. I haven't thought about this issue deeply, but on looking at the XML, I am left with some obvious questions: 1) why use elements for the content, when the description suggests simple attributes are fine: > format (can repeat) Obviously this should be an element, but the rest assume no more than one of a given value. >> name (required; shorthand human-readable format name) >> type (required; should be a valid, accepted mime-type) >> docs (optional; should consist of a single url) >> namespace_uri (optional; should consist of a single url) >> schema_location (optional; should consist of a single url) 2) I dislike the last option. I think you ought to ditch it for now, unless you want to rethink the whole thing. Consider, for example, a format that has more than one schema: say a normative RNG version, and an XSD. If you want to capture that, then you need to consider more complicated markup, a la: And it's unclear to me what value this has in any case given the use cases. A namespace uri is important because it provides a unique id, but why would anyone care aboutt the schema location? 3) The namespace issue: I tend to think any new XML language ought to be namespaced, though Rob may be right that simpler is better. When you deal with attributes, for example, things start to get confusing with namespaces. And I can't imagine why one would want to "remix" this sort of format content anyway (?). If you want to do that, then might as well do RDF. 4) I'm not sure why there's anything wrong with datatyping; I'd say it's a good thing myself. In any case, my suggestion would then modify Kevin's strawman to end up with: # I guess I'd lean towards leaving off the namespace datatypes xsd = "http://www.w3.org/2001/XMLSchema-datatypes" start = element formats { attribute uri { xsd:anyURI }, element format { attribute name { text }, # might be worth controlling values of type attribute type { text }, attribute docs { xsd:anyURI }?, attribute ns { xsd:anyURI }? }+ } I wonder if it wouldn't make sense to have the root be "service" (or something similar) and have "formats" as a child of that? Bruce From azaroth at liverpool.ac.uk Mon Mar 27 16:03:31 2006 From: azaroth at liverpool.ac.uk (Robert Sanderson) Date: Mon Mar 27 16:06:46 2006 Subject: [gcs-pcs-list] formats schema In-Reply-To: References: Message-ID: Hi Bruce :) >1) why use elements for the content, when the description suggests >simple attributes are fine: It's much harder to extend an attribute, compared to extending an element. Other than that, it's a pretty arbitrary decision, IMO. >>> schema_location (optional; should consist of a single url) >2) I dislike the last option. I think you ought to ditch it for now, >unless you want to rethink the whole thing. >And it's unclear to me what value this has in any case given the use >cases. A namespace uri is important because it provides a unique id, >but why would anyone care aboutt the schema location? Because namespace URI does not provide a unique id for a *schema* it provides it for a group of elements which may or may not be part of a schema with that namespace. Schema location does not provide a unique id for a schema, because schema location is not unique. I can copy a schema and change the location to my local copy. In fact there is nothing apart from an arbitrarily assigned identifier for a schema that says, for example, 'simple dublin core schema'. :( For example, mods and modscollection require different processing, but are part of the same xsd schema file and have the same namespace. IMO, to fully uniquely identify a schema, you need a registry. At which point, I say (for unapi) screw it, just have a name and a human readable link to documentation describing the format and be done. >3) The namespace issue: > >I tend to think any new XML language ought to be namespaced, though >Rob may be right that simpler is better. When you deal with >attributes, for example, things start to get confusing with >namespaces. And I can't imagine why one would want to "remix" this >sort of format content anyway (?). If you want to do that, then might >as well do RDF. It depends a lot on the aim. My understanding is that the aim is to create an API so simple that you can implement it completely and correctly within an hour or two. (Compared to say OAI, which is a day or two and SRU which is probably a week or two) Anything that adds weight, adds time. Namespaces add weight. Ergo... Rob From bdarcus.lists at gmail.com Mon Mar 27 16:38:33 2006 From: bdarcus.lists at gmail.com (Bruce D'Arcus) Date: Mon Mar 27 16:39:36 2006 Subject: [gcs-pcs-list] formats schema In-Reply-To: References: Message-ID: On 3/27/06, Robert Sanderson wrote: > >1) why use elements for the content, when the description suggests > >simple attributes are fine: > > It's much harder to extend an attribute, compared to extending an > element. True. Perhaps worth deciding now if that's important, because OTOH, the attribute content model is fundamentally unordered, while elements are ordered. The latter adds a layer of complexity for implementers, particularly when you have braindead schema languages like XML Schema that do not understand the notion of unordered element content. E.g. the schema I posted can be losslessly converted to XSD, while doing the same with an element-based model would require that the order be signficant. > >>> schema_location (optional; should consist of a single url) > >2) I dislike the last option. I think you ought to ditch it for now, > >unless you want to rethink the whole thing. > >And it's unclear to me what value this has in any case given the use > >cases. A namespace uri is important because it provides a unique id, > >but why would anyone care aboutt the schema location? > > Because namespace URI does not provide a unique id for a *schema* it > provides it for a group of elements which may or may not be part of a > schema with that namespace. > Schema location does not provide a unique id for a schema, because > schema location is not unique. I can copy a schema and change the > location to my local copy. Right .. this a big can-o-worms this spec ought to leave alone IMHO. There is huge controversy about this issue. A "version" option might cover some of the same ground? For comparison, here's my locating file for nxml. Bruce From liu_x at lanl.gov Mon Mar 27 22:30:54 2006 From: liu_x at lanl.gov (Xiaoming Liu) Date: Mon Mar 27 22:29:32 2006 Subject: [gcs-pcs-list] formats schema In-Reply-To: References: Message-ID: Bruce, Just some background information. On Mon, 27 Mar 2006, Bruce D'Arcus wrote: > 2) I dislike the last option. I think you ought to ditch it for now, > unless you want to rethink the whole thing. > > Consider, for example, a format that has more than one schema: say a > normative RNG version, and an XSD. If you want to capture that, then > you need to consider more complicated markup, a la: > > > > And it's unclear to me what value this has in any case given the use > cases. A namespace uri is important because it provides a unique id, > but why would anyone care aboutt the schema location? This is already in Dan's todo list. http://curtis.med.yale.edu/dchud/unapi/todo-latest.txt I agree with your analysis. > > 3) The namespace issue: > > I tend to think any new XML language ought to be namespaced, though > Rob may be right that simpler is better. When you deal with > attributes, for example, things start to get confusing with > namespaces. And I can't imagine why one would want to "remix" this > sort of format content anyway (?). If you want to do that, then might > as well do RDF. This was argued before: http://cipolo.med.yale.edu/pipermail/gcs-pcs-list/2006-March/000655.html I see benefits for extensibility. IMO, RDF and XML extensibility are two different mechanisms. > > 4) I'm not sure why there's anything wrong with datatyping; I'd say > it's a good thing myself. > > In any case, my suggestion would then modify Kevin's strawman to end up with: > > # I guess I'd lean towards leaving off the namespace > datatypes xsd = "http://www.w3.org/2001/XMLSchema-datatypes" > > start = > element formats { > attribute uri { xsd:anyURI }, > element format { > attribute name { text }, > # might be worth controlling values of type > attribute type { text }, I think the spec says "should be a valid, accepted mime-type". > attribute docs { xsd:anyURI }?, > attribute ns { xsd:anyURI }? > }+ > } > > I wonder if it wouldn't make sense to have the root be "service" (or > something similar) and have "formats" as a child of that? Could you elaborate more about what you think other "services" should be added? otherwise I don't see benefits of another layer. xiaoming > > Bruce > _______________________________________________ > gcs-pcs-list mailing list > gcs-pcs-list@cipolo.med.yale.edu > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list > From liu_x at lanl.gov Mon Mar 27 23:12:48 2006 From: liu_x at lanl.gov (Xiaoming Liu) Date: Mon Mar 27 23:11:24 2006 Subject: [gcs-pcs-list] formats schema In-Reply-To: References: Message-ID: On Mon, 27 Mar 2006, Bruce D'Arcus wrote: > On 3/27/06, Robert Sanderson wrote: > >>> 1) why use elements for the content, when the description suggests >>> simple attributes are fine: >> >> It's much harder to extend an attribute, compared to extending an >> element. > > True. Perhaps worth deciding now if that's important, because OTOH, > the attribute content model is fundamentally unordered, while elements > are ordered. The latter adds a layer of complexity for implementers, > particularly when you have braindead schema languages like XML Schema > that do not understand the notion of unordered element content. > > E.g. the schema I posted can be losslessly converted to XSD, while > doing the same with an element-based model would require that the > order be signficant. I think the schema proposal largely follows Atom (rfc4287) style. A RELAX NG schema is suggested as a "non-normative" appendix. In this case I am not sure how relevant of constructing an equivalent xsd. I agree order or not should be somewhat explicit, and perhaps rfc4287 section 6.2/6.4 can be applicable to FAQ if we indeed choose extensibility. xiaoming From bdarcus.lists at gmail.com Tue Mar 28 07:43:07 2006 From: bdarcus.lists at gmail.com (Bruce D'Arcus) Date: Tue Mar 28 07:44:12 2006 Subject: [gcs-pcs-list] formats schema In-Reply-To: References: Message-ID: On 3/27/06, Xiaoming Liu wrote: > Just some background information. Thanks. > > 3) The namespace issue: > > > > I tend to think any new XML language ought to be namespaced, though > > Rob may be right that simpler is better. When you deal with > > attributes, for example, things start to get confusing with > > namespaces. And I can't imagine why one would want to "remix" this > > sort of format content anyway (?). If you want to do that, then might > > as well do RDF. > > This was argued before: > http://cipolo.med.yale.edu/pipermail/gcs-pcs-list/2006-March/000655.html OK, I see. > I see benefits for extensibility. IMO, RDF and XML extensibility are two > different mechanisms. The problem is there is no XML model for extensibility :-) It would be easy enough to make the format RDF and get it's built in extensibility. This, for example, is valid RDF: > > I wonder if it wouldn't make sense to have the root be "service" (or > > something similar) and have "formats" as a child of that? > > Could you elaborate more about what you think other "services" should be > added? otherwise I don't see benefits of another layer. Because the uri is not related to any "formats". The uri is associated with a service, which provides formats. Removing this discussion from the realm of XML and RDF, just think of how you'd create a class that represented this? Would you call it "Formats" and then have a uri attribute and a "contents" attribute that was an array, or would you instead call it "Service" (or whatever else you think better describes it) and have an attribute called "formats"? The first would result in code like: for format in x.contents: print format.name ... while the second in: for format in x.formats: print format.name Bruce From liu_x at lanl.gov Tue Mar 28 08:22:26 2006 From: liu_x at lanl.gov (Xiaoming Liu) Date: Tue Mar 28 08:21:04 2006 Subject: [gcs-pcs-list] formats schema In-Reply-To: References: Message-ID: On Tue, 28 Mar 2006, Bruce D'Arcus wrote: > > The problem is there is no XML model for extensibility :-) > while XML might be lacking offical model for extensibiliy, there are also good and elegant practices. e.g. see section 6.4 of rfc4287. 6.4. Extension Elements Atom allows foreign markup anywhere in an Atom document, except where it is explicitly forbidden. Child elements of atom:entry, atom:feed, atom:source, and Person constructs are considered Metadata elements and are described below. Child elements of Person constructs are considered to apply to the construct. The role of other foreign markup is undefined by this specification. > It would be easy enough to make the format RDF and get it's built in > extensibility. This, for example, is valid RDF: I am afraind RDF will scare people away ;-) in the very early version of unAPI formats response is based on JSON, so unAPI is not XML centric and it just happends to choose to use XML as response format. > >>> I wonder if it wouldn't make sense to have the root be "service" (or >>> something similar) and have "formats" as a child of that? >> >> Could you elaborate more about what you think other "services" should be >> added? otherwise I don't see benefits of another layer. > > Because the uri is not related to any "formats". The uri is associated > with a service, which provides formats. In the todo list there is an item of removing URI from response. If it is getting through your concern might be addressed :-) I advocate removing URI from response and this discussion may add another reason for it. xiaoming > > Removing this discussion from the realm of XML and RDF, just think of > how you'd create a class that represented this? Would you call it > "Formats" and then have a uri attribute and a "contents" attribute > that was an array, or would you instead call it "Service" (or whatever > else you think better describes it) and have an attribute called > "formats"? > > The first would result in code like: > > for format in x.contents: > print format.name > > ... while the second in: > > for format in x.formats: > print format.name > > Bruce > -- Xiaoming From bdarcus.lists at gmail.com Tue Mar 28 08:46:56 2006 From: bdarcus.lists at gmail.com (Bruce D'Arcus) Date: Tue Mar 28 08:48:02 2006 Subject: [gcs-pcs-list] formats schema In-Reply-To: References: Message-ID: On 3/28/06, Xiaoming Liu wrote: > while XML might be lacking offical model for extensibiliy, there are also > good and elegant practices. e.g. see section 6.4 of rfc4287. > > 6.4. Extension Elements > > Atom allows foreign markup anywhere in an Atom document, except where > it is explicitly forbidden. Child elements of atom:entry, atom:feed, > atom:source, and Person constructs are considered Metadata elements > and are described below. Child elements of Person constructs are > considered to apply to the construct. The role of other foreign > markup is undefined by this specification. I'd call this fairly limited myself. Granted, though, for this use case it might work. > > It would be easy enough to make the format RDF and get it's built in > > extensibility. This, for example, is valid RDF: > > I am afraind RDF will scare people away ;-) in the very early > version of unAPI formats response is based on JSON, so unAPI is not XML > centric ... Neither is RDF. But I think my argument stands regardless of the technology. > >>> I wonder if it wouldn't make sense to have the root be "service" (or > >>> something similar) and have "formats" as a child of that? > >> > >> Could you elaborate more about what you think other "services" should be > >> added? otherwise I don't see benefits of another layer. > > > > Because the uri is not related to any "formats". The uri is associated > > with a service, which provides formats. > > In the todo list there is an item of removing URI from response. If > it is getting through your concern might be addressed :-) I advocate > removing URI from response and this discussion may add another reason for > it. I'm not seeing that in the todo (?). Bruce From leigh at ldodds.com Tue Mar 28 08:49:00 2006 From: leigh at ldodds.com (Leigh Dodds) Date: Tue Mar 28 08:53:03 2006 Subject: [gcs-pcs-list] formats schema In-Reply-To: References: Message-ID: <44293ECC.40005@ldodds.com> Xiaoming Liu wrote: > On Tue, 28 Mar 2006, Bruce D'Arcus wrote: > >> >> The problem is there is no XML model for extensibility :-) >> > > while XML might be lacking offical model for extensibiliy, there are > also good and elegant practices. e.g. see section 6.4 of rfc4287. It's worth noting that those "good and elegant practices" are there as a result of RDF folk pushing the Atom folk to consider extensibility. If you take XML, and say that those practices (e.g. child elements qualify their parent in some way, extra elements can be littered everywhere) as a formal part of the model. Then, you've pretty much got RDF. But thats a debate for another day :) L. -- Home: http://www.ldodds.com | "Simplicity is the ultimate Blog: http://www.ldodds.com/blog | sophistication" -- Leonardo da Vinci From leigh at ldodds.com Tue Mar 28 08:54:43 2006 From: leigh at ldodds.com (Leigh Dodds) Date: Tue Mar 28 08:55:05 2006 Subject: [gcs-pcs-list] format=FORMAT Message-ID: <44294023.2090807@ldodds.com> A question, mainly to check an assumption that I may be inadvertantly making when reading the spec and considering implementations: Is there an expectation/intention that the values for FORMAT will be standardised? I've seen discussion that recommends that FORMAT be a mimetype, but thats not sufficient for all cases (and the formats schema acknowledges this with additional elements that qualify each format). Another way to ask the same question is by considering the whether the following is an expected use case: Given a base URL for an unapi service, should a system be able to programmatically construct the ?uri=URI&format=FORMAT request? If the answer is yes, then we need clear unambiguous guidance on what goes in FORMAT. If the answer is no, client should be expected to do a ?uri=URI request first, or follow an embedded unapi link, then we don't In fact, if the answer is no, then we could do away for the format parameter entirely. Cheers, L. -- Home: http://www.ldodds.com | "Simplicity is the ultimate Blog: http://www.ldodds.com/blog | sophistication" -- Leonardo da Vinci From leigh at ldodds.com Tue Mar 28 09:11:38 2006 From: leigh at ldodds.com (Leigh Dodds) Date: Tue Mar 28 09:15:40 2006 Subject: [gcs-pcs-list] Links in metadata formats document In-Reply-To: <20060310215705.GM18260@sildin.med.yale.edu> References: <4411E9C7.10603@ldodds.com> <20060310215705.GM18260@sildin.med.yale.edu> Message-ID: <4429441A.2030006@ldodds.com> Daniel Chudnov wrote: > Leigh Dodds wrote, on Fri, Mar 10, 2006 at 09:04:07PM +0000: >> This document is basically an index document that lists all >> formats available for a given URI. The client can then construct >> ?format=FORMAT calls using one of the named formats. >> >> I'd like to suggest that the format include a link to the relevant API >> call also, e.g: > ... >> The name then becomes just a useful label, e.g. for display to a user. A >> client application need only select the appropriate link value for a >> subsequent GET request. > > We have considered this before; the name already is a useful label > for display to a user, and an appropriate param value. How does this > suggestion change that? Currently the name is actually pulling double duty: its a label, in that it helps to disambiguate between formats in a ?uri=URI request. It's also an identifier as its naming a particular format in a ?uri=URI&format=FORMAT request. Depending on what features we want from the API, we can clarify that role somewhat. Will follow up on a separate thread. L. -- Home: http://www.ldodds.com | "Simplicity is the ultimate Blog: http://www.ldodds.com/blog | sophistication" -- Leonardo da Vinci From liu_x at lanl.gov Tue Mar 28 09:30:22 2006 From: liu_x at lanl.gov (Xiaoming Liu) Date: Tue Mar 28 09:28:57 2006 Subject: [gcs-pcs-list] formats schema In-Reply-To: References: Message-ID: On Tue, 28 Mar 2006, Bruce D'Arcus wrote: >>>> Could you elaborate more about what you think other "services" should be >>>> added? otherwise I don't see benefits of another layer. >>> >>> Because the uri is not related to any "formats". The uri is associated >>> with a service, which provides formats. >> >> In the todo list there is an item of removing URI from response. If >> it is getting through your concern might be addressed :-) I advocate >> removing URI from response and this discussion may add another reason for >> it. > > I'm not seeing that in the todo (?). > My bad, I thought it was there, although "Consider refactoring the formats specification to remove redundancy in UNAPI and UNAPI?uri=URI" is sort of related. May I ask Dan to kindly put this issue in the queue? -- Xiaoming From azaroth at liverpool.ac.uk Tue Mar 28 09:37:47 2006 From: azaroth at liverpool.ac.uk (Rob Sanderson) Date: Tue Mar 28 09:41:05 2006 Subject: [gcs-pcs-list] format=FORMAT In-Reply-To: <44294023.2090807@ldodds.com> References: <44294023.2090807@ldodds.com> Message-ID: <1143556667.9492.20.camel@helmsdeep> On Tue, 2006-03-28 at 14:54 +0100, Leigh Dodds wrote: > Is there an expectation/intention that the values for FORMAT > will be standardised? My understanding is that the values for format are not necessarily standardised, but might be. (Compare to URI vs Identifier, but that's another debate :) ) > Given a base URL for an unapi service, should a system be able > to programmatically construct the ?uri=URI&format=FORMAT request? Yes, it is one of the values specified in the ?uri=URI format/name instances. It may be enlightening to look at the ZeeRex/Z39.92 schemaInfo section to which formats is practically identical: Simple Dublin Core This provides a globally unique identifier, a local name and the location from which you can retrieve the schema, plus zero or more human readable title options. The obvious issue is that what we have in unAPI is not just XML schemas, we have many possible types of file format, each with many possible 'schema'. ZeeRex handles this with an alternative with Z39.50 speak: Simple Dublin Core And repeat recordSyntax for different file types. (In the Z39.50 example above, the identifier is an OID, but the schema does not require this to be so outside of describing Z39.50... it could be a mime type, for example) So you could have 3 different jpegs, 2 different XML representations and PDF. Hope that helps :) Rob -- Dr Robert Sanderson Dept of Computer Science, University of Liverpool Home: http://www.csc.liv.ac.uk/~azaroth/ Cheshire: http://www.cheshire3.org/ From leigh at ldodds.com Tue Mar 28 09:50:50 2006 From: leigh at ldodds.com (Leigh Dodds) Date: Tue Mar 28 09:55:02 2006 Subject: [gcs-pcs-list] format=FORMAT In-Reply-To: <1143556667.9492.20.camel@helmsdeep> References: <44294023.2090807@ldodds.com> <1143556667.9492.20.camel@helmsdeep> Message-ID: <44294D4A.9040002@ldodds.com> Rob Sanderson wrote: > My understanding is that the values for format are not necessarily > standardised, but might be. > (Compare to URI vs Identifier, but that's another debate :) ) Yes, thats what I expected. >> Given a base URL for an unapi service, should a system be able >> to programmatically construct the ?uri=URI&format=FORMAT request? > > Yes, it is one of the values specified in the ?uri=URI format/name > instances. But it didn't be. If the response format included a URL from which the desired format can be retrieved then you don't actually need FORMAT here -- it becomes an implementation detail of a given service. By providing a URL in the response (or as an embedded link), you've removed the need to include the details of how to construct that URL programmatically(*) format=FORMAT is only required if you're coming at a unapi service without any previous interactions. So, by adding a single element to the format option we can cut down on the "complexity" of the API design and specification. And the "format" element in the response format becomes purely a human readable label. But you do lose the ability to support that particular use case (coming at the API without previous interactions), which is why I posed the question as whether thats a direct goal. Cheers, L. (*) this is the essence of RESTful design: opaque URLs; hypermedia as the engine of application state. -- Home: http://www.ldodds.com | "Simplicity is the ultimate Blog: http://www.ldodds.com/blog | sophistication" -- Leonardo da Vinci From azaroth at liverpool.ac.uk Tue Mar 28 10:03:09 2006 From: azaroth at liverpool.ac.uk (Rob Sanderson) Date: Tue Mar 28 10:06:33 2006 Subject: [gcs-pcs-list] format=FORMAT In-Reply-To: <44294D4A.9040002@ldodds.com> References: <44294023.2090807@ldodds.com> <1143556667.9492.20.camel@helmsdeep> <44294D4A.9040002@ldodds.com> Message-ID: <1143558189.9492.24.camel@helmsdeep> On Tue, 2006-03-28 at 15:50 +0100, Leigh Dodds wrote: > >> Given a base URL for an unapi service, should a system be able > >> to programmatically construct the ?uri=URI&format=FORMAT request? > > Yes, it is one of the values specified in the ?uri=URI format/name > > instances. > But it didn't be. If the response format included a URL from which > the desired format can be retrieved then you don't actually need > FORMAT here -- it becomes an implementation detail of a given > service. By providing a URL in the response (or as an embedded link), > you've removed the need to include the details of how to construct > that URL programmatically(*) Great. So for every time you want to do something you need to make two calls to the webserver. I'm sure that'll go down well with big databases ;) > format=FORMAT is only required if you're coming at a unapi service > without any previous interactions. Which will be the majority of the time if usage is similar to more complicated apis such as SRU, OpenURL and OAI. > So, by adding a single element to the format option we can cut > down on the "complexity" of the API design and specification. And > the "format" element in the response format becomes purely a human > readable label. So instead of parsing out the name and putting that into a trivially constructed url, you parse out a url and send it intact. And people are talking about RDF and XML namespaces? There's a lot of complexity that can go before this little bit. :) Rob -- Dr Robert Sanderson Dept of Computer Science, University of Liverpool Home: http://www.csc.liv.ac.uk/~azaroth/ Cheshire: http://www.cheshire3.org/ From leigh at ldodds.com Tue Mar 28 10:12:07 2006 From: leigh at ldodds.com (Leigh Dodds) Date: Tue Mar 28 10:16:23 2006 Subject: [gcs-pcs-list] format=FORMAT In-Reply-To: <1143558189.9492.24.camel@helmsdeep> References: <44294023.2090807@ldodds.com> <1143556667.9492.20.camel@helmsdeep> <44294D4A.9040002@ldodds.com> <1143558189.9492.24.camel@helmsdeep> Message-ID: <44295247.4050604@ldodds.com> Rob Sanderson wrote: > Great. So for every time you want to do something you need to make two > calls to the webserver. I'm sure that'll go down well with big > databases ;) Thats not what I was suggesting. I'm just curious about the use cases. E.g. whether database publishers will be embedding unapi links in their abstract or other pages. And this will be the primary source of unapi linking, supporting interactions such as cut-and-paste Or whether unapi services will be used similar to OAI, etc as you suggested, and may be a way to harvest ("by proxy") metadata from other services. Its not been clear to me from the discussion whether either or both were the main focus. "Cut and Paste" seems to rely on the former, metadata extraction the ability to do teh latter. There's been interest in keeping the API as brutally simple as possible, so I was interested in exploring the use cases and pointing out the design decisions that follow. But that aside, I still think its a good idea to include a link :) > So instead of parsing out the name and putting that into a trivially > constructed url, you parse out a url and send it intact. Yes, just like a web browser does with the Location header and a redirect. > There's a lot of complexity that can go before this little bit. :) IMO, the API is about as small as it can possibly be to support a mix of use cases. To get smaller certain things need to be explicitly out of scope. Seems like documentation, e.g. on FORMAT, is where value can be added at present. (I'm coming at this as from an impl perspective as I'm considering adding unapi support to IngentaConnect) Cheers, L. -- Home: http://www.ldodds.com | "Simplicity is the ultimate Blog: http://www.ldodds.com/blog | sophistication" -- Leonardo da Vinci From azaroth at liverpool.ac.uk Tue Mar 28 10:19:45 2006 From: azaroth at liverpool.ac.uk (Rob Sanderson) Date: Tue Mar 28 10:23:02 2006 Subject: [gcs-pcs-list] format=FORMAT In-Reply-To: <44295247.4050604@ldodds.com> References: <44294023.2090807@ldodds.com> <1143556667.9492.20.camel@helmsdeep> <44294D4A.9040002@ldodds.com> <1143558189.9492.24.camel@helmsdeep> <44295247.4050604@ldodds.com> Message-ID: <1143559185.9492.31.camel@helmsdeep> On Tue, 2006-03-28 at 16:12 +0100, Leigh Dodds wrote: > Rob Sanderson wrote: > > > Great. So for every time you want to do something you need to make two > > calls to the webserver. I'm sure that'll go down well with big > > databases ;) > > Thats not what I was suggesting. I'm just curious about the use > cases. I don't see how you can avoid it? If the only way to get an item in a particular format is to use a non programmatically constructable URL which is included only in the ?uri=URI response, how can you get the item without first retrieving the url? > But that aside, I still think its a good idea to include a link :) It makes it easier to XSLT into something meaningful, for example. There are reasons, but I don't think that it should be at the expense of requiring multiple interactions. > > So instead of parsing out the name and putting that into a trivially > > constructed url, you parse out a url and send it intact. > Yes, just like a web browser does with the Location header and a > redirect. My point, lost to snippage, was that it's only harder in the same order of magnitude as 3*4 is harder than 4+4+4, and that before we discuss anything like that, we should stop discussing RDF, namespaces, extensibility, etc etc etc :) Rob -- Dr Robert Sanderson Dept of Computer Science, University of Liverpool Home: http://www.csc.liv.ac.uk/~azaroth/ Cheshire: http://www.cheshire3.org/ From daniel.chudnov at yale.edu Tue Mar 28 10:34:12 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Tue Mar 28 10:35:26 2006 Subject: [gcs-pcs-list] formats schema In-Reply-To: References: Message-ID: <4C37F556-3D36-4DDE-9A1E-302367C3CC87@yale.edu> On Mar 28, 2006, at 9:30 AM, Xiaoming Liu wrote: > On Tue, 28 Mar 2006, Bruce D'Arcus wrote: >>> >>> In the todo list there is an item of removing URI from response. If >>> it is getting through your concern might be addressed :-) I >>> advocate >>> removing URI from response and this discussion may add another >>> reason for >>> it. >> >> I'm not seeing that in the todo (?). > > My bad, I thought it was there, although "Consider refactoring the > formats specification to remove redundancy in UNAPI and UNAPI? > uri=URI" is sort of related. That includes this issue. -Dan From leigh at ldodds.com Tue Mar 28 10:32:48 2006 From: leigh at ldodds.com (Leigh Dodds) Date: Tue Mar 28 10:36:56 2006 Subject: [gcs-pcs-list] format=FORMAT In-Reply-To: <1143559185.9492.31.camel@helmsdeep> References: <44294023.2090807@ldodds.com> <1143556667.9492.20.camel@helmsdeep> <44294D4A.9040002@ldodds.com> <1143558189.9492.24.camel@helmsdeep> <44295247.4050604@ldodds.com> <1143559185.9492.31.camel@helmsdeep> Message-ID: <44295720.5030009@ldodds.com> Rob Sanderson wrote: > I don't see how you can avoid it? > > If the only way to get an item in a particular format is to use a non > programmatically constructable URL which is included only in > the ?uri=URI response, how can you get the item without first retrieving > the url? Because you may have found the URL directly from an embedded span, as noted in the spec under "A URI microformat": These link to the relevant unapi request, no? > My point, lost to snippage, was that it's only harder in the same order > of magnitude as 3*4 is harder than 4+4+4, and that before we discuss > anything like that, we should stop discussing RDF, namespaces, > extensibility, etc etc etc :) Yes, building links is easy and cheap. The cumulative costs of adding support for every new linking syntax isn't. This is where the benefits of typed, opaque links become important: a client shouldn't care what API a service is exposing, it should be able to traverse a link to get the desired metadata. Then we can all build that behaviour once and move on. But thats got very little to do with unapi, so I'll shut up. Cheers, L. -- Home: http://www.ldodds.com | "Simplicity is the ultimate Blog: http://www.ldodds.com/blog | sophistication" -- Leonardo da Vinci From leigh at ldodds.com Tue Mar 28 10:41:01 2006 From: leigh at ldodds.com (Leigh Dodds) Date: Tue Mar 28 10:41:23 2006 Subject: [gcs-pcs-list] format=FORMAT In-Reply-To: <44295720.5030009@ldodds.com> References: <44294023.2090807@ldodds.com> <1143556667.9492.20.camel@helmsdeep> <44294D4A.9040002@ldodds.com> <1143558189.9492.24.camel@helmsdeep> <44295247.4050604@ldodds.com> <1143559185.9492.31.camel@helmsdeep> <44295720.5030009@ldodds.com> Message-ID: <4429590D.7010106@ldodds.com> Leigh Dodds wrote: > > > These link to the relevant unapi request, no? Ah, I re-read the example and see that it doesn't. My mistake, the URI is the identifier for the item, not the URI of the unapi service. Perhaps it should be :) L. -- Home: http://www.ldodds.com | "Simplicity is the ultimate Blog: http://www.ldodds.com/blog | sophistication" -- Leonardo da Vinci From daniel.chudnov at yale.edu Tue Mar 28 10:43:44 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Tue Mar 28 10:45:09 2006 Subject: [gcs-pcs-list] format=FORMAT In-Reply-To: <44294023.2090807@ldodds.com> References: <44294023.2090807@ldodds.com> Message-ID: <1517C971-F216-4B0A-A75E-FB45676F7E69@yale.edu> On Mar 28, 2006, at 8:54 AM, Leigh Dodds wrote: > Is there an expectation/intention that the values for FORMAT > will be standardised? No. This is up to publishers, who may choose to use standardized format names if they wish. > I've seen discussion that recommends that FORMAT be a mimetype, > but thats not sufficient for all cases (and the formats schema > acknowledges this with additional elements that qualify each > format). Type is the mimetype. Name could be UTIs, locally-registered URIs, or anything else. > Given a base URL for an unapi service, should a system be able > to programmatically construct the ?uri=URI&format=FORMAT request? > > If the answer is yes, then we need clear unambiguous guidance on what > goes in FORMAT. From a base URL like UNAPI, no. From a URL like UNAPI?uri=URI, yes. > (I'm coming at this as from an impl perspective as I'm considering > adding unapi support to IngentaConnect) Cool. :) The objective of unAPI, as stated in the spec, is: "The objective of unAPI is to enable web sites with HTML interfaces to information-rich objects to simultaneously publish richly structured metadata for those objects, or those objects themselves, in a predictable and consistent way for machine processing." Full-on harvesting is not a stated goal. Maybe we should make that clearer... tightening up the intro is on the to-do list. -Dan From lists at hubmed.org Tue Mar 28 10:52:48 2006 From: lists at hubmed.org (Alf Eaton) Date: Tue Mar 28 10:56:11 2006 Subject: [gcs-pcs-list] format=FORMAT In-Reply-To: <4429590D.7010106@ldodds.com> References: <44294023.2090807@ldodds.com> <1143556667.9492.20.camel@helmsdeep> <44294D4A.9040002@ldodds.com> <1143558189.9492.24.camel@helmsdeep> <44295247.4050604@ldodds.com> <1143559185.9492.31.camel@helmsdeep> <44295720.5030009@ldodds.com> <4429590D.7010106@ldodds.com> Message-ID: <21A1CF0B-8BF6-4883-BB85-6C40CA4A2CFE@hubmed.org> On 28 Mar 2006, at 10:41, Leigh Dodds wrote: > Leigh Dodds wrote: > >> >> These link to the relevant unapi request, no? > > Ah, I re-read the example and see that it doesn't. My mistake, > the URI is the identifier for the item, not the URI of the unapi > service. > > Perhaps it should be :) At the moment, the URL of the unapi service is expected to be in the head of the page (or already known by the client), to avoid writing it out again for every link. You could conceivably make each item a proper link though, instead... alf. From daniel.chudnov at yale.edu Tue Mar 28 10:55:23 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Tue Mar 28 10:56:31 2006 Subject: [gcs-pcs-list] formats schema In-Reply-To: References: Message-ID: (Welcome Bruce. :) On Mar 28, 2006, at 8:22 AM, Xiaoming Liu wrote: > On Tue, 28 Mar 2006, Bruce D'Arcus wrote: >> It would be easy enough to make the format RDF and get it's built in >> extensibility. This, for example, is valid RDF: > > I am afraind RDF will scare people away ;-) in the very early > version of unAPI formats response is based on JSON, so unAPI is not > XML centric and it just happends to choose to use XML as response > format. I *told* you all that JSON would be easier. :) >> Removing this discussion from the realm of XML and RDF, just think of >> how you'd create a class that represented this? Would you call it >> "Formats" and then have a uri attribute and a "contents" attribute >> that was an array, or would you instead call it "Service" (or >> whatever >> else you think better describes it) and have an attribute called >> "formats"? The point of the spec is that these decisions are trivial and implementation-specific. In my code, there isn't even a class... it's just a list/array to be iterated over. -Dan From daniel.chudnov at yale.edu Tue Mar 28 11:09:34 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Tue Mar 28 11:10:57 2006 Subject: [gcs-pcs-list] format=FORMAT In-Reply-To: <44294D4A.9040002@ldodds.com> References: <44294023.2090807@ldodds.com> <1143556667.9492.20.camel@helmsdeep> <44294D4A.9040002@ldodds.com> Message-ID: On Mar 28, 2006, at 9:50 AM, Leigh Dodds wrote: > If the response format included a URL from which > the desired format can be retrieved then you don't actually need > FORMAT here -- it becomes an implementation detail of a given > service. By providing a URL in the response (or as an embedded > link), you've removed the need to include the details of how to > construct > that URL programmatically(*) > > format=FORMAT is only required if you're coming at a unapi service > without any previous interactions. This came up very recently. I wrote about my use case in some depth here: http://cipolo.med.yale.edu/pipermail/gcs-pcs-list/2006-March/ 000597.html An excerpt: "If unAPI implementers were *not* in the habit of actually fully developing the ability to answer UNAPI?uri=URI&format=FORMAT requests (even if they just redirect), then there might not be a way for me to re-associate Foo or other unalog users with the unAPI-source from which Bar originally got the data. I could point Foo to the redirected link (say, the flickr url) but then that loses the unAPI-source info. If I know the request came from the unAPI service, I can re-compose the UNAPI?uri=URI&format=FORMAT url for Foo, and Foo can either get it or not depending on access rights at the unAPI-source." Admittedly, that post effectively killed the thread. :) And, I'm not saying I've got it right. But, at this point, we can only discuss and decide on changes based on shared understanding of specific use cases. Continuing to discuss these kinds of changes to the spec divorced from any specific implementation context at any more length is distracting. It's not that the questions aren't good questions; rather, there's no way we can answer them to everyone's satisfaction without the use case. -Dan From liu_x at lanl.gov Tue Mar 28 11:14:51 2006 From: liu_x at lanl.gov (Xiaoming Liu) Date: Tue Mar 28 11:13:26 2006 Subject: [gcs-pcs-list] format=FORMAT In-Reply-To: <44294023.2090807@ldodds.com> References: <44294023.2090807@ldodds.com> Message-ID: On Tue, 28 Mar 2006, Leigh Dodds wrote: > > Another way to ask the same question is by considering the > whether the following is an expected use case: > > Given a base URL for an unapi service, should a system be able > to programmatically construct the ?uri=URI&format=FORMAT request? > I think this also comes to another item in todo list: "Clarify the relationship between UNAPI and UNAPI?uri=URI" If "unapi (no parameters) returns formats that can be disseminated from all identifiers", this single request might be sufficient for some services. e.g. if my service only handles dublin core, and the site formsts response includes dublin core, I can safely issue request unapi?uri=URI&format=dc for all identifiers, therefore relieve the load to unAPI providers. On another scenario, if we say "unapi (no parameters) returns all formats supported by this repository", you may have to issue "unapi?uri=URI" to get available formats for each URI, because there is no guarantee that a format will be available for a specific URI. I think the first case is more friendly to developers, however OAI-PMH supports second scenario. xiaoming From daniel.chudnov at yale.edu Tue Mar 28 11:24:02 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Tue Mar 28 11:25:11 2006 Subject: [gcs-pcs-list] unAPI issue: rename root node? In-Reply-To: References: <20060321223017.GF3685@sildin.med.yale.edu> Message-ID: <89D20134-5E55-43BA-B63B-25A8908EBA61@yale.edu> On Mar 27, 2006, at 2:55 PM, Robert Sanderson wrote: >> This thread broke down rather quickly into something we cannot decide >> on. Some quick observations: >> - If you want ZeeRex / Z39.92, use it. We're not duplicating it in >> unAPI. > > You are, in the formats response, in that formats is directly > equivalent > to explain/schemaInfo. No, we're not. c.f. discussion of OpenURL. We are pulling one exceedingly common and useful use case (copy this object) out of interaction patterns exhibited by users and implemented in various ways in diverse specifications. -Dan From daniel.chudnov at yale.edu Tue Mar 28 11:26:19 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Tue Mar 28 11:27:28 2006 Subject: [gcs-pcs-list] unAPI issue: vary unapi-uri class name? In-Reply-To: <63A93F61-DF4E-4340-9971-0DF20E0B7FA7@yale.edu> References: <63A93F61-DF4E-4340-9971-0DF20E0B7FA7@yale.edu> Message-ID: <4C8AD7E1-FED7-4A71-BD9D-67A5FC686F47@yale.edu> This fails. Issue closed. -Dan On Mar 27, 2006, at 10:59 AM, Daniel Chudnov wrote: > An earlier message from Eric suggested the possibility of varying > unAPI class names and target servers to help with the multiple- > provider issue, e.g. : > > href="http://example.com/unapi/" /> > href="http://isbn.example.org/unapi" /> > > and in the body: > PMID 12345678 > ISBN > 123456789X > > ...which is copied (with incomplete URIs in titles :) from the > message at: > > http://cipolo.med.yale.edu/pipermail/gcs-pcs-list/2006-March/ > 000491.html > > > This seems complicated, especially if it means we have to take on a > role of registering unapi class name variations. It also means > more of a burden on publishers to specify these options according > to identifier types. > > But... any takers, still? > > -Dan > _______________________________________________ > gcs-pcs-list mailing list > gcs-pcs-list@cipolo.med.yale.edu > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list > From leigh at ldodds.com Tue Mar 28 11:32:01 2006 From: leigh at ldodds.com (Leigh Dodds) Date: Tue Mar 28 11:36:04 2006 Subject: [gcs-pcs-list] format=FORMAT In-Reply-To: References: <44294023.2090807@ldodds.com> <1143556667.9492.20.camel@helmsdeep> <44294D4A.9040002@ldodds.com> Message-ID: <44296501.7070408@ldodds.com> Daniel Chudnov wrote: > This came up very recently. I wrote about my use case in some depth here: > > http://cipolo.med.yale.edu/pipermail/gcs-pcs-list/2006-March/000597.html I didn't understand the specific use case, then went on holiday, hence lack of response and sudden return to activity :) I'll re-read. > But, at this point, we can only discuss and decide on changes based on > shared understanding of specific use cases. Yes, which is where I came in! I'd suggest itemising those use cases, as it'd be useful to clarify further discussions. Cheers, L. -- Home: http://www.ldodds.com | "Simplicity is the ultimate Blog: http://www.ldodds.com/blog | sophistication" -- Leonardo da Vinci From azaroth at liverpool.ac.uk Tue Mar 28 11:35:08 2006 From: azaroth at liverpool.ac.uk (Rob Sanderson) Date: Tue Mar 28 11:38:20 2006 Subject: [gcs-pcs-list] unAPI issue: rename root node? In-Reply-To: <89D20134-5E55-43BA-B63B-25A8908EBA61@yale.edu> References: <20060321223017.GF3685@sildin.med.yale.edu> <89D20134-5E55-43BA-B63B-25A8908EBA61@yale.edu> Message-ID: <1143563708.9492.41.camel@helmsdeep> On Tue, 2006-03-28 at 11:24 -0500, Daniel Chudnov wrote: > On Mar 27, 2006, at 2:55 PM, Robert Sanderson wrote: > > >> This thread broke down rather quickly into something we cannot decide > >> on. Some quick observations: > >> - If you want ZeeRex / Z39.92, use it. We're not duplicating it in > >> unAPI. > > > > You are, in the formats response, in that formats is directly > > equivalent > > to explain/schemaInfo. > > No, we're not. c.f. discussion of OpenURL. Yes, you are, in the new, non standard formats response. As in an email in response to one of Leigh's comments, the information in formats is pretty much identical to the information which is included in ZeeRex schemaInfo/recordInfo. That is my claim. Feel free to try and refute it if you wish :) For example you could have recordInfo as your top level tag and just reference the Z39.92 spec. Not that I'm suggesting you WANT to do that, but it's certainly possible. If the idea is to allow extensibility, then it makes sense to extend something else rather than reinventing the wheel. (Of course unAPI essentially reinvents a bunch of wheels, so I guess that's not a goal of the spec) > We are pulling one exceedingly common and useful use case (copy this > object) out of interaction patterns exhibited by users and > implemented in various ways in diverse specifications. Which is very nice, but not at all relevant to formats response vs Z39.92. Rob -- Dr Robert Sanderson Dept of Computer Science, University of Liverpool Home: http://www.csc.liv.ac.uk/~azaroth/ Cheshire: http://www.cheshire3.org/ From daniel.chudnov at yale.edu Tue Mar 28 11:46:36 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Tue Mar 28 11:47:46 2006 Subject: [gcs-pcs-list] unAPI gauntlet thrown down: why extensibility. Message-ID: <4EA412B0-364E-47DF-B9D8-9AF22DC84D12@yale.edu> I suspect all our diverse current threads would clear up nicely if somebody could explain what "extensibility" means w/r/to unAPI and we all agreed. I propose that if nobody can, soon, we all stop talking about it. The word "extensibility" or variants do not appear in the spec at present. It's not a stated goal. Its implications are nebulous, its importance is debatable, its impact on our list is nefarious. Somebody please explain what you want it for, and soon, please. My take: we don't want extensibility from unAPI. Look for it in the formatted data you get from unAPI services, instead. -Dan From bdarcus.lists at gmail.com Tue Mar 28 11:59:33 2006 From: bdarcus.lists at gmail.com (Bruce D'Arcus) Date: Tue Mar 28 12:00:41 2006 Subject: [gcs-pcs-list] unAPI gauntlet thrown down: why extensibility. In-Reply-To: <4EA412B0-364E-47DF-B9D8-9AF22DC84D12@yale.edu> References: <4EA412B0-364E-47DF-B9D8-9AF22DC84D12@yale.edu> Message-ID: On 3/28/06, Daniel Chudnov wrote: > My take: we don't want extensibility from unAPI. Look for it in the > formatted data you get from unAPI services, instead. Makes sense to me. Bruce From azaroth at liverpool.ac.uk Tue Mar 28 12:01:11 2006 From: azaroth at liverpool.ac.uk (Rob Sanderson) Date: Tue Mar 28 12:04:25 2006 Subject: [gcs-pcs-list] unAPI gauntlet thrown down: why extensibility. In-Reply-To: <4EA412B0-364E-47DF-B9D8-9AF22DC84D12@yale.edu> References: <4EA412B0-364E-47DF-B9D8-9AF22DC84D12@yale.edu> Message-ID: <1143565271.9492.44.camel@helmsdeep> On Tue, 2006-03-28 at 11:46 -0500, Daniel Chudnov wrote: > I suspect all our diverse current threads would clear up nicely if > somebody could explain what "extensibility" means w/r/to unAPI and we > all agreed. My definition: The ability to include information in responses which is NOT in the specification and possibly to have some standard framework in which to do that. (Eg extraFooData in SRU gives us as much extensibility as we will ever need, but it's completely inappropriate for a 2 hour spec like unAPI as opposed to a 2 week spec like SRU) I give extensibility a big fat -1 in any of its forms (for unAPI). R -- Dr Robert Sanderson Dept of Computer Science, University of Liverpool Home: http://www.csc.liv.ac.uk/~azaroth/ Cheshire: http://www.cheshire3.org/ From liu_x at lanl.gov Tue Mar 28 12:21:33 2006 From: liu_x at lanl.gov (Xiaoming Liu) Date: Tue Mar 28 12:20:08 2006 Subject: [gcs-pcs-list] unAPI gauntlet thrown down: why extensibility. In-Reply-To: <4EA412B0-364E-47DF-B9D8-9AF22DC84D12@yale.edu> References: <4EA412B0-364E-47DF-B9D8-9AF22DC84D12@yale.edu> Message-ID: On Tue, 28 Mar 2006, Daniel Chudnov wrote: > I suspect all our diverse current threads would clear up nicely if somebody > could explain what "extensibility" means w/r/to unAPI and we all agreed. I am thinking any provider can insert vendor-specific data. But I am willing to withdraw the issue for all these confusions/difficulties. xiaoming > > I propose that if nobody can, soon, we all stop talking about it. The word > "extensibility" or variants do not appear in the spec at present. It's not a > stated goal. Its implications are nebulous, its importance is debatable, its > impact on our list is nefarious. > > Somebody please explain what you want it for, and soon, please. > > My take: we don't want extensibility from unAPI. Look for it in the > formatted data you get from unAPI services, instead. > > -Dan > _______________________________________________ > gcs-pcs-list mailing list > gcs-pcs-list@cipolo.med.yale.edu > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list From daniel.chudnov at yale.edu Wed Mar 29 19:23:54 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Wed Mar 29 19:23:56 2006 Subject: [gcs-pcs-list] unAPI gauntlet thrown down: why extensibility. In-Reply-To: References: <4EA412B0-364E-47DF-B9D8-9AF22DC84D12@yale.edu> Message-ID: <20060330002353.GH13803@sildin.med.yale.edu> Xiaoming Liu wrote, on Tue, Mar 28, 2006 at 10:21:33AM -0700: > On Tue, 28 Mar 2006, Daniel Chudnov wrote: > > >I suspect all our diverse current threads would clear up nicely if > >somebody could explain what "extensibility" means w/r/to unAPI and we all > >agreed. > > I am thinking any provider can insert vendor-specific data. But I am > willing to withdraw the issue for all these confusions/difficulties. If we *don't* reference a schema, couldn't people just do this if they want? So long as a service validates cleanly, unAPI is unAPI, even if other stuff gets thrown into it. I don't understand this, since I don't really speak XML. Could it work this way? We specify nothing, and people can add to it, or not. Let features emerge through experience and convention, or not. I can't tell if this is evil or beautiful or beautifully evil or dumb. -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From daniel.chudnov at yale.edu Wed Mar 29 19:25:44 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Wed Mar 29 19:25:46 2006 Subject: [gcs-pcs-list] not unAPI: a "go" implementation Message-ID: <20060330002543.GI13803@sildin.med.yale.edu> Interesting: http://infogami.com/blog/books Hmm... "go" sounds familiar somehow... :) -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From bdarcus.lists at gmail.com Wed Mar 29 19:43:06 2006 From: bdarcus.lists at gmail.com (Bruce D'Arcus) Date: Wed Mar 29 19:44:09 2006 Subject: [gcs-pcs-list] unAPI gauntlet thrown down: why extensibility. In-Reply-To: <20060330002353.GH13803@sildin.med.yale.edu> References: <4EA412B0-364E-47DF-B9D8-9AF22DC84D12@yale.edu> <20060330002353.GH13803@sildin.med.yale.edu> Message-ID: On 3/29/06, Daniel Chudnov wrote: > Xiaoming Liu wrote, on Tue, Mar 28, 2006 at 10:21:33AM -0700: > > > I am thinking any provider can insert vendor-specific data. But I am > > willing to withdraw the issue for all these confusions/difficulties. > > If we *don't* reference a schema, couldn't people just do this if > they want? So long as a service validates cleanly, unAPI is unAPI, > even if other stuff gets thrown into it. > > I don't understand this, since I don't really speak XML. Could it > work this way? We specify nothing, and people can add to it, or not. > Let features emerge through experience and convention, or not. IIf you allow extension, I think it's good practice to specify the rules for it, rather than let people fumble around in the dark until stuff breaks. And I also think that if you want to allow extension, it makes sense to namespace it. Bruce From liu_x at lanl.gov Wed Mar 29 22:34:11 2006 From: liu_x at lanl.gov (Xiaoming Liu) Date: Wed Mar 29 22:32:43 2006 Subject: [gcs-pcs-list] unAPI gauntlet thrown down: why extensibility. In-Reply-To: <20060330002353.GH13803@sildin.med.yale.edu> References: <4EA412B0-364E-47DF-B9D8-9AF22DC84D12@yale.edu> <20060330002353.GH13803@sildin.med.yale.edu> Message-ID: On Wed, 29 Mar 2006, Daniel Chudnov wrote: > Xiaoming Liu wrote, on Tue, Mar 28, 2006 at 10:21:33AM -0700: >> On Tue, 28 Mar 2006, Daniel Chudnov wrote: >> >>> I suspect all our diverse current threads would clear up nicely if >>> somebody could explain what "extensibility" means w/r/to unAPI and we all >>> agreed. >> >> I am thinking any provider can insert vendor-specific data. But I am >> willing to withdraw the issue for all these confusions/difficulties. > > If we *don't* reference a schema, couldn't people just do this if > they want? So long as a service validates cleanly, unAPI is unAPI, > even if other stuff gets thrown into it. Without schema, I think it's a grey area. So indeed people can throw other things in without breaking rules. In essence I see this is same as Atom's approach (rfc4287, section 6), unfortunately they don't invent a catchy name so we cannot easily reference it; a verbatim copy might be too much, but one snippet may catch the idea: "Atom allows foreign markup anywhere in an Atom document. The role of foreign markup is undefined by this specification." I also agree with Bruce that a namespace is important in this case. Maybe a namespace and a sentence can do the trick? xiaoming > > I don't understand this, since I don't really speak XML. Could it > work this way? We specify nothing, and people can add to it, or not. > Let features emerge through experience and convention, or not. > > I can't tell if this is evil or beautiful or beautifully evil or dumb. > > -Dan > > > From azaroth at liverpool.ac.uk Thu Mar 30 03:11:08 2006 From: azaroth at liverpool.ac.uk (Robert Sanderson) Date: Thu Mar 30 03:14:21 2006 Subject: [gcs-pcs-list] unAPI gauntlet thrown down: why extensibility. In-Reply-To: References: <4EA412B0-364E-47DF-B9D8-9AF22DC84D12@yale.edu> <20060330002353.GH13803@sildin.med.yale.edu> Message-ID: >In essence I see this is same as Atom's approach (rfc4287, section 6), >unfortunately they don't invent a catchy name so we cannot easily >reference it; a verbatim copy might be too much, but one snippet may catch >the idea: "Atom allows foreign markup anywhere in an Atom document. The >role of foreign markup is undefined by this specification." Which allows for: (zeerex) XML ... ... ... Do you REALLY want that? Does the same apply to the other response formats? If so, I'll happily return some 'foreign' elements in my 'new' implementation... 1 ... etc. And I'm sure that OpenSearch people and OAI people and openURL people will all do the same, and claim unAPI conformance. ;) Just. Say. No. Rob From liu_x at lanl.gov Thu Mar 30 08:47:37 2006 From: liu_x at lanl.gov (Xiaoming Liu) Date: Thu Mar 30 08:46:11 2006 Subject: [gcs-pcs-list] unAPI gauntlet thrown down: why extensibility. In-Reply-To: References: <4EA412B0-364E-47DF-B9D8-9AF22DC84D12@yale.edu> <20060330002353.GH13803@sildin.med.yale.edu> Message-ID: Rob, Sorry I didn't put the most accurate words, but I hope we understand each other what I am tring to say here. I am talking the way of Atom, and I think it's simple and clean. About unAPI compliance, I have my own opinion. When targetting one page spec, it's difficult to make it as solid as TCP/IP. You have to expect people do sensible things. The prize is not to claim unAPI compliance, but rather to have your data widely used. regards, xiaoming On Thu, 30 Mar 2006, Robert Sanderson wrote: > >> In essence I see this is same as Atom's approach (rfc4287, section 6), >> unfortunately they don't invent a catchy name so we cannot easily >> reference it; a verbatim copy might be too much, but one snippet may catch >> the idea: "Atom allows foreign markup anywhere in an Atom document. The >> role of foreign markup is undefined by this specification." > > Which allows for: > > > > (zeerex) > XML > > > ... > ... > > > > > > > ... > > > > > > Do you REALLY want that? > > Does the same apply to the other response formats? > > If so, I'll happily return some 'foreign' elements in my 'new' > implementation... > > > > 1 > > > ... > > etc. > > And I'm sure that OpenSearch people and OAI people and openURL people > will all do the same, and claim unAPI conformance. > > ;) > > Just. Say. No. > > Rob > > _______________________________________________ > gcs-pcs-list mailing list > gcs-pcs-list@cipolo.med.yale.edu > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list > From azaroth at liverpool.ac.uk Thu Mar 30 09:21:19 2006 From: azaroth at liverpool.ac.uk (Rob Sanderson) Date: Thu Mar 30 09:24:32 2006 Subject: [gcs-pcs-list] unAPI gauntlet thrown down: why extensibility. In-Reply-To: References: <4EA412B0-364E-47DF-B9D8-9AF22DC84D12@yale.edu> <20060330002353.GH13803@sildin.med.yale.edu> Message-ID: <1143728479.31094.9.camel@helmsdeep> Here is my point: If you allow arbitrary elements to be included in the response, you allow me to claim that SRU or any other extensible spec is unAPI. You allow ANYONE to implement unapi in any way they want, so long as those elements are somewhere in the response. The aim IS to make data more available. I have shown that allowing arbitrary elements makes it less available, to the point of being completely worthless if you nest the unapi elements somewhere in arbitrary XML. Therefore the obvious solution is: Do Not Allow Extra Elements. Rob On Thu, 2006-03-30 at 06:47 -0700, Xiaoming Liu wrote: > Rob, > > Sorry I didn't put the most accurate words, but I hope we understand each > other what I am tring to say here. I am talking the way of Atom, and I > think it's simple and clean. > > About unAPI compliance, I have my own opinion. When targetting one page > spec, it's difficult to make it as solid as TCP/IP. You have to expect > people do sensible things. The prize is not to claim unAPI compliance, but > rather to have your data widely used. > > regards, > xiaoming > > > On Thu, 30 Mar 2006, Robert Sanderson wrote: > > > > >> In essence I see this is same as Atom's approach (rfc4287, section 6), > >> unfortunately they don't invent a catchy name so we cannot easily > >> reference it; a verbatim copy might be too much, but one snippet may catch > >> the idea: "Atom allows foreign markup anywhere in an Atom document. The > >> role of foreign markup is undefined by this specification." > > > > Which allows for: > > > > > > > > (zeerex) > > XML > > > > > > ... > > ... > > > > > > > > > > > > > > ... > > > > > > > > > > > > Do you REALLY want that? > > > > Does the same apply to the other response formats? > > > > If so, I'll happily return some 'foreign' elements in my 'new' > > implementation... > > > > > > > > 1 > > > > > > ... > > > > etc. > > > > And I'm sure that OpenSearch people and OAI people and openURL people > > will all do the same, and claim unAPI conformance. > > > > ;) > > > > Just. Say. No. > > > > Rob > > > > _______________________________________________ > > gcs-pcs-list mailing list > > gcs-pcs-list@cipolo.med.yale.edu > > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list > > > > -- Dr Robert Sanderson Dept of Computer Science, University of Liverpool Home: http://www.csc.liv.ac.uk/~azaroth/ Cheshire: http://www.cheshire3.org/ From ross.singer at library.gatech.edu Thu Mar 30 09:53:37 2006 From: ross.singer at library.gatech.edu (Ross Singer) Date: Thu Mar 30 09:54:45 2006 Subject: [gcs-pcs-list] unAPI gauntlet thrown down: why extensibility. In-Reply-To: <1143728479.31094.9.camel@helmsdeep> References: <4EA412B0-364E-47DF-B9D8-9AF22DC84D12@yale.edu> <20060330002353.GH13803@sildin.med.yale.edu> <1143728479.31094.9.camel@helmsdeep> Message-ID: <23b83f160603300653x593165cfmb4a7d09026b43284@mail.gmail.com> Er, Rob, would a good analog to what you're saying be the notion of what happened with Z39.50? It's one thing for everyone to implement something, but degrades its value when everyone answers requests in a different way. -Ross. On 3/30/06, Rob Sanderson wrote: > > > Here is my point: > > If you allow arbitrary elements to be included in the response, you > allow me to claim that SRU or any other extensible spec is unAPI. You > allow ANYONE to implement unapi in any way they want, so long as those > elements are somewhere in the response. > > The aim IS to make data more available. I have shown that allowing > arbitrary elements makes it less available, to the point of being > completely worthless if you nest the unapi elements somewhere in > arbitrary XML. > > Therefore the obvious solution is: > > Do Not Allow Extra Elements. > > Rob > > On Thu, 2006-03-30 at 06:47 -0700, Xiaoming Liu wrote: > > Rob, > > > > Sorry I didn't put the most accurate words, but I hope we understand > each > > other what I am tring to say here. I am talking the way of Atom, and I > > think it's simple and clean. > > > > About unAPI compliance, I have my own opinion. When targetting one page > > spec, it's difficult to make it as solid as TCP/IP. You have to expect > > people do sensible things. The prize is not to claim unAPI compliance, > but > > rather to have your data widely used. > > > > regards, > > xiaoming > > > > > > On Thu, 30 Mar 2006, Robert Sanderson wrote: > > > > > > > >> In essence I see this is same as Atom's approach (rfc4287, section > 6), > > >> unfortunately they don't invent a catchy name so we cannot easily > > >> reference it; a verbatim copy might be too much, but one snippet may > catch > > >> the idea: "Atom allows foreign markup anywhere in an Atom document. > The > > >> role of foreign markup is undefined by this specification." > > > > > > Which allows for: > > > > > > > > > > > > (zeerex) > > > XML > > > > > > > > > ... > > > ... > > > > > > > > > > > > > > > > > > > > > ... > > > > > > > > > > > > > > > > > > Do you REALLY want that? > > > > > > Does the same apply to the other response formats? > > > > > > If so, I'll happily return some 'foreign' elements in my 'new' > > > implementation... > > > > > > > > > > > > 1 > > > > > > > > > ... > > > > > > etc. > > > > > > And I'm sure that OpenSearch people and OAI people and openURL people > > > will all do the same, and claim unAPI conformance. > > > > > > ;) > > > > > > Just. Say. No. > > > > > > Rob > > > > > > _______________________________________________ > > > gcs-pcs-list mailing list > > > gcs-pcs-list@cipolo.med.yale.edu > > > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list > > > > > > > > -- > Dr Robert Sanderson > Dept of Computer Science, University of Liverpool > Home: http://www.csc.liv.ac.uk/~azaroth/ > Cheshire: http://www.cheshire3.org/ > > _______________________________________________ > gcs-pcs-list mailing list > gcs-pcs-list@cipolo.med.yale.edu > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://cipolo.med.yale.edu/pipermail/gcs-pcs-list/attachments/20060330/7b838ddb/attachment-0001.htm From azaroth at liverpool.ac.uk Thu Mar 30 10:04:09 2006 From: azaroth at liverpool.ac.uk (Rob Sanderson) Date: Thu Mar 30 10:07:21 2006 Subject: [gcs-pcs-list] unAPI gauntlet thrown down: why extensibility. In-Reply-To: <23b83f160603300653x593165cfmb4a7d09026b43284@mail.gmail.com> References: <4EA412B0-364E-47DF-B9D8-9AF22DC84D12@yale.edu> <20060330002353.GH13803@sildin.med.yale.edu> <1143728479.31094.9.camel@helmsdeep> <23b83f160603300653x593165cfmb4a7d09026b43284@mail.gmail.com> Message-ID: <1143731049.31094.23.camel@helmsdeep> Yep. It's at least as bad as that. With Z39.50 there's at least a spec that you can implement badly. Here there's no spec and hence you can't implement it wrong. R On Thu, 2006-03-30 at 09:53 -0500, Ross Singer wrote: > Er, Rob, would a good analog to what you're saying be the notion of > what happened with Z39.50? It's one thing for everyone to implement > something, but degrades its value when everyone answers requests in a > different way. > > -Ross. > > On 3/30/06, Rob Sanderson wrote: > > Here is my point: > > If you allow arbitrary elements to be included in the > response, you > allow me to claim that SRU or any other extensible spec is > unAPI. You > allow ANYONE to implement unapi in any way they want, so long > as those > elements are somewhere in the response. > > The aim IS to make data more available. I have shown that > allowing > arbitrary elements makes it less available, to the point of > being > completely worthless if you nest the unapi elements somewhere > in > arbitrary XML. > > Therefore the obvious solution is: > > Do Not Allow Extra Elements. > > Rob > > On Thu, 2006-03-30 at 06:47 -0700, Xiaoming Liu wrote: > > Rob, > > > > Sorry I didn't put the most accurate words, but I hope we > understand each > > other what I am tring to say here. I am talking the way of > Atom, and I > > think it's simple and clean. > > > > About unAPI compliance, I have my own opinion. When > targetting one page > > spec, it's difficult to make it as solid as TCP/IP. You have > to expect > > people do sensible things. The prize is not to claim unAPI > compliance, but > > rather to have your data widely used. > > > > regards, > > xiaoming > > > > > > On Thu, 30 Mar 2006, Robert Sanderson wrote: > > > > > > > >> In essence I see this is same as Atom's approach > (rfc4287, section 6), > > >> unfortunately they don't invent a catchy name so we > cannot easily > > >> reference it; a verbatim copy might be too much, but one > snippet may catch > > >> the idea: "Atom allows foreign markup anywhere in an Atom > document. The > > >> role of foreign markup is undefined by this > specification." > > > > > > Which allows for: > > > > > > > > > > > > (zeerex) > > > XML > > > > > > > > > ... > > > ... > > > > > > > > > > > > > > > > > > > > > ... > > > > > > > > > > > > > > > > > > Do you REALLY want that? > > > > > > Does the same apply to the other response formats? > > > > > > If so, I'll happily return some 'foreign' elements in my > 'new' > > > implementation... > > > > > > > > > > > > 1 > > > > > > > > > ... > > > > > > etc. > > > > > > And I'm sure that OpenSearch people and OAI people and > openURL people > > > will all do the same, and claim unAPI conformance. > > > > > > ;) > > > > > > Just. Say. No. > > > > > > Rob > > > > > > _______________________________________________ > > > gcs-pcs-list mailing list > > > gcs-pcs-list@cipolo.med.yale.edu > > > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list > > > > > > > > -- > Dr Robert Sanderson > Dept of Computer Science, University of Liverpool > Home: http://www.csc.liv.ac.uk/~azaroth/ > Cheshire: http://www.cheshire3.org/ > > _______________________________________________ > gcs-pcs-list mailing list > gcs-pcs-list@cipolo.med.yale.edu > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list > > -- Dr Robert Sanderson Dept of Computer Science, University of Liverpool Home: http://www.csc.liv.ac.uk/~azaroth/ Cheshire: http://www.cheshire3.org/ From daniel.chudnov at yale.edu Thu Mar 30 10:21:07 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Thu Mar 30 10:22:31 2006 Subject: [gcs-pcs-list] unAPI gauntlet thrown down: why extensibility. In-Reply-To: References: <4EA412B0-364E-47DF-B9D8-9AF22DC84D12@yale.edu> <20060330002353.GH13803@sildin.med.yale.edu> Message-ID: On Mar 30, 2006, at 3:11 AM, Robert Sanderson wrote: > > And I'm sure that OpenSearch people and OAI people and openURL people > will all do the same, and claim unAPI conformance. With all due respect, that's absurd. I think the question at hand is first "whither extensibility". Agreement so far seems to be "no where". Then the question becomes "if we specify nothing, what does that mean?" If the answer is "then people can do anything", the question becomes "can we live with that?" If the answer's no, then we need a schema or a namespace or something, I'm not sure what. Your repeated statements regarding these issues seem to contradict themselves in this regard. -Dan From fawcett at uwindsor.ca Thu Mar 30 10:20:17 2006 From: fawcett at uwindsor.ca (Graham Fawcett) Date: Thu Mar 30 10:22:48 2006 Subject: [gcs-pcs-list] unAPI gauntlet thrown down: why extensibility. In-Reply-To: <1143728479.31094.9.camel@helmsdeep> References: <4EA412B0-364E-47DF-B9D8-9AF22DC84D12@yale.edu> <20060330002353.GH13803@sildin.med.yale.edu> <1143728479.31094.9.camel@helmsdeep> Message-ID: <442BF731.1030702@uwindsor.ca> On 3/30/2006 9:21 AM, Rob Sanderson wrote: > The aim IS to make data more available. I have shown that allowing > arbitrary elements makes it less available, to the point of being > completely worthless if you nest the unapi elements somewhere in > arbitrary XML. > But you don't have to allow for nesting of unapi elements in order to allow for arbitrary content, right? It can be specified that 'uri' and 'format' elements must be children of the root, and may contain no arbitrary elements; but that the root may contain arbitrary elements following the last 'format' element. You could just tell implementors of 'simple' unapi clients -- those that avoid or ignore the rigours of the schema -- just to consume 'uri', then consume one or more 'format' elements until (a) there are no more elements or (b) they encounter an element with tagname != 'format', and then stop processing. If you want to be extra friendly to extenders, I guess you could permit arbitrary elements within 'format' elements, after 'formats/format/schema_location'. It's harder to write a naive script to account for that, though, due to all the optional subelements of 'format'. But since each 'format/name' is unique (presumably?) there's the opportunity for extenders to map content in their top-level arbitrary-elements onto format entries, using format/names as keys. You get at least a chance to relate arbitrary data to formats, without actually adding any content to the format entries themselves. A reasonable compromise? > Therefore the obvious solution is: > > Do Not Allow Extra Elements. > or perhaps, Do Not Allow Extra Elements, Except Within a Well-Defined Location That's Easily Avoided by Uninterested Folk. ;-) (Not that I'm voting for extensibility, mind you -- just pointing out that it could be implemented with minimal impact, and then dismissed from the discussion.) Graham -- Graham Fawcett Application Developer/Consultant Centre for Flexible Learning University of Windsor fawcett@uwindsor.ca (519) 253-3000 ext 3049 From azaroth at liverpool.ac.uk Thu Mar 30 10:28:54 2006 From: azaroth at liverpool.ac.uk (Rob Sanderson) Date: Thu Mar 30 10:28:58 2006 Subject: [gcs-pcs-list] unAPI gauntlet thrown down: why extensibility. In-Reply-To: References: <4EA412B0-364E-47DF-B9D8-9AF22DC84D12@yale.edu> <20060330002353.GH13803@sildin.med.yale.edu> Message-ID: <1143732534.31094.29.camel@helmsdeep> On Thu, 2006-03-30 at 10:21 -0500, Daniel Chudnov wrote: > On Mar 30, 2006, at 3:11 AM, Robert Sanderson wrote: > > And I'm sure that OpenSearch people and OAI people and openURL people > > will all do the same, and claim unAPI conformance. > > With all due respect, that's absurd. I'm glad that you agree :) > Your repeated statements regarding these issues seem to contradict > themselves in this regard. In what way? Rob -- Dr Robert Sanderson Dept of Computer Science, University of Liverpool Home: http://www.csc.liv.ac.uk/~azaroth/ Cheshire: http://www.cheshire3.org/ From liu_x at lanl.gov Thu Mar 30 11:12:42 2006 From: liu_x at lanl.gov (Xiaoming Liu) Date: Thu Mar 30 11:11:13 2006 Subject: [gcs-pcs-list] unAPI gauntlet thrown down: why extensibility. In-Reply-To: <1143728479.31094.9.camel@helmsdeep> References: <4EA412B0-364E-47DF-B9D8-9AF22DC84D12@yale.edu> <20060330002353.GH13803@sildin.med.yale.edu> <1143728479.31094.9.camel@helmsdeep> Message-ID: On Thu, 30 Mar 2006, Rob Sanderson wrote: > > Here is my point: > > If you allow arbitrary elements to be included in the response, you > allow me to claim that SRU or any other extensible spec is unAPI. You > allow ANYONE to implement unapi in any way they want, so long as those > elements are somewhere in the response. No, this is not my intention, and Graham has good points about this. Atom has a whole section about extensibility, which is actually very generic and certainly addresses your concern, but unfortunately there is not a catchy word for this pattern, and we don't want to bloat unAPI spec with another page of extensibility issue. Anyhow, I am pro Dan's previous words: "We specify nothing, and people can add to it, or not. Let features emerge through experience and convention, or not." Think about HTML and what happened in browser war. If we don't understand the issue well to convince each other, maybe it's better to leave it blank. If indeed unAPI flies, more experiments and implementations will settle the issue. xiaoming > > The aim IS to make data more available. I have shown that allowing > arbitrary elements makes it less available, to the point of being > completely worthless if you nest the unapi elements somewhere in > arbitrary XML. > > Therefore the obvious solution is: > > Do Not Allow Extra Elements. > > Rob > > On Thu, 2006-03-30 at 06:47 -0700, Xiaoming Liu wrote: >> Rob, >> >> Sorry I didn't put the most accurate words, but I hope we understand each >> other what I am tring to say here. I am talking the way of Atom, and I >> think it's simple and clean. >> >> About unAPI compliance, I have my own opinion. When targetting one page >> spec, it's difficult to make it as solid as TCP/IP. You have to expect >> people do sensible things. The prize is not to claim unAPI compliance, but >> rather to have your data widely used. >> >> regards, >> xiaoming >> >> >> On Thu, 30 Mar 2006, Robert Sanderson wrote: >> >>> >>>> In essence I see this is same as Atom's approach (rfc4287, section 6), >>>> unfortunately they don't invent a catchy name so we cannot easily >>>> reference it; a verbatim copy might be too much, but one snippet may catch >>>> the idea: "Atom allows foreign markup anywhere in an Atom document. The >>>> role of foreign markup is undefined by this specification." >>> >>> Which allows for: >>> >>> >>> >>> (zeerex) >>> XML >>> >>> >>> ... >>> ... >>> >>> >>> >>> >>> >>> >>> ... >>> >>> >>> >>> >>> >>> Do you REALLY want that? >>> >>> Does the same apply to the other response formats? >>> >>> If so, I'll happily return some 'foreign' elements in my 'new' >>> implementation... >>> >>> >>> >>> 1 >>> >>> >>> ... >>> >>> etc. >>> >>> And I'm sure that OpenSearch people and OAI people and openURL people >>> will all do the same, and claim unAPI conformance. >>> >>> ;) >>> >>> Just. Say. No. >>> >>> Rob >>> >>> _______________________________________________ >>> gcs-pcs-list mailing list >>> gcs-pcs-list@cipolo.med.yale.edu >>> http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list >>> >> >> > From lists at hubmed.org Thu Mar 30 10:51:53 2006 From: lists at hubmed.org (Alf Eaton) Date: Thu Mar 30 11:33:00 2006 Subject: [gcs-pcs-list] unAPI gauntlet thrown down: why extensibility. In-Reply-To: References: <4EA412B0-364E-47DF-B9D8-9AF22DC84D12@yale.edu> <20060330002353.GH13803@sildin.med.yale.edu> Message-ID: <4DE7C025-D93F-444F-AAAE-4FD1BF879726@hubmed.org> I like the way that XSPF allows extensibility at a particular point in a playlist or track element, using an 'extension' element. XSPF has its own namespace, and people can insert their own elements inside the extension element in their own namespace if needed, while still allowing XSPF to validate and be parsed as normal. http://www.xspf.org/xspf-v1.html Whether extensibility (or even XML) is needed in unAPI is another question - I guess it's impossible to know in advance - but if it was I think this would be a good way to do it. As a suggestion for something that might be possible in an extension, the unAPI server might want to add the URL of another unAPI server that it knows will be able to handle the requested URI better (seeAlso, if you like). alf. From mrylander at gmail.com Thu Mar 30 11:39:49 2006 From: mrylander at gmail.com (Mike Rylander) Date: Thu Mar 30 11:40:54 2006 Subject: [gcs-pcs-list] unAPI gauntlet thrown down: why extensibility. In-Reply-To: <4EA412B0-364E-47DF-B9D8-9AF22DC84D12@yale.edu> References: <4EA412B0-364E-47DF-B9D8-9AF22DC84D12@yale.edu> Message-ID: On 3/28/06, Daniel Chudnov wrote: > My take: we don't want extensibility from unAPI. Look for it in the > formatted data you get from unAPI services, instead. > It seems that the confusion stemmed, at first, from a discussion of "should be the root node", which subsequently morphed into a "but other thingies do it this way" stand off. Now, I admit that I used the "e" word when first addressing the issue, but that was all hand-waving strawmaniness. After sitting back and observing the thread, and absorbing some thoughts from those obviously smarter than myself, here's my summation and proposal: 1) we don't know what "extensibility" means in unAPI (because it cannot yet be known) 2) we want to keep implementations simple 3) we want to allow for future customization/expansion without breaking backwards compatibility (I think?...) So, to state directly what others have alluded and linked to, here's a proposal: In the case of the current response to a specific URI request, leave as the root node, don't namespace our elements, and say (perhaps in a non normative reference doc) "if you want to add stuff to a URI response, just use namespaced elements, but you cannot change the root node and expect most unAPI clients to cope." For the base response (sometimes referred to as the introspection document) it makes sense to create a new root element to wrap , because it's /very easy/ to imagine passing extra optional info to "smart" clients along with the list. So, we add an element as the root, and say the same thing about that element as we did about the URI specific element: add stuff if you like, but don't break the structure of the response, and namespace your optional (to unAPI clients) crap. While this is not the most elegant solution in the world (from an XML perspective), it has exactly one precedent that wins almost /all/ arguments in terms of adoption and simplicity: RSS. -- Mike Rylander mrylander@gmail.com GPLS -- PINES Development Database Developer http://open-ils.org From bdarcus.lists at gmail.com Thu Mar 30 12:08:26 2006 From: bdarcus.lists at gmail.com (Bruce D'Arcus) Date: Thu Mar 30 12:09:29 2006 Subject: [gcs-pcs-list] unAPI gauntlet thrown down: why extensibility. In-Reply-To: References: <4EA412B0-364E-47DF-B9D8-9AF22DC84D12@yale.edu> <20060330002353.GH13803@sildin.med.yale.edu> Message-ID: On 3/30/06, Xiaoming Liu wrote: > Sorry I didn't put the most accurate words, but I hope we understand each > other what I am tring to say here. I am talking the way of Atom, and I > think it's simple and clean. It's worth noting that Atom is a data format primarily. What we're talking about here has a much more focused and narrow task, one which I'm sceptcal needs extensibility. I say: 1) do not allow extension 2) publish a draft schema, without a namespace 3) evolve the schema if there is a real need, either by adding explicit elements or attributes, or by adding a namespace and explicit extension structures You probably won''t even need to get to step 3. My druthers is that most of the content is better captured with attributes, but beyond relative verbosity (an attribute-only version would yeild more compact files), this is mostly personal opinion. Bruce From daniel.chudnov at yale.edu Fri Mar 31 12:05:51 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Fri Mar 31 12:05:52 2006 Subject: [gcs-pcs-list] unAPI gauntlet thrown down: why extensibility. In-Reply-To: <1143732534.31094.29.camel@helmsdeep> References: <4EA412B0-364E-47DF-B9D8-9AF22DC84D12@yale.edu> <20060330002353.GH13803@sildin.med.yale.edu> <1143732534.31094.29.camel@helmsdeep> Message-ID: <20060331170550.GC7796@sildin.med.yale.edu> Rob Sanderson wrote, on Thu, Mar 30, 2006 at 03:28:54PM +0000: > On Thu, 2006-03-30 at 10:21 -0500, Daniel Chudnov wrote: > > On Mar 30, 2006, at 3:11 AM, Robert Sanderson wrote: > > > And I'm sure that OpenSearch people and OAI people and openURL people > > > will all do the same, and claim unAPI conformance. > > > > With all due respect, that's absurd. > > I'm glad that you agree :) Actually, I meant that that I think it's absurd to think that OpenSearch, OAI, and OpenURL people would do that and claim that. unAPI isn't exactly the web2.0 buzzword of the day. (Yet.) > > Your repeated statements regarding these issues seem to contradict > > themselves in this regard. > > In what way? You are against extensibility; that's fair. You are also against an explicit, restrictive schema or namespace or other avenues of discussion that call for locking down the spec so that nothing else is allowed (unless you're simply for saying "nothing else is allowed", which we haven't really floated, or if you or someone else did, I'm sorry I missed it). That, by itself, is fair too. But, I don't know how you can have the former without some expression of the intent of the latter. -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From azaroth at liverpool.ac.uk Fri Mar 31 12:26:57 2006 From: azaroth at liverpool.ac.uk (Rob Sanderson) Date: Fri Mar 31 12:34:56 2006 Subject: [gcs-pcs-list] unAPI gauntlet thrown down: why extensibility. In-Reply-To: <20060331170550.GC7796@sildin.med.yale.edu> References: <4EA412B0-364E-47DF-B9D8-9AF22DC84D12@yale.edu> <20060330002353.GH13803@sildin.med.yale.edu> <1143732534.31094.29.camel@helmsdeep> <20060331170550.GC7796@sildin.med.yale.edu> Message-ID: <1143826017.6581.16.camel@helmsdeep> On Fri, 2006-03-31 at 12:05 -0500, Daniel Chudnov wrote: > Rob Sanderson wrote, on Thu, Mar 30, 2006 at 03:28:54PM +0000: > > On Thu, 2006-03-30 at 10:21 -0500, Daniel Chudnov wrote: > > > On Mar 30, 2006, at 3:11 AM, Robert Sanderson wrote: > > > > And I'm sure that OpenSearch people and OAI people and openURL people > > > > will all do the same, and claim unAPI conformance. > > > > > > With all due respect, that's absurd. > > > > I'm glad that you agree :) > > Actually, I meant that that I think it's absurd to think that OpenSearch, > OAI, and OpenURL people would do that and claim that. unAPI isn't > exactly the web2.0 buzzword of the day. (Yet.) Perhaps, but if you have a spec that allows it, you can't turn around and say that they're doing something wrong when it IS the buzzword of the day. Look at Z39.50 and how vendors claim to support it. Look at Microsoft and their embrace and extend policies. I'm sure that there's no need to define what 'specification' means, as opposed to 'guidelines' or 'recommendation'. > > > Your repeated statements regarding these issues seem to contradict > > > themselves in this regard. > > In what way? > You are against extensibility; that's fair. > You are also against an explicit, restrictive schema No? I argued that *lack* of a schema isn't going to put people off, which was Eric's original contention, I didn't argue that one should not be created. I don't think something so trivial as the formats response *requires* a schema, but it certainly doesn't hurt to have one. More, optional documentation never hurts anything. > or namespace I argue against the use of namespaces because they're demonstrably harder to deal with in a 2 hour implementation. So is extensibility in that you need to pick your way through garbage to get to what you actually need. It limits the potential choices of the way in which someone can implement. Limiting potential implementation strategies means that the people who would have done it that way need to find some other way to do it (or perhaps will think it's too troublesome and they won't bother, if there's no great reason for them to do the implementation) Ditto for URI vs identifier. > or > other avenues of discussion that call for locking down the spec so that > nothing else is allowed (unless you're simply for saying "nothing else > is allowed", which we haven't really floated, or if you or someone else > did, I'm sorry I missed it). That, by itself, is fair too. That's pretty much what I'm in favour of. Here is what you can do (and if you want a schema, here it is) and you can't add anything else to it. " The top level element in the response is . This can contain 1 or more elements, each of which describes a format in which the object can be returned. This element can contain the following elements: * name: The name of the format to put in the format request parameter * description: A url to a description of the format * (etc) Example: simpledc http://.... " Done. 1 paragraph plus example that explicitly lays out what can be in the response. No schema (though I'm not against it), no namespaces and no extensibility. If you DO want extensibility, then I recommend exactly what was suggested (and what has been done in SRU) -- have two slots for extra information... What I HAVE argued against is allowing arbitrary xml anywhere in the spec, distinguished by namespace or not. > But, I don't know how you can have the former without some expression > of the intent of the latter. See above. Rob -- Dr Robert Sanderson Dept of Computer Science, University of Liverpool Home: http://www.csc.liv.ac.uk/~azaroth/ Cheshire: http://www.cheshire3.org/