On 12/11/06, Eric Hellman <[EMAIL PROTECTED]> wrote: > > I think it would be a grave mistake to decide on one or the other- > the systems that produce COinS are less flexible in being able to > alter URLEncoding behavior (typically done by a library routine) than > are processing systems.
Where are you basing this? I would imagine the systems that are producing COinS are doing it via some 'COinS-production-library' (tm). Why can this not URLencode the string? > > If your COinS processing system gets tripped up by the unimportant > details of the URLEncoding, I would say your system could use fixing. Eh? What does this mean? It's a /lot/ more expensive to figure out if a string is URLencoded and do (or undo or not do) something about it then to know beforehand that it's URLencoded or not. What is the benefit to ambiguity? Why bother with this? To explicitly state in the spec whether or not it should be URLencoded or not would alleviate a hell of a lot of unnecessary frustration. > Check your utf8 implementation while you're at it! Again, what's this? The difference here is that a COinS should be /assumed/ utf8 unless /explicitly stated otherwise/. I think that's the freaking point. You /know/ what you're looking at so you don't have to guess. This is the point of a spec. -Ross. > > Eric > > > At 12:40 PM -0500 12/11/06, Ross Singer wrote: > >Eric, > > > >I think the ambiguity might come in parsing them in place. Should we > >decide on one or the other just so a parser knows what it's looking > >at? > > > >-Ross. > > > >On 12/11/06, Eric Hellman <[EMAIL PROTECTED]> wrote: > >> > >> either one should work; url encoding of the "KEV context object" is > >> governed by encoding rules for URIs in general- any character MAY be > >> url encoded; Very strictly speaking, the characters ":" and "/" are > >> required to be URL encoded, but in practice, leaving them unencoded > >> should be harmless. > >> > >> I'll look at the COinS spec to see where this might be clarified > >> > >> > >> At 5:09 PM +0000 12/11/06, jrochkind wrote: > >> >Hi all. > >> > > >> >The ocoins.info "spec" contains an example which includes: > >> > > >> >&rft_val_fmt=info:ofi/fmt:kev:mtx:journal > >> > > >> >When I first saw that, I thought, gee, shouldn't that be > >> >escaped/encoded somehow? If I were creating an SAP1 KEV context object, > >> >I believe (I confess escaping/encoding still confuses me) would need to > >> >encode this like: > >> > > >> >&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal > >> > > >> >If I'm putting an SAP1 KEV context object into my COinS, then I'd think > >> >I'd leave it alone just like that---except the example makes different > >> >choices about escaping. > >> > > >> >Nowhere in the ocoins.info "spec" is the word escape or escaping > >> >mentioned, or encode/encoding in the context of this question. So it's > >> >a bit confusing what is supposed to be reccommended/required here. All > >> >we have is the example to look at. > >> > > >> >Can we get some clarity as to how a COinS should be encoded/escaped, > >> >and maybe put it on ocoins.info? To me, again, a COinS should probably > >> >be encoded just like a SAP1 KEV, and then nobody needs to specify > >> >anything else. Or at least that should be an option that applications > >> >are required to support (it's been suggested to me that Zotero may not > >> >support escaped COinS). If you aren't going to say "just like" > >> >something else, then I guess ocoins.info needs to spell out how things > >> >should be escaped/encoded itself. One way or another, the current > >> >vagueness and spec only by one example seems to be leading to > >> >confusion? > >> > > >> >Thanks, > >> >Jonathan > >> > > >> > > >> > > >> > >> -- > >> > >> Eric Hellman, Director OCLC Openly > >> Informatics Division > >> [EMAIL PROTECTED] 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 > >> > >> > > >> > >> > > > > > > -- > > Eric Hellman, Director OCLC Openly > Informatics Division > [EMAIL PROTECTED] 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 > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "gcs-pcs-list" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/gcs-pcs-list?hl=en -~----------~----~----~----~------~----~------~--~---
