Talk:Uniform Resource Identifier

Untitled

For discussions before content was merged into this article in 2015, see Talk:URI scheme.

Syntax diagram

The syntax diagram added to the section General syntax, Definition was generated by the Railroad Diagram Generator using the following code:

URI ::= 'scheme' ':' ('//' (userinfo '@')? host (':' port)?)? path ('?' query)? ('#' fragment)?

based on the code in the two boxes above it.

--Ennex2 (talk) 14:46, 21 September 2018 (UTC)

Suggestion

Suggest URI resolution redirect here. — Preceding unsigned comment added by 96.40.48.159 (talk) 11:00, 2 July 2020 (UTC)

 Done Good idea.  — Scott • talk 12:56, 2 July 2020 (UTC)

@Scott 46.213.81.83 (talk) 23:43, 11 August 2023 (UTC)

Change syntax diagram

Shouldn't we changes the syntax diagram? For relative URIs the scheme part is optional.
I mean "img/button.jpg" is a valid (relative) URI.

Something like:
URI ::= ('scheme' ':')? ('//' (userinfo '@')? host (':' port)?)? path ('?' query)? ('#' fragment)?

If the scheme is absent, the first path segment is not allowed to contain a ":" — Preceding unsigned comment added by Grandswiss (talk • contribs) 11:02, 20 August 2020 (UTC)

Schemes all still have to get resolved at some point. I would almost even assert that scheme alone is URI. It's a naming scheme for resources. Check out the syntax diagram syntax diagram. Going straight across from end to start, the line connects; data as a path, to a name or identifier. The IANA keeps records of the resource names. Simillarly to how ICANN connects hostnames to ip-addresses. And finally since everything is all uniform like using HTTP we can just assume all requests are HTTP not include it, and do little resolving if needed. --Flybird.dev (talk) 15:09, 5 June 2022 (UTC)

based on the https://datatracker.ietf.org/doc/html/rfc3986#section-3.2 :

  The authority component is preceded by a double slash ("//") and is
  terminated by the next slash ("/"), question mark ("?"), or number
  sign ("#") character, or by the end of the URI.

However a path dosen't have to start with "/".

I feel that the article diagram is misleading and suggest that / isn't a must between the authority and path. Also part of the misleading is that according to the diagram path must be included but it can be empty.

suggested solution: change the diagram to something like:

  URI ::= 'scheme' ':' ('//' (userinfo '@')? host (':' port)? ('/' path)? | path) ('?' query)? ('#' fragment)?

Or maybe add a clarification in the paragraphs after the scheme. — Preceding unsigned comment added by Avizipi (talk • contribs) 07:31, 16 June 2021 (UTC)

Syntax Section

Usually when I see tags on articles like this that say "this may be too technical" I roll my eyes and think "this is a technical topic, what do you expect?" but the whole section on the syntax of URIs seems to be really gory detail. I work with URIs (actually IRIs now which is the more recent term but essentially the same thing) every day and I've never gotten into that kind of detail. I haven't read the section carefully but my initial reaction was is it even necessary to get into that much detail? That kind of detail seems more relevant to a wikibook or blog not an encyclopedia that is for a general audience. I'm going to look at the whole article in more detail and try to address some of the tags but I just wanted to see if other people had opinions on that syntax section, if it should even be kept? --MadScientistX11 (talk) 20:28, 5 December 2020 (UTC)

I just noticed at the top that this article was listed as a Good Article by the Engineering task force. Also, as I read the syntax section it looks well written, I actually learned some things so my preference now is to keep it unless others strongly disagree. --MadScientistX11 (talk) 17:57, 6 December 2020 (UTC)

I agree about the fact of keeping all technical details because URIs are something that nowadays more than one billion of people surfing Internet / the web have to manage. I mean that even a non technical user using only a browser might find very useful certain explanations in order to avoid mistakes or misunderstandings (i.e. many products have references / links to web sites using URIs, etc.). I have added a "NOTE" to "path" item about the "pathinfo" sub-part of an http URI in order to make more understandable the links to "clean URL" and "slug". --Ade56facc 15:30, 5 November 2021 (UTC)

Changed intro

I rewrote the intro to hopefully make it more understandable to a non-technical audience and to use a 3rd party reference. Here is the original text that I replaced:

A Uniform Resource Identifier (URI) is a string of characters that unambiguously identifies a particular resource. To guarantee uniformity, all URIs follow a predefined set of syntax rules, but also maintain extensibility through a separately defined hierarchical naming scheme (e.g. http://). Such identification enables interaction with representations of the resource over a network, typically the World Wide Web, using specific protocols. Schemes specifying a concrete syntax and associated protocols define each URI. The most common form of URI is the Uniform Resource Locator (URL), frequently referred to informally as a web address. More rarely seen in usage is the Uniform Resource Name (URN), which was designed to complement URLs by providing a mechanism for the identification of resources in particular namespaces.

I think the problem with the intro as it now stands is that it says a URI "provides a unique address" where a "resource may be found". This isn't true of all URIs. Many URN schemes provide names only, no addressing mechanism. Even a URL can be a valid URI without resolving to a resource. -- Phil Barker 11:11, 22 December 2020 (UTC)

If I'm understanding you correctly you are saying one can have a valid URI even though there is no resource there. Which is true but seems to me to be a point of detail that would confuse non-technical people and belongs somewhere in the article not in the introduction. Why would you ever have such a URI to begin with? It seems to me it would virtually always be an error and discussing errors or outliers to a topic belongs in the details of the article not the introduction. I can imagine writing a program where you construct the URI first and then link it to the resource later (or maybe you discard it because it turns out you don't need the resource). But again that seems like a very detailed point not appropriate to the introduction. If I'm missing your point please give me a bit more detail or an example. Thanks. --MadScientistX11 (talk) 19:06, 22 December 2020 (UTC)

What I am saying is that the URI does not have to resolve to a resource. It doesn't even have to try--not all URIs are URLs, see [Uniform_Resource_Name]. URN:ISBN:0471597821 is a valid URI, with no associated protocal. And yes, even http URIs don't need to resolve to the resource they identify: mine is http://people.pjjk.net/phil/#id which identifies me (NB: not my webpage) but will never resolve to me (it redirects to my webpage, but would still identify me even if it didn't). This is key to the use of URIs in RDF. If there is an error, it is a 404 error, i.e. an error on the part of the browser, not the identifier. Phil Barker 14:52, 5 January 2021 (UTC)

I made some edits which I hope keep the introduction simple and I think avoid misleading oversimplifications. Phil Barker 13:00, 6 January 2021 (UTC)

References

Currently all the references (except a couple of new ones I added) redirect to citations in the Further Reading section. I think this is confusing to the user and not the standard behavior I've seen in articles. Especially since IMO many of the citations in the Further Reading section don't meet the criteria for that section although they do meet the criteria for reference of specific points. So I'm converting the references to traditional citations with the citation in the Reference section and I'm deleting the ref from the Further Reading section unless I think it really merits inclusion, e.g., is some classic book or article on the topic. --MadScientistX11 (talk) 00:13, 6 December 2020 (UTC)

Also, I plan to address the tag about not enough 3rd party references. I've already done that a bit in the intro. But so for, while I agree many of the references are to relatively obscure pages from W3C working groups, the ones I've checked all seem to be good references. Again, as someone who works in the field, I'm finding them interesting so unless I find dead links or really obscure refs my plan is to keep the existing refs but also add more 3rd party ones. --MadScientistX11 (talk) 18:01, 6 December 2020 (UTC)

One more thing: I've noticed that some of the refs are direct links to external sites. That is clearly a violation of Wikipedia referencing standards so I will change all those as well to inline citations with the links in the reference section. --MadScientistX11 (talk) 19:18, 6 December 2020 (UTC)

DOCTYPE Puzzle

Readers of this page may be interested in thw following discussion:

• Wikipedia:Reference desk/Computing#DOCTYPE Puzzle

--Guy Macon (talk) 22:37, 1 June 2021 (UTC)