Re: A very preliminary draft of a URL spec
If you go for standardizing an API for dealing with URIs (probably a good idea if you go down this route) - then I would recommend being inspired by the API of Java's java.net.URI http://docs.oracle.com/javase/7/docs/api/java/net/class-use/URI.html The only thing that is not well handled by the above is IRIs (probably as the API predates IRIs). A defined API would have to be much more precise about which elements allow which international characters. On 13 May 2013 04:34, Charles McCathie Nevile cha...@yandex-team.ru wrote: Hi, to close ACTION-693 I scribbled some stuff into a very preliminary draft of a URL spec: https://dvcs.w3.org/hg/webapps/raw-file/81f24bfc5970/url/url.html In the end I didn't copy Anne's spec beyond believeing him about some Unicode points when I was offline. So far I have done nothing at all about an API, and am waiting for some formal confirmation from people who implement stuff that they would like to standardise an API for dealing with URLs. It seems to be a common task, judging from the number of people who seem to have some scrap of code lying around for it, so I expect to hear people say Yes, great idea - although I have been surprised before. As the more astute (read people who look at the spec for a few seconds with at least some level of attention) will notice, this needs work. I would be very pleased to receive comments that help clarify things the spec gets wrong, doesn't specify, or doesn't explain clearly. I hope there will be a bugzilla component really very soon, but I neglected to request one so far. If Mike happens to be reading, I'd be grateful for him to do the magic before I get around to writing the request. In the meantime I guess you should just reply to the thread... And no, it doesn't use futures. Sorry. At some point I will come back with the answer to a request for a way to change that. cheers Chaals -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com -- Stian Soiland-Reyes, myGrid team School of Computer Science The University of Manchester http://soiland-reyes.com/stian/work/
Re: A very preliminary draft of a URL spec
On Tuesday, May 21, 2013 at 10:12 AM, Stian Soiland-Reyes wrote: If you go for standardizing an API for dealing with URIs (probably a good idea if you go down this route) - then I would recommend being inspired by the API of Java's java.net.URI http://docs.oracle.com/javase/7/docs/api/java/net/class-use/URI.html We (the Web community) have had pretty bad experiences trying to apply Java's API idioms on the Web (e.g., the gawd awful DOM APIs). The Java URI also suffers from a lot of the same issues: great if you are working in Java, not so great for JS. Far more JS idiomatic examples: http://medialize.github.io/URI.js/ http://nodejs.org/api/url.html
Re: A very preliminary draft of a URL spec
On 13 May 2013 05:34, Charles McCathie Nevile cha...@yandex-team.ru wrote: Hi, to close ACTION-693 I scribbled some stuff into a very preliminary draft of a URL spec: https://dvcs.w3.org/hg/**webapps/raw-file/81f24bfc5970/**url/url.htmlhttps://dvcs.w3.org/hg/webapps/raw-file/81f24bfc5970/url/url.html In the end I didn't copy Anne's spec beyond believeing him about some Unicode points when I was offline. So far I have done nothing at all about an API, and am waiting for some formal confirmation from people who implement stuff that they would like to standardise an API for dealing with URLs. It seems to be a common task, judging from the number of people who seem to have some scrap of code lying around for it, so I expect to hear people say Yes, great idea - although I have been surprised before. As the more astute (read people who look at the spec for a few seconds with at least some level of attention) will notice, this needs work. I would be very pleased to receive comments that help clarify things the spec gets wrong, doesn't specify, or doesn't explain clearly. I hope there will be a bugzilla component really very soon, but I neglected to request one so far. If Mike happens to be reading, I'd be grateful for him to do the magic before I get around to writing the request. In the meantime I guess you should just reply to the thread... And no, it doesn't use futures. Sorry. At some point I will come back with the answer to a request for a way to change that. +1 Chaals, I welcome this effort It's tempting (especially on the whatwg ML) to think that the browser is the web. But the URL is used in many contexts in and outside the browser. Please do post the link to the issue tracker when it's up, and hopefully a some of us on WHATGW can help you and Anne in creating a stable and up to date home for this important work. cheers Chaals -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: A very preliminary draft of a URL spec
On 5/20/13 12:54 PM, ext Melvin Carvalho wrote: On 13 May 2013 05:34, Charles McCathie Nevile cha...@yandex-team.ru mailto:cha...@yandex-team.ru wrote: I hope there will be a bugzilla component really very soon, but I neglected to request one so far. Please do post the link to the issue tracker when it's up, and hopefully a some of us on WHATGW can help you and Anne in creating a stable and up to date home for this important work. The URL spec's bugzilla component is https://www.w3.org/Bugs/Public/buglist.cgi?product=WebAppsWGcomponent=URL
Re: A very preliminary draft of a URL spec
On Tue, May 14, 2013 at 4:24 AM, Charles McCathie Nevile cha...@yandex-team.ru wrote: On Mon, 13 May 2013 17:25:23 +0100, Anne van Kesteren ann...@annevk.nl wrote: What's wrong with the http://url.spec.whatwg.org/ URL standard. 1. It is apparently not intended to become a stable reference that can be used in situations where fixing every edge case is less important than fixing the content we agree we are looking at. As Anne noted, it's the edge cases that are *important* to resolve. We already have specs that define a bunch of the easy stuff, but they leave off the edge cases that allow interoperability. 2. It provides extremely detailed algorithms that certain classes of tools require to work with URLs, at the expense of an easily-read explanation of what is and isn't a URL. This is the work of an Intro section, or at most an Explainer document. Either would be welcome! The URL spec accepts pull requests. ^_^ 3. It does not provide any kind of license commitment from anyone likely to have patents on the technology described. URLs are old enough that this is less likely to be an issue than for many techs being specified today. Regardless, though, this is something that can be solved more easily by leaning on existing W3C process - spin up a community group, occasionally copy over a snapshot of the URL spec, and publish it as a Final Specification (or whatever the name is). This gives you patent coverage, and is basically mechanical. Not invented here? Ironically (given the history of URLs as used on the Web today), that is indeed a defensible explanation of one issue. For reasons including stability of the document content, WHAT-WG living standards are not suitable as normative references for W3C Recommendations. As you note, HTML essentially depends on having a sound reference. (For other mostly technical reasons I believe that RFC 3986 and perhaps to a lesser extent RFC 3987 are not especially suitable either, because the question is equally valid as to what is wrong with them). There is no process issue with normatively referring to WHATWG specs. Even if there was, see above for an easier solution to the problem than independently writing a parallel spec. You can go *even simpler* if you'd like, because the URL standard is freely licensed; just save a copy of the spec and send it to www-archive, or some other storage with a reasonably stable url, and refer to that instead. It would be silly and quickly outdated, but if that's what you're asking for, the option exists. If there are *actual problems* with the URL standard that you're trying to fix with your spec, I support the effort, though I believe it would be more fruitful to work with Anne on the existing URL spec. If, as your email suggests, you're trying to write this document solely because of perceived W3C Process issues, that's silly and I will oppose the publication of this spec, as it has far too much potential for accidental badness over the other, simpler options. ~TJ
Re: A very preliminary draft of a URL spec
On Mon, 13 May 2013 17:25:23 +0100, Anne van Kesteren ann...@annevk.nl wrote: On Sun, May 12, 2013 at 8:34 PM, Charles McCathie Nevile cha...@yandex-team.ru wrote: So far I have done nothing at all about an API, and am waiting for some formal confirmation from people who implement stuff that they would like to standardise an API for dealing with URLs. It seems to be a common task, judging from the number of people who seem to have some scrap of code lying around for it, so I expect to hear people say Yes, great idea - although I have been surprised before. Given that you're questioning this, I am not questioning whether it is a good idea. I am checking that it will actually get implementation - since a spec of things we think people should do, but they don't and probably won't is just an idea written down. Personally I don't think the Web is just what browsers will implement, since there are things (like microdata) that don't really need the browser at all in order to be important to the web. But in this case, as with most APIs I think browser implementations are particularly important. maybe you want to study HTML's dependencies. Sure, but making life easier for spec authors is not directed at the highest priority group in the hierarchy of audiences (much as I want to do it). It seems that's a problem overall. This draft doesn't go into detail about any of the problems for which HTML started defining URLs by itself in the first place. Sure. As I noted, it is extremely rough, and it is definitely missing more than it includes at this stage. What's wrong with the http://url.spec.whatwg.org/ URL standard. 1. It is apparently not intended to become a stable reference that can be used in situations where fixing every edge case is less important than fixing the content we agree we are looking at. 2. It provides extremely detailed algorithms that certain classes of tools require to work with URLs, at the expense of an easily-read explanation of what is and isn't a URL. 3. It does not provide any kind of license commitment from anyone likely to have patents on the technology described. The first two of these are only problems from a specific set of perspectives, but those perspectives happen to be ones that match real existing needs. I believe that the third is a non-issue in practical terms, given that most of what is specified has been around for long enough to ensure the existence of prior art, but it doesn't hurt to be surer about this. Not invented here? Ironically (given the history of URLs as used on the Web today), that is indeed a defensible explanation of one issue. For reasons including stability of the document content, WHAT-WG living standards are not suitable as normative references for W3C Recommendations. As you note, HTML essentially depends on having a sound reference. (For other mostly technical reasons I believe that RFC 3986 and perhaps to a lesser extent RFC 3987 are not especially suitable either, because the question is equally valid as to what is wrong with them). It is quite possible that the whole problem will go away, and one or more of these specifications will just happily disappear in deference to the rest. However, that's not currently the world we live in, and meeting W3C's interim need seemed a useful investment of some time. cheers Chaals -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: A very preliminary draft of a URL spec
On Tue, May 14, 2013 at 4:24 AM, Charles McCathie Nevile cha...@yandex-team.ru wrote: I am checking that it will actually get implementation - since a spec of things we think people should do, but they don't and probably won't is just an idea written down. Yeah, I think this shows that you have not actually checked HTML's dependencies and what is implemented today. a.protocol and such most definitely exist today and the way that is defined is through the URL Standard. And FWIW, the whole point of doing STD66 again is precisely about fixing edge cases and having that extremely detailed algorithm. If those did not matter we could just use STD66. -- http://annevankesteren.nl/
Re: A very preliminary draft of a URL spec
On Mon, 13 May 2013 04:34:32 +0100, Charles McCathie Nevile cha...@yandex-team.ru wrote: Hi, to close ACTION-693 I scribbled some stuff into a very preliminary draft of a URL spec: I made a couple of updates, including a pointer to the readable incarnation of the latest version: https://dvcs.w3.org/hg/webapps/raw-file/default/url/url.html I hope there will be a bugzilla component really very soon And there is one, linked. Further comments are still appreciated, obviously. cheers Chaals -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: A very preliminary draft of a URL spec
On Sun, May 12, 2013 at 8:34 PM, Charles McCathie Nevile cha...@yandex-team.ru wrote: So far I have done nothing at all about an API, and am waiting for some formal confirmation from people who implement stuff that they would like to standardise an API for dealing with URLs. It seems to be a common task, judging from the number of people who seem to have some scrap of code lying around for it, so I expect to hear people say Yes, great idea - although I have been surprised before. Given that you're questioning this, maybe you want to study HTML's dependencies. It seems that's a problem overall. This draft doesn't go into detail about any of the problems for which HTML started defining URLs by itself in the first place. What's wrong with the http://url.spec.whatwg.org/ URL standard. It seems way clearer and actually addresses those concerns. Not invented here? -- http://annevankesteren.nl/
Re: A very preliminary draft of a URL spec
On 13/05/2013 05:34 , Charles McCathie Nevile wrote: So far I have done nothing at all about an API, and am waiting for some formal confirmation from people who implement stuff that they would like to standardise an API for dealing with URLs. It seems to be a common task, judging from the number of people who seem to have some scrap of code lying around for it, so I expect to hear people say Yes, great idea - although I have been surprised before. An API manipulate URLs is a common need, and one that's often done in a buggy manner by libraries. So it's certainly something that I'd like to see happen. -- Robin Berjon - http://berjon.com/ - @robinberjon
Re: A very preliminary draft of a URL spec
On Sun, May 12, 2013 at 8:34 PM, Charles McCathie Nevile cha...@yandex-team.ru wrote: Hi, to close ACTION-693 I scribbled some stuff into a very preliminary draft of a URL spec: https://dvcs.w3.org/hg/webapps/raw-file/81f24bfc5970/url/url.html In the end I didn't copy Anne's spec beyond believeing him about some Unicode points when I was offline. So far I have done nothing at all about an API, and am waiting for some formal confirmation from people who implement stuff that they would like to standardise an API for dealing with URLs. It seems to be a common task, judging from the number of people who seem to have some scrap of code lying around for it, so I expect to hear people say Yes, great idea - although I have been surprised before. As the more astute (read people who look at the spec for a few seconds with at least some level of attention) will notice, this needs work. I would be very pleased to receive comments that help clarify things the spec gets wrong, doesn't specify, or doesn't explain clearly. I hope there will be a bugzilla component really very soon, but I neglected to request one so far. If Mike happens to be reading, I'd be grateful for him to do the magic before I get around to writing the request. In the meantime I guess you should just reply to the thread... And no, it doesn't use futures. Sorry. At some point I will come back with the answer to a request for a way to change that. I'm also curious about what the purpose of this draft is. There's nothing wrong with pursuing an idea in multiple places (so long as we settle on one eventually), but this message doesn't even mention what you think is wrong with Anne's spec which your spec is intended to fix. ~TJ
A very preliminary draft of a URL spec
Hi, to close ACTION-693 I scribbled some stuff into a very preliminary draft of a URL spec: https://dvcs.w3.org/hg/webapps/raw-file/81f24bfc5970/url/url.html In the end I didn't copy Anne's spec beyond believeing him about some Unicode points when I was offline. So far I have done nothing at all about an API, and am waiting for some formal confirmation from people who implement stuff that they would like to standardise an API for dealing with URLs. It seems to be a common task, judging from the number of people who seem to have some scrap of code lying around for it, so I expect to hear people say Yes, great idea - although I have been surprised before. As the more astute (read people who look at the spec for a few seconds with at least some level of attention) will notice, this needs work. I would be very pleased to receive comments that help clarify things the spec gets wrong, doesn't specify, or doesn't explain clearly. I hope there will be a bugzilla component really very soon, but I neglected to request one so far. If Mike happens to be reading, I'd be grateful for him to do the magic before I get around to writing the request. In the meantime I guess you should just reply to the thread... And no, it doesn't use futures. Sorry. At some point I will come back with the answer to a request for a way to change that. cheers Chaals -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
