Actually, I think I agree with Roy's point here. He hasn't been entirely explicit with what he means by "architecture", but I think that's understandable in such a terse comment.
My guess is that the aspect of web "architecture" to which he refers is the fundamental separation between identification, retrieval, and representation: URIs identify things, we often (or usually) use HTTP to get them, and HTML is one of the ways we represent things. The argument is that if HTML goes monkeying around with the other two layers you're in danger of breaking something.
If people think they can come up with an identifier scheme that lets them guess things about the representation of a resource on the basis of its identifier they are violating the "architecture" of the web. I doubt the (on the whole, quite wise) authors of HTML5 have any intention of making such a mistake, but they court the possibility by claiming any authority over the internal structure of URIs. Better to just say "this bit of the syntax is a string that happens to be a URI, as defined by the official URI spec" than to dive into a URI's internal syntax.
Or at least that's my interpretation of what Roy is saying. You may disagree over whether this layering is in fact fundamental to the web's "architecture", but I think Roy does refer to a reasonable definition of that term.
Roy T. Fielding
· 1 year ago
I authored the HTTP and URI standards, participated in the original HTML 2.0 standardization, produced one of the first WWW client libraries, and cofounded the Apache project. I wrote my dissertation on the Web architecture and spent four years on the TAG explaining it to others and providing input to the webarch document. I have also written findings on the subject and there are at least a thousand archived emails from me on Web architecture, easily discoverable with a google search on w3.org.
Why on earth do you think I need to repeat that background, which should be obvious to anyone working on Web standards, in an email message sent to the HTML working group? The authors of HTML5 haven't even justified the WG goals, let alone developed a coherent architecture. Stop drinking the kool-aid and start thinking about how stupid it would be to repeat all of the IETF discussions on URI and HTTP within a mailing list that is already overloaded by HTML.
The architectural principle is separation of concerns, also known as the principle of orthogonality (orthogonal protocols deserve orthogonal specs). It is central to the Web architecture that identification is independent of (cannot be defined by) data formats. HTML is just one of many data formats on the Web. These are all facts that are not open to debate -- they are decisions that we made over a decade ago and reaffirmed by consensus of the TAG. Whether or not Ian agrees with the architecture is irrelevant.
FTR, it is categorically insane to believe that STD 66 is not "agreed to". It is a full IETF Standard with the full backing of the W3C and all of the vendors that the HTML5 group considers reference implementations. The issue here is not about what STD 66 defines (which is the set of identifier syntax that is entirely interoperable across all Web components) but rather what to do with strings that STD 66 considers invalid when they are encountered in the wild.
My suggestion is to treat them as invalid strings, not claim them as some special identifier to re-brand with the URL name, and thus achieve the same result of specifying browser behavior on invalid input *without* violating an international standard. The only technical difference between the two is that HTML5 will not instruct browsers to send invalid HTTP requests containing invalid URI references in the request-URI.
Bijan Parsia
· 1 year ago
Roy, I'm well aware of your background. I taught web architecture to MSc students last year and used your dissertation in my class (albeit critically).
I never said you needed to repeat your background. I just pointed out that your message conflated spec structure and system architecture and made no technical point. No more, no less. That still seems true.
(Your last paragraph is, indeed, technical. But it's a proposal, not a justification of that proposal. And it's hard to see how that proposal is justified by your architectural claims.)
Of course, I don't believe the web has an architecture, certainly not a prescriptive one. So we're going to be at odds from the start, since things like "TAG consensus" doesn't have evidentiary weight for me. Thus the fact of that consensus is also irrelevant.
You slide even in this message from spec considerations (orthogonal things deserve orthogonal specs) to system considerations (HTML is one data format). It's perfectly possible to have an orthogonal system architecture speced non-orthogonally without violating that system's orthogonality. It may be risky (because hard to manage), but it's certainly possible and logically independent.
Ian indeed asked for things to be specced orthogonally and was refused. This is why things ended up this way. But all this has been pretty clearly explained on list.
Clearly, further discussion in this vein would be useless. One thing that might be useful is for us to change dialectical roles, i.e., you argue my part and I argue yours.
Bijan Parsia
· 1 year ago
Oh, about "agreed to". I just meant that it's unclear whether it really reflects global consensus de jure. What organizations say, even in their public voice, and what they actually mean can come apart. If we buy "rough consensus and running code" then formal consensus may be less important that field consensus. So, I didn't mean that people weren't involved with a spec process and agreed to it. I just meant that that might not reflect existing consensus. That seems uncontroversial, so I apologize for the confusion.
All Comments
My guess is that the aspect of web "architecture" to which he refers is the fundamental separation between identification, retrieval, and representation: URIs identify things, we often (or usually) use HTTP to get them, and HTML is one of the ways we represent things. The argument is that if HTML goes monkeying around with the other two layers you're in danger of breaking something.
If people think they can come up with an identifier scheme that lets them guess things about the representation of a resource on the basis of its identifier they are violating the "architecture" of the web. I doubt the (on the whole, quite wise) authors of HTML5 have any intention of making such a mistake, but they court the possibility by claiming any authority over the internal structure of URIs. Better to just say "this bit of the syntax is a string that happens to be a URI, as defined by the official URI spec" than to dive into a URI's internal syntax.
Or at least that's my interpretation of what Roy is saying. You may disagree over whether this layering is in fact fundamental to the web's "architecture", but I think Roy does refer to a reasonable definition of that term.
Why on earth do you think I need to repeat that background, which should be obvious to anyone working on Web standards, in an email message sent to the HTML working group? The authors of HTML5 haven't even justified the WG goals, let alone developed a coherent architecture. Stop drinking the kool-aid and start thinking about how stupid it would be to repeat all of the IETF discussions on URI and HTTP within a mailing list that is already overloaded by HTML.
The architectural principle is separation of concerns, also known as the principle of orthogonality (orthogonal protocols deserve orthogonal specs). It is central to the Web architecture that identification is independent of (cannot be defined by) data formats. HTML is just one of many data formats on the Web. These are all facts that are not open to debate -- they are decisions that we made over a decade ago and reaffirmed by consensus of the TAG. Whether or not Ian agrees with the architecture is irrelevant.
FTR, it is categorically insane to believe that STD 66 is not "agreed to". It is a full IETF Standard with the full backing of the W3C and all of the vendors that the HTML5 group considers reference implementations. The issue here is not about what STD 66 defines (which is the set of identifier syntax that is entirely interoperable across all Web components) but rather what to do with strings that STD 66 considers invalid when they are encountered in the wild.
My suggestion is to treat them as invalid strings, not claim them as some special identifier to re-brand with the URL name, and thus achieve the same result of specifying browser behavior on invalid input *without* violating an international standard. The only technical difference between the two is that HTML5 will not instruct browsers to send invalid HTTP requests containing invalid URI references in the request-URI.
I never said you needed to repeat your background. I just pointed out that your message conflated spec structure and system architecture and made no technical point. No more, no less. That still seems true.
(Your last paragraph is, indeed, technical. But it's a proposal, not a justification of that proposal. And it's hard to see how that proposal is justified by your architectural claims.)
Of course, I don't believe the web has an architecture, certainly not a prescriptive one. So we're going to be at odds from the start, since things like "TAG consensus" doesn't have evidentiary weight for me. Thus the fact of that consensus is also irrelevant.
You slide even in this message from spec considerations (orthogonal things deserve orthogonal specs) to system considerations (HTML is one data format). It's perfectly possible to have an orthogonal system architecture speced non-orthogonally without violating that system's orthogonality. It may be risky (because hard to manage), but it's certainly possible and logically independent.
Ian indeed asked for things to be specced orthogonally and was refused. This is why things ended up this way. But all this has been pretty clearly explained on list.
Clearly, further discussion in this vein would be useless. One thing that might be useful is for us to change dialectical roles, i.e., you argue my part and I argue yours.