gmane.org.w3c.uri

Re: URI spec production path-empty uses prose-val ABNF mechanism on purpose?

Roy T. Fielding — 2008-11-18T20:12:56

On Nov 17, 2008, at 10:12 PM, Dan Connolly wrote: probably not, but it is more readable than path-empty = 0pchar I probably should have used path-empty = 0*0(pchar) but it really doesn't make any difference. BTW, the current ABNF ref is RFC5234. ....Roy

URI spec production path-empty uses prose-val ABNF mechanism on purpose?

Dan Connolly — 2008-11-18T06:12:00

I'm trying to do some automated processing of the URI spec, and I bumped into: path-empty = 0 I wonder if those <> are there on purpose. I suppose it doesn't matter; 0 repetitions of anything is the empty string. I doubt this mechanism was invoked on purpose, though: prose-val = "<" *(%x20-3D / %x3F-7E) ">" ; bracketed string of SP and VCHAR without angles ; prose description, to be used as last resort http://tools.ietf.org/html/rfc2234#page-9 for reference... this path-empty production shows up in the issues list under 02 Apr 2004, draft 05 http://labs.apache.org/webarch/uri/rev-2002/issues.html#044-empty-path I also traced it down in SVN: http://svn.apache.org/repos/asf/labs/webarch/tags/uri/draft-05/rev-2002/rfc2396bis.xml 503091 fielding path-empty = 0<pchar> r503091 | fielding | 2004-04-01 19:01:20 -0600 (Thu, 01 Apr 2004) | 2 lines fi

uriparser 0.7.3 released

Sebastian Pipping — 2008-11-08T20:22:41

Hello! This release offers a wild mix of things. Mainly it makes uriparser build on Cygwin (packager wanted!), fixes a small bug with parsing reported by Sezai Tekin, and adds Qt Compressed Help (.qch) output for viewing the API documentation in Qt Assistant. This release is both source- and binary-compatible. Download: http://sourceforge.net/project/showfiles.php?group_id=182840 Changelog: http://sourceforge.net/project/shownotes.php?release_id=639066&group_id=182840 Sebastian

Re: URI Templates: done or dead?

Robert Brewer — 2008-11-06T22:02:09

Roy Fielding wrote: So we have constructions for empty variables and undefined variables producing valid URI's. What I have yet to see in either proposal (but is in e.g. WADL) is a way to specify that a given expansion variable MUST be defined, else raise an error because no valid URI can be constructed if it is missing. For example, if I have the desired target URI "/users/1234/first_name", I can't write "/users/{user_id}/first_name" (using Joe's URI Template draft-03) because that will allow "/users//first_name" if user_id is undefined. I don't think I can use the above (which otherwise looks quite nice) for the same reasons. Perhaps a trailing "!" could be used to require certain variables, e.g. "{?x,y,undef!}" Thoughts? Am I missing some glaring interop principle by wanting this? Robert Brewer fumanchu< at >aminus.org

RE: [rest-discuss] RE: [whatwg] Proposing URI Templates for WebForms 2.0

Mike Schinkel — 2008-11-05T21:25:59

Subbu Allamaraju wrote: follow the same techniques that HTML clients follow *today*. I must be missing something but I don't see how that's a problem. Why can't HTML be used for a web service representation? -Mike Schinkel http://mikeschinkel.com

Re: [rest-discuss] RE: [whatwg] Proposing URI Templates for WebForms 2.0

Erik Wilde — 2008-11-04T19:01:49

hello. supported representations can be determined dynamically by content negotiation, and the idea would exactly be that there is no difference between these two things you call "API server" and "web server". they are RESTful servers supporting RESTful interactions. some of them may decide to support XHTML representations, others may not. but i don't think we should make that distinction of servers; on the contrary, i think the web should take every step possible into a direction where that perceived difference between "API servers" and "web servers" disappears, and where technologies that somehow create that distinction (such as HTML forms) are fixed (with reasonable transition strategies in place). cheers, dret.

Re: [rest-discuss] RE: [whatwg] Proposing URI Templates for WebForms 2.0

Subbu Allamaraju — 2008-11-04T18:24:40

On Nov 1, 2008, at 11:38 AM, Erik Wilde wrote: Not sure how you came to that conclusion, but I find that argument a stretch. If I understand correctly, Mike's argument for supporting templates is to avoid requiring JS support. So, a RESTful server that needs to be consumed by a browser without requiring JS support has just one option - that is to use a media type that can be recognized by browsers, which is HTML. That is, it uses (X)HTML representations, supports query parameters and forms. The so-called API server therefore becomes a web server. I can understand the merits of URI template support for HTML on its own, but I don't think it is correct to argue that such a support will make it easy to consume APIs. Sincerely, Subbu --- http://subbu.org

Re: Fwd: Mac number and IP address as URIs

Dan Connolly — 2008-11-04T15:28:50

Lisa Dusseault wrote: [...] I've seen dns: and tcp: in the REBOL stuff, but not ip: nor mac: I just did a little gardening in a wiki of URI schemes... http://esw.w3.org/topic/UriSchemes/dns http://esw.w3.org/topic/UriSchemes/ip http://esw.w3.org/topic/UriSchemes/mac

Status of URI Templates?

Mike Schinkel — 2008-11-02T01:13:11

Hi All: As you have seen I'm trying to get URI Templates to be usable in HTML5 forms as a template attribute in place of action attributes. I posted about it here back in Jan 2007: http://blog.whatwg.org/proposing-uri-templates-for-webforms-20 But in order for it to be included I'm sure URI Templates will need to be finalized. Where are we with URI Templates and would any of those of you who are interested in URI Templates like to see if be used in HTML5 forms? Thanks in advance. -Mike Schinkel http://mikeschinkel.com

path to daylight? for foo-templates in web markup [was: Re: [whatwg] Proposing URI Templates ...]

Al Gilman — 2008-11-01T23:37:01

On 1 Nov 2008, at 8:27 AM, Mike Schinkel wrote: For a community that's sold on pattern templates and a design based on a broader application thereof, look at the use of Attribute Value Templates in Content Selection for Device Independence http://www.w3.org/TR/cselection/ If you were to do your applications in cselection+foo (a profile formerly known as DIAL) with all the pattern-driven structure in them, and serve them first through a DI engine that downcasts to whatever passes for HTML of date, then at least for the disabled consumers who had the services of a trained content-adaptor (on their client machines) they could send you a "source, please" request and you would know that your templates were in coping hands. This affords a possible migration path to wider uptake if personalization processing gradually becomes a must have for browsers through popular demand as it leaks out of the niches where the early adopters live. To catch up on where this community is with this idea

Re: [rest-discuss] RE: [whatwg] Proposing URI Templates for WebForms 2.0

Erik Wilde — 2008-11-01T18:38:02

Subbu Allamaraju wrote: that is certainly true. but i think there are cases where this already would be useful on today's web. if you consider services exposing information through GData, for example, then mike's proposal would make it possible to simply write a web form for these services. there already are quite a number of GData services out there, but i agree that for a long time to come, dedicated form-processing services will remain the norm. of course the installed base of code assuming that services are designed specifically for form-data processing is huge. and i do understand the hesitation to look beyond forms, because they are so popular and wide-spread. but really, RESTful services in non-form flavors are becoming more popular and more widespread, and i think it's safe to say that this is a long-term trend. that is a circular argument. and in many cases, if you are building a RESTful service primarily intended as an API, then URI design for it will look very different from form

Re: [rest-discuss] RE: [whatwg] Proposing URI Templates for WebForms 2.0

Erik Wilde — 2008-11-01T17:01:15

Subbu Allamaraju wrote: the question is more how many page authors will be able to reliably develop forms against services/servers? i think mike's idea is pretty good because it increases loose coupling between clients and servers. on today's web, forms and services are more or less tightly coupled, and they almost are developed as one thing. mike proposes an architecture that introduces a more loose coupling, because a form is able to interact with more services than before. ( mike, please correct me if i am wrong. ) yes, but if you have some service out there that expect certain URIs, then currently it is not possible to build a form for that, unless the service does expect form-encoded data. mike's proposal would allow forms to interact with a much wider set of services. cheers, dret.

Re: [whatwg] Proposing URI Templates for WebForms 2.0

Al Gilman — 2008-11-01T15:20:44

On 31 Oct 2008, at 6:37 PM, Mark Nottingham wrote: ** pro Let me suggest two threads of reasoning that I believe make it plausible that doing these specializations with declarative patterns is better for accessibility than doing it in imperative script. 1. Pattern-ist dyslexics Some dyslexics are extreme pattern-ists. How can I explain this concept? Well, there is another class of cognitive condition sometimes called 'semantic pragmatic' in which people are extremely literal in their interpretation of terms. The semantic-pragmatic individual does not interpret simile and allusion well. Patternists are the opposite of this, preferring a projective development of an idea as an intersection of known ideas to a constructive development as a union of known facets. Some people are extreme patternists, and we know them as dyslexics because of the pointillist operating point of our written language. The language assumes more atomicity to terms and concepts than what obtains in the mental calculus whe

How to encode URL for HTTP over unix domain sockets?

Claes H — 2008-10-09T19:47:10

Hello, What would be a good way to encode URLs for communication using HTTP over Unix domain sockets? For example to implement a service locally: Rather than serving it from http://www.example.com/service, to do it from a socket on the file system named /tmp/daemon.socket be encoded as the 'host' part of the authority, in a way that can not be confused with domain name addresses or IP addresses. So lets say we would put a character from sub-delims in front, such as '!', to make it invalid as any current HTTP URL. Then we get !/tmp/daemon.socket. Next we percent-encode it and add the scheme and path parts. Then we get http://!%2Ftmp%2Fdaemon.socket/service Playing a little bit with sub-delims, here are some variants: http://filesystem,%2Ftmp%2Fdaemon.socket/service http://socket;%2Ftmp%2Fdaemon.socket/service Have I interpreted the specs correctly? Of course, this is not compliant with HTTP as defined by RFC2616, but I am curious about valid ways to extend this. Background: I have for a while wonder

Re: URI Templates: done or dead?

John Cowan — 2008-09-17T02:28:39

Roy T. Fielding scripsit: Yes, they are valid; no, a URI is not an opaque bytestream wrapped in ASCII. There are only two mentions of bytes in RFC 3986: one that denies that URIs must be byte-by-byte identical to be identical (i.e. they may have different encodings as bytes), and another (irrelevant here) explaining about how bytes in IP addresses are encoded. Allowing ASCII-only mantains maximum compatibility across implementations.

Re: URI Templates: done or dead?

John Cowan — 2008-09-17T02:22:11

Phillips, Addison scripsit: +1. NFC is appropriate.

RE: URI Templates: done or dead?

Phillips, Addison — 2008-09-17T02:16:55

... which effectively means that the template processor does not apply any form of normalization. NFC should have been used early; if it wasn’t, for some reason, IRI doesn't impose it. Note the point, though, about include-normalization. Consider: http://example.org/{boo}{moo} Let 'boo' = 'e' Let 'moo' = '\u0301' (a combining mark) The resulting URI is not NFC, even though each of the parts is. Addison

Re: URI Templates: done or dead?

William A. Rowe, Jr. — 2008-09-17T00:28:07

Phillips, Addison wrote: You are correct; NFC is appropriate here... 3.1 [Step 1]... a. If the IRI is written on paper, read aloud, or otherwise represented as a sequence of characters independent of any character encoding, represent the IRI as a sequence of characters from the UCS normalized according to Normalization Form C (NFC, [UTR15]). although in the other cases, the server performs no normalization, this clause effectively states that only NFC needs to be honored. Which means NFKC is truly out of place in the -03 draft. Similarly, if the template processor relies on user input, it should be subjected to NFC per RFC 3987, while if it's a machine value, the NFC form should have been used in the first place.

Re: URI Templates: done or dead?

Mark Nottingham — 2008-09-17T00:03:28

On 16/09/2008, at 12:28 PM, Roy T. Fielding wrote: Yes, there are a number of editorial issues in -03, but some technical decisions need to be made (or the current design agreed to) before they can be addressed. After simple string substitution, yes. I agree that typed functions are unnecessary. I can live with accommodating lists in the 'standard' operators as long as their impact is minimal. The area that I'm concerned about here is the case where a template is supplied to someone who inserts a variable into it, and the variable can appear anywhere. For example, if the value "email" is an e-mail address, "nottingham/mark< at >example.org ", and the following template is supplied; http://example.net/{email}/ which would expand to http://example.net/nottingham%2Fmark%40example.org/ whereas the template http://example.net/{+email}/ would expand to http://example.net/nottingham/mark< at >example.org/ which isn't what's desired; http://example.net/nottingham%2Fmark< at >example.org/

Re: URI Templates: done or dead?

Mark Nottingham — 2008-09-17T00:03:50

Joe, where can we find your issues list? On 16/09/2008, at 1:09 PM, Joe Gregorio wrote: -- Mark Nottingham http://www.mnot.net/

Re: URI Templates: done or dead?

Roy T. Fielding — 2008-09-16T23:39:06

On Sep 16, 2008, at 4:08 PM, William A. Rowe, Jr. wrote: Yes, so one answer would be to allow percent-encoded-UTF-8 in the variable names as well. That would address the issue of external field names being non-ASCII without introducing the horror of non-octet-based name comparisons. ....Roy