I think that many current COinS parsing systems may get tripped up by this.
For instance, the Openly Firefox extension seems to pass whatever it finds directly to the browser. (No offense meant if I'm wrong, just a cursory inspection). Which means that if the COinS is _not_ URL-encoded, then it's technically requesting an illegal URL---although Firefox seems to be generous enough to forgive the mistake and fetch the URL anyways. Contariwise, I've been told that the Zotero parser will not correctly handle URL-encoded COinS. I see what you're saying about leaving it flexible, though. But I think more specific guidance is needed. Erik's point that officially a URL _can_ be encoded is important. I think the ocoins.info document should say that processors should be prepared to look at the COinS as a URL-encoded string, that is, be prepared to un-escape any encoded characters it finds. So a processor that did not do the right thing with URL-encoded data would be clearly in error. The document can further say that producers are _encouraged_ to supply a COinS that is a valid URL-encoded string. (Not encouraged to encode every char, but encouraged to encode : and /, neccesary to make it a valid URL-encoded string.) Producers are of course required to escape properly to make it a valid HTML attribute, since it is one---I don't think it would hurt to say this explicitly. Encoding gets awfully confusing, and what's obvious to someone who has been thinking about this stuff for a while might not be obvious to a newcomer. And it definitely needs to be said that you are _allowed_ to URL-encode a COinS, if you are---the current documentation gives only one example, one where no URL encoding has taken place, leading some people to believe that url-encoding is not allowed. Producers would not then be _required_ to supply a valid URL-encoded string. But this means that if a processor plans on turning a COinS into a URL (which I'm guessing is not an unusual situation)---the processor is responsible for _determining_ if the COinS is properly URL-encoded, and then properly URL-encoding it if it is not. Because that's what needs to happen to turn it into a proper URL (eg, as the Openly Firefox extension does). Is it trivial to detect if a string requires url-encoding or not? I'm not sure (like I said, encodings still confuse me!). If it is, this is not a problem, although I still think it would be a good idea to make it clear in the document that Processors can run into this problem and are responsible for dealing with it. If it's a non-trivial thing to do, this detection---might want to re-think whether url-encoding should be left optional. Jonathan On Dec 11, 12:59 pm, 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. > > If your COinS processing system gets tripped up by the unimportant > details of the URLEncoding, I would say your system could use fixing. > Check your utf8 implementation while you're at it! > > 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 > 07003http://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 -~----------~----~----~----~------~----~------~--~---
