Architecture of the World Wide Web, First Edition

1.1.1. Audience of this Document

This document is intended to inform discussions about issues of Web architecture. The intended audience for this document includes:

1. Participants in W3C Activities; i.e., developers of Web technologies and specifications in W3C
2. Other groups and individuals developing technologies to be integrated into the Web
3. Implementers of W3C specifications
4. Web content authors and publishers

Readers will benefit from familiarity with the Requests for Comments (RFC) series from the IETF, some of which define pieces of the architecture discussed in this document.

1.1.2. Scope of this Document

This document presents the general architecture of the Web. Other groups inside and outside W3C also address specialized aspects of Web architecture, including accessibility, internationalization, device independence, and Web Services. The section on Architectural Specifications includes references.

This document strikes a balance between brevity and precision while including illustrative examples. TAG findings are informational documents that complement the current document by providing more detail about selected topics. This document includes some important material from the findings. Since the findings evolve independently, this document also includes references to approved TAG findings. For other TAG issues covered by this document but without an approved finding, references are to entries in the TAG issues list.

1.1.3. Principles, Constraints, and Good Practice

The sample principle "self-descriptive markup" makes me nervous: surely the TAG does not believe that XML (or any other system) is a self-describing format in the sense that anyone looking at any instance of the format will understand what is going on without having to have recourse to any documentation? Neither XML nor any other format or notation matches this description. Some formats are or can be self-describing in that the notation can be used to describe the notation: one can write a grammar in BNF for BNF itself, and one can write a schema in XML to define the XML vocabulary for writing schemas. But such recursion is possible, surely, primarily for notations which are intended to be used for defining notations.

The TAG resolved to keep the drop shadow for aesthetic reasons.

issue msm2: WD-webarch-20031209, 1.1.3: Self-descriptive markup considered improbable
error decided 2004-03-04

[[Authors of protocol specifications in particular should invest time in understanding the REST model and consider the role to which of its principles could guide their design: statelessness, clear assignment of roles to parties, uniform address space, and a limited, uniform set of verbs.]]

This sentence has an "interesting" structure. For one thing, "the role to which of its principles could guide their design" seems to mix several more usual constructions, e.g., either "the role its principles could [or should] *play* in their designs" or "the *extent* to which each of its principles could [or should] guide their designs". For another, it seems as if the list of principles should follow "principles" rather than "design", as in something like: "Authors of protocol specifications in particular should invest time in understanding the REST model and consider the role its principles -- statelessness, clear assignment of roles to parties, uniform address space, and a limited, uniform set of verbs -- could play in their designs.

issue manola5: Sentence on understanding REST model unclear
clarification raised 2004-03-10

The important points of this document are categorized as follows:

Constraint

An architectural constraint is a restriction in behavior or interaction within the system. Constraints may be imposed for technical, policy, or other reasons.

Design Choice

In the design of the Web, some design choices, like the names of the <p> and <li> elements in HTML, or the choice of the colon character in URIs, are somewhat arbitrary; if <par>, <elt>, or * had been chosen instead, the large-scale result would, most likely, have been the same. Other design choices are more fundamental; these are the focus of this document.

Good practice

Good practice — by software developers, content authors, site managers, users, and specification writers — increases the value of the Web.

Principle

An architectural principle is a fundamental rule that applies to a large number of situations and variables. Architectural principles include "separation of concerns", "generic interface", "self-descriptive syntax," "visible semantics," "network effect" (Metcalfe's Law), and Amdahl's Law: "The speed of a system is determined by its slowest component."

Property

Architectural properties include both the functional properties achieved by the system, such as accessibility and global scope, and non-functional properties, such as relative ease of evolution, re-usability of components, efficiency, and dynamic extensibility.

This categorization is derived from Roy Fielding's work on "Representational State Transfer" [REST]. Authors of protocol specifications in particular should invest time in understanding the REST model and consider the role to which of its principles could guide their design: statelessness, clear assignment of roles to parties, uniform address space, and a limited, uniform set of verbs.

1.2.1. Orthogonal Specifications

The reviewer explained why "orthogonality" was the wrong term to use. See email for details.

The TAG believes that "orthogonal", not "independent" is the proper term. E.g., the HTTP specification depends on the URI specification, but they are orthogonal. The TAG also decided to remove the term "loosely coupled" and to change "independent" to "may evolve independently."

issue gilman2: orthogonality is not the answer
error decided 2004-03-04

The first paragraph of this section is incomprehensible to me; I hope it can be rewritten.

What does it mean to define an identifier without knowing what representations are available? Representations for what? For the identifier? For the thing identified? For something else entirely? In general, I would have thought that before assigning identifiers to things it would normally be useful to know what one was identifying. In programming languages, what one identifies with identifiers are typically representations of things (representations of integers, representations of character strings, etc.); in that context, it seems nonsensical to say without qualification (as is done here) that identifiers can be assigned without any knowledge about available representations; it is only a knowledge of the available representations and their characteristics that allows one to decide intelligently what different things need to be distinguished and thus what different things will need to be identified.

Overtaken by events.

issue msm3: WD-webarch-20031209, 1.2.1 para 1: Assigning identifiers without knowing about representations
error decided 2004-03-04

It's clear that the world would be a better place if specifications were more consistently implemented and their nuances more consistently observed. It's not quite clear to me that the world will be a better place if we assign all authority for document metadata to the server and remove all possibility of overriding it in the document itself. The principle enunciated or illustrated here works well when the systems administrator responsible for the server knows the character encoding, content-type, etc., of each resource served, cares about serving correct metadata, and knows how to configure the server to achieve that result. It works less well when any of those conditions ceases to apply.

It is not unusual (in my experience, at least) for the author or provider of a document to know more about it than the maintainer of the Web server; if the in-line metadata and the metadata provided by the server are in conflict, it is not always my experience that the server is right and the author wrong, and it troubles me to see the web architecture document effectively disenfranchising the latter in favor of the former.

Section 3.4.1, Principle: Authoritative server metadata, says "User agents MUST NOT silently ignore authoritative server metadata" and discusses the responsibility of server managers in the provision of metadata.

This principle appears to mean that the only first-class citizens of the Web are server managers. Any content provider in the position of controlling the content, but not the server configuration, is at the mercy of the server manager; this situation is unproblematic when the server manager takes seriously the responsibilities assigned here; it seems likely to lead to problems in organizations where a typical exchange between content provider and webmaster runs like this:

Content Provider: This document needs to be served in UTF-8, not ISO Latin-1.

Webmaster: I'm busy, I don't have time for this kind of thing, so get lost.

Content Provider: Also, the expiration time should be thirty days, not two hours.

Webmaster: Close the door on your way out, OK?

It seems to me that local authority on metadata would be an approach more consistent with the principle of decentralization which governs Web architecture in other respects.

Decided at the Ottawa f2f. Added good practice about metadata association.

issue msm4: WD-webarch-20031209, 1.2.1, final bulleted list, final item.: Authoritative metadata and the principle of decentralization
error decided 2004-03-04

The second bullet doesn't make much sense; it seems to argue that META tags are capable of specifying new HTTP headers on the fly. While I suppose someone could make up a new header and stick it in a META tag, this really isn't the point. It also surmises that this somehow leads to the feature not being widely deployed; I believe that the reason is much more down-to-earth; performance.

Decided at the Ottawa f2f. Redrafted 5.1 'Orthogonal Specifications'.

issue nottingham1: Second bullet doesn't make sense.
error decided 2004-03-05

First bullet: This and http://www.w3.org/2001/tag/doc/whenToUseGet.html#i18n are basically okay. However the word 'limitations' (related to i18n) may give the wrong impression; it is not clear what the i18n concerns are. We suggest that you describe the issue more clearly, e.g. as "The design works reasonably well, although there are issues related to the transmission of non-ASCII characters." (please note the use of the word 'issues' rather than 'limitations'; although there are indeed some limitations as to the combinations of encodings in form pages and in requests, due to well-established practices based on HTML 4, there is no fundamental limitation to the basic use of non-ASCII characters. Also, please make sure the reader can directly go to the relevant section in the finding. Also, you may want to point to the FAQ on "What is the best way to deal with encoding issues in forms that may use multiple languages and scripts?" http://www.w3.org/International/questions/qa-forms-utf-8.html

issue i18nwg4: Please refer to "issues" rather than "limitations"
clarification raised 2004-03-18

Third bullet:

"Some authors use the META/http-equiv approach to declare the character encoding scheme of an HTML document. By design, this is a hint that an HTTP server should emit a corresponding "Content-Type" header field. In practice, the use of the hint in servers is not widely deployed. Furthermore, many user agents use this information to override the "Content-Type" header sent by the server. This works against the principle of authoritative representation metadata."

This is rather misleading on several points:

"By design, this is a hint that an HTTP server should emit a corresponding "Content-Type" header field.": It's correct that by design, this WAS a hint to the sever. Practice has shown that this wasn't such a good idea, and practice has found a better use for it. The WebArch doc should mainly look forward, mentioning misguided/reused designs can help, but it should not be presented as if it would be better to go back to that design. So e.g. reword to "this was (originally) intended..." "In practice, the use of the hint in servers is not widely deployed.": Is it actually deployed at all? Any pointers would be appreciated. "Furthermore, many user agents use this information to override the "Content-Type" header sent by the server.": Tests we have done recently with reasonably new browsers have shown that none of the major browsers do this. In particular if 'many user agents' is an acronym for IE6win, this is actually wrong (in case you do you own tests, please clean your cache if you change encodings or encoding labels for files; encodings are very 'sticky' in IE6, but for fresh pages, it gets things right). We suggest rewording e.g. to "user agents use this information if there is no 'charset' information in the "Content-Type" header" and/or "some have in the past..."

issue i18nwg5: Discussion of content-type header hint
error raised 2004-03-18

Identification, interaction, and representation are orthogonal (or, "independent", or "loosely coupled") concepts: an identifier can be assigned without knowing what representations are available, agents can interact with any identifier, and representations can change without regard to the identifiers or interactions that may dereference them.

Orthogonality in specifications facilitates a flexible design that can evolve over time. The fact, for example, that the an image can be identified using a URI without needing any information about the representation of that image allowed PNG and SVG to evolve independent of the specifications that define image elements.

Orthogonal abstractions deserve orthogonal specifications. Specifications should clearly indicate those features that simultaneously access information from otherwise orthogonal abstractions. For example a specification should draw attention to a feature that requires information from both the header and the body of a message.

Although the HTTP, HTML, and URI specifications are orthogonal for the most part, they are not completely orthogonal. Experience demonstrates that where they are not orthogonal, problems have arisen:

• The HTML specification includes a protocol extension of sorts: it specifies how a user agent sends HTML form data to a server (as a URI query string). The design works reasonably well, although there are limitations related to internationalization (see the TAG finding "URIs, Addressability, and the use of HTTP GET and POST") and the query string design impinges on the server design. Developers (for example, of [CGI] applications) might have an easier time finding the specification if it were published separately and then cited from the HTTP, URI, and HTML specifications.
• The HTML specification allows content providers to instruct HTTP servers to build response headers from META element instances. This is an abstraction violation; the developer community deserves to be able to find all HTTP headers from the HTTP specification (including any associated extension registries and specification updates per IETF process). Perhaps as a result, this feature of the HTML specification is not widely deployed. Furthermore, this design has led to confusion in user agent development. The HTML specification states that META in conjunction with http-equiv is intended for HTTP servers, but many HTML user agents interpret http-equiv='refresh' as a client-side instruction.
• Some authors use the META/http-equiv approach to declare the character encoding scheme of an HTML document. By design, this is a hint that an HTTP server should emit a corresponding "Content-Type" header field. In practice, the use of the hint in servers is not widely deployed. Furthermore, many user agents use this information to override the "Content-Type" header sent by the server. This works against the principle of authoritative representation metadata.

1.2.2. Extensibility

1.2.2 para 5 ("Ideally, many ..."). Sentence 2 ("Languages that exhibit this property are said to be 'extensible'") seems to say that if an instance of a larger language can be processed as though it were an instance of a smaller language, then the larger language is said to be "extensible". I think the term is probably better taken as referring to the smaller language; I think the paragraph should probably be rewritten from scratch, since with the current structure it will be difficult to provide a clear antecedent of the phrase "this property".

In any case, the current formulation invites the reply that OF COURSE some instances of a superset language may be processed as if they were members of a subset language: in any plausible case, a large number of members of the superset language ARE members of the subset language; that is what it means for one language to be a superset of another. I think the instances you wish to refer to particularly are those members of the superset language which are NOT instances of the subset language, but which can nonetheless successfully be processed by a suitable processor. The analysis here is weakened by its failure to acknowledge explicitly that the property in question is not a property of the language by itself but a property of the particular kind of processing involved, and the coding of the processor. (Here as elsewhere the document appears to fall into the trap of speaking as if only one kind of processing were liable to be applied to any particular document, or any particular language; this is not the case for any language intended to promote the reuse and repurposing of data, and that fact is of material importance in any discussion of extensibility.)

issue msm5: WD-webarch-20031209, 1.2.2 para 5: Extensibility is a not a property of languages in isolation
error raised 2004-03-04

1.2.2 para 5 ("Ideally, many ..."). I think the end of the paragraph would be more persuasive if "ignore" and "treat as error" were not the only examples given of default processing rules. The "ignore" approach is (as formulated here and elsewhere) an oversimplification. It is both underspecified and excessively specific. Underspecified, because most proponents do not distinguish between ignoring the unknown element and ignoring the tags which mark the beginning and ending of the unknown element, and some participants in the discussion fail to understand the difference, as is illustrated by the following paragraph of this document. Excessively specific, because ignoring is not the only plausible default processing rule, and in many contexts it's easy to think of a better. A pretty-printer should use its default line-break and indentation rules; a search system should use its default indexing rules; an editor should use its default display; a transformation system should perform the identity transform, or suppress the element (is this the same as 'ignoring' it? I don't think so), or perform another default action (such as the default action specified by XSLT). These do not all seem to me to be the same as "ignoring" either the element or the tags.

issue msm6: WD-webarch-20031209, 1.2.2 para 5: Ignoring the unknown as a default action
error raised 2004-03-04

The information in the Web and the technologies used to represent that information change over time. Some examples of successful technologies designed to allow change while minimizing disruption include:

• the fact that URI schemes are independently specified,
• the use of an open set of Internet media types in mail and HTTP to specify document interpretation,
• the separation of the generic XML grammar and the open set of XML namespaces for element and attribute names,
• Extensibility models in Cascading Style Sheets (CSS), XSLT 1.0, and SOAP
• user agent plug-ins

The following applies to languages, in particular the specifications of data formats, of message formats, and URIs. Note: This document does not distinguish in any formal way the terms "format" and "language." Context has determined which term is used.

Language subset: one language is a subset (or, "profile") of a second language if any document in the first language is also a valid document in the second language and has the same interpretation in the second language.

Language extension: one language is an extension of a second language if the second is a language subset of the first (thus, the extension is a superset). Clearly, creating an extension language is better for interoperability than creating an incompatible language.

Ideally, many instances of a superset language can be safely and usefully processed as though they were in the subset language. Languages that exhibit this property are said to be "extensible." Language designers can facilitate extensibility by defining how implementations must handle unknown extensions -- for example, that they be ignored (in some way) or should be considered errors.

For example, from early on in the Web, HTML agents followed the convention of ignoring unknown elements. This choice left room for innovation (i.e., non-standard elements) and encouraged the deployment of HTML. However, interoperability problems arose as well. In this type of environment, there is an inevitable tension between interoperability in the short term and the desire for extensibility. Experience shows that designs that strike the right balance between allowing change and preserving interoperability are more likely to thrive and are less likely to disrupt the Web community. Orthogonal specifications help reduce the risk of disruption.

For further discussion, see the section on versioning and extensibility. See also TAG issue xmlProfiles-29.

1.2.3. Error Handling

I don't agree with the exceptionless form of this principle. I think one can imagine silent error recoveries which aren't harmful. I suggested an amended version: silent error recovery is harmful if, and only if, it does some harm beyond mere failure to notify; or, put better: mere failure to notify isn't always a harm. (I'd be just as happy with the smallest possible weakening of the principle, something like: "Silent recovery from error is usually [or "typically" or "often"] harmful."

The TAG believes that text from the approved finding "Authoritative Metadata" will address the reviewer's concerns. Henceforth, refer to issue dhm2.

issue clark5: Silent Error Recovery Always Harmful?
error decided 2004-02-26

The validity of this principle depends very much on what level one is talking about. Is silent recovery from packet collisions harmful? With an ECC memory: should every correctable memory problem be reported? Must an application that normalizes input data so that out-of-range values are normalized to the valid extreme of the range report every bad data item? To whom? (Suppose the data stream represents instrument measurements streamed to a Web display.) We suggest that the rule be:

Silent recovery from errors may hinder problem diagnosis. Furthermore, silent recovery of errors resulting from erroneous input may inappropriately promote use of non-compliant data formats."

We also note that there is a tension between this principle and the notion of "must-ignore". For many applications, "what you don't understand" is equivalent to "an error". So one principle says you should ignore (presumably silently) this data, and the other says you should not.

I agree with this principle in cases where the way in which the agent recovers affects the resulting service provided to the user. There are error cases where this is not the case - for example, a 401 in http where the problem was a stale nonce, or an error indicating that a message was lost and should be retransmitted. In such cases, silent recovery probably makes sense.

Henceforth, refer to issue dhm2.

issue schema1: [1.2.3] "Silent recovery from error is harmful."
error decided 2004-03-04

The reviewer asked a number of questions about the principle of error recovery. See email for details.

See issue clark5.

issue parsia3: LC Comment, 1.2.3: Principle: Error recovery
clarification raised 2004-03-05

[[A user agent acts on behalf of the user and therefore is expected to help the user understand the nature of errors, and possibly overcome them. User agents that correct errors without the consent of the user are not acting on the user's behalf.]]

Is "user agent" intended to be *any* kind of "agent" (human or software, as previously defined) acting on behalf of someone else (the "user", so far undefined), or just *software* that acts on behalf of a human?

Also, the text seems to equate "act on behalf of the user" with that action necessarily being helpful, which is not necessarily the way "act on behalf of" is always interpreted. The real point would seem to be that user agents that correct errors in this way may in some sense be acting on the user's behalf, but they aren't helping the user by doing it.

issue manola6: User agent any kind of agent or just software? What does "on behalf of" include?
clarification raised 2004-03-10

Third bullet: [[* An agent that encounters unrecognized content...]]

Given the context, this seems a bit ambiguous, since it might be taken to refer to "user agent", as well as more generally to "agent" (assuming these are different; are they?)

issue manola7: "Agent" or "user agent" meant?
clarification raised 2004-03-10

Errors occur in networked information systems. The manner in which they are dealt with depends on application context. A user agent acts on behalf of the user and therefore is expected to help the user understand the nature of errors, and possibly overcome them. User agents that correct errors without the consent of the user are not acting on the user's behalf.

To promote interoperability, specifications should set expectations about behavior in the face of known error conditions. Experience has led to the following observations about error-handling approaches.

• Protocol designers should provide enough information about the error condition so that a an agent can address the error condition. For instance, an HTTP 404 message ("resource not found") is useful because it allows user agents to present relevant information to users, enabling them to contact the author of the representation that included the (broken) link.
• Experience with the cost of building a user agent to handle the diverse forms of ill-formed HTML content convinced the authors of the XML specification to require that agents fail deterministically upon encountering ill-formed content. Because users are unlikely to tolerate such failures, this design choice has pressured all parties into respecting XML's constraints, to the benefit of all.
• An agent that encounters unrecognized content may handle it in a number of ways, including as an error; see also the section on extensibility and versioning.
• Error behavior that is appropriate for a person may not be appropriate for software. People are capable of exercising judgement in ways that software applications generally cannot. An informal error response may suffice for a person but not for a processor.

See the TAG issues contentTypeOverride-24 and errorHandling-20.

1.2.4. Protocol-based Interoperability

Good practice: user agents should allow user to look "inside" to see (and even manipulate) the protocol interactions the agent is performing on behalf of the user.

Overtaken by events.

issue hawke1: Proposed good practice note on looking inside protocol interactions
proposal decided 2004-02-13

It is common for programmers working with the Web to write code that generates and parses these messages directly. It is less common, but not unusual, for end users to have direct exposure to these messages. This leads to the well-known "view source" effect, whereby users gain expertise in the workings of the systems by direct exposure to the underlying protocols.

It was not clear to me what is the intended significance of this with respect to Web Architecture. Suggest: explain the significance or drop this paragraph.

issue klyne1: Proposed to drop para on view source or clarify role in webarch
clarification raised 2004-03-05

The Web follows Internet tradition in that its important interfaces are defined in terms of protocols, by specifying the syntax, semantics, and sequence of the messages interchanged. The technology shared among Web agents lasts longer than the agents themselves.

It is common for programmers working with the Web to write code that generates and parses these messages directly. It is less common, but not unusual, for end users to have direct exposure to these messages. This leads to the well-known "view source" effect, whereby users gain expertise in the workings of the systems by direct exposure to the underlying protocols.

2.3.1. URIs in other Roles

[[In Web architecture, URIs identify resources. Outside the bounds of Web architecture specifications, URIs can be useful for other purposes, for example, as database keys...]]

It seems to me this paragraph mixes a few things. Just because a URI is used as a database key doesn't necessarily mean it's being used for a different purpose. If a URI is used as a key in a relational table that associates metadata with the Web resources identified by those keys, and does so correctly (i.e., distinguishes between metadata about Nadia and metadata about her mailbox), it seems as if this is the *same* use of the URI (to identify a Web resource), even though it may also be used in the database to identify a distinct row in the table. Moreover, the database might exhibit URI ambiguity in the same way the Web might, e.g., by mixing metadata about both Nadia and her mailbox in the same row. At the same time, the use of "mailto:nadia@example.com" as an identifier for Nadia rather than her mailbox seems just as likely to occur in a Web context as in this database one (people seem to want to do it in RDF, for example; or is this not the part of the Web you're talking about?).

issue manola16: Paragraph on other uses of URIs is confusing
clarification raised 2004-03-10

Good practice: URI opacity: This says "Agents making use of URIs MUST NOT attempt to infer properties of the referenced resource except as licensed by relevant specifications." Earlier, the document defines 'agent' as both humans and machines.

This good practice is not too difficult to follow for agents (although this seems to disallow e.g. Google to consider pieces of an URI in their algorithms, e.g. the 'weather' and 'oaxaca' in 'http://weather.example.com/oaxaca'; we're not sure disallowing this is intended or makes sense).

However, this practice is *impossible* to follow for humans: It's just completely impossible to look at http://weather.example.com/oaxaca and NOT interfering that this may be about 'weather' or 'oaxaca'. The WebArch document itself is using this connection all the time. This is important in connection with IRIs.

Overtaken by events.

issue i18nwg16: Good practice on URI opacity impossible to follow for humans.
error decided 2004-03-18

In Web architecture, URIs identify resources. Outside the bounds of Web architecture specifications, URIs can be useful for other purposes, for example, as database keys. For instance, the organizers of a conference might use "mailto:nadia@example.com" to refer to Nadia. While this usage is not licensed by Web architecture specifications, in the context of the conference, all parties may agree to that local policy and understand one another. Certain properties of URIs, such as their potential for uniqueness, make them appealing as general-purpose identifiers. In the Web architecture, "mailto:nadia@example.com" identifies an Internet mailbox; that is what is licensed by the "mailto" URI scheme specification. The fact that the URI serves other purposes in non-Web contexts does not lead to URI ambiguity. URI ambiguity arises a URI is used to identify two different Web resources.

2.4.1. URI Scheme Registration

The Internet Assigned Numbers Authority (IANA) maintains a registry [IANASchemes] of mappings between URI scheme names and scheme specifications. For instance, the IANA registry indicates that the "http" scheme is defined in [RFC2616]. The process for registering a new URI scheme is defined in [RFC2717].

The use of unregistered URI schemes is discouraged for a number of reasons:

• There is no generally accepted way to locate the scheme specification.
• Someone else may be using the scheme for other purposes.
• One should not expect that general-purpose software will do anything useful with URIs of this scheme; the network effect is lost.

Note: Some URI scheme specifications (such as the "ftp" URI scheme specification) use the term "designate" where the current document uses "identify."

TAG issue siteData-36 is about expropriation of naming authority.

2.7.1. Internationalized Identifiers

The integration of internationalized identifiers (i.e., composed of characters beyond those allowed by [URI]) into the Web architecture is an important and open issue. See TAG issue IRIEverywhere-27 for discussion about work going on in this area.

2.7.2. Assertion that Two URIs Identify the Same Resource

Proposal" Knowing two URIs identify the same resource does not, however, mean they are interchangeable. For example, Oaxaca might have several government-run weather stations, and the measurements take from each of these might be available from both weather.example.org and weather.example.com. The first might call a particular station http://weather.example.org/stations/oaxaca#ws17a while the second calls it http://weather.example.com/rdfdump?region=oaxaca&station=ws17a These two URIs would both identify the same resource, a certain collection of weather measuring equipment. They are owl:sameAs each other. But an attempt to dereference them might well produce different content produced by different organizations (probably based originally on the same government-supplied data), so a user agent which substituted one for the other would be serving its user poorly.

Overtaken by events.

issue hawke7: 2.7.2. Assertion that Two URIs Identify the Same Resource
proposal decided 2004-02-13

Emerging Semantic Web technologies, including the "Web Ontology Language (OWL)" [OWL10], define RDF [RDF10] properties such as sameAs to assert that two URIs identify the same resource or functionalProperty to imply it.

3.3.1. Media Types and Fragment Identifier Semantics

This sentence seems misleading, as if one can infer something about the nature of a secondary resource by interpreting a URI reference with fragement identifier. One cannot infer the nature of any URI denoted resource based either on the URI *or* based on any representation obtained by dereferencing that URI, either directly, or for URI references with fragment identifiers, by first dereferencing the base URI and interpreting the fragment in terms of the MIME type of the returned represenatation. This last sentence could either be removed or clarified/reworked.

issue stickler8: Section 3.3.1, last para, last sentence: Nature of secondary resource not known through URI
clarification raised 2004-02-03

Question: are the methods PUT, POST or DELETE meaningful for URI references with fragment identifiers, in terms of interacting with the state of the secondary resources denoted? If not, then it seems there is a good principle that one should use URIs without fragment identifiers whenever possible to maximise the utililty of those URIs.

Overtaken by events.

issue stickler9: Good practice note on URIs without fragids?
proposal decided 2004-02-03

[3.3.1] says: "Per [URI], in order to know the authoritative interpretation of a fragment identifier, one must dereference the URI containing the fragment identifier. The Internet Media Type of the retrieved representation specifies the authoritative interpretation of the fragment identifier. Thus, in the case of Dirk and Nadia, the authoritative interpretation depends on the SVG specification, not the XHTML specification (i.e., the context where the URI appears)."

But this seems to contradict the referenced URI specification, which says:

"The semantics of a fragment identifier are defined by the set of representations that might result from a retrieval action on the primary resource. The fragment's format and resolution is therefore dependent on the media type [RFC2046] of the retrieved representation, even though such a retrieval is only performed if the URI is dereferenced."

The latter says clearly you need not dereference. On the contrary, you must know the range of representations that you might get _if_ you tried to dereference.

Decided just prior to the Ottawa f2f. Incorporating CL’s edits of 3.3.1 has fixed this issue (by making the webarch document the same as 2396bis.

issue schema5: [3.3.1] Inconsistency with RFC2396bis about frag id meaning?
error decided 2004-03-04

[3.3.1] says

"Given a URI "U#F", and a representation retrieved by dereferencing URI "U", the (secondary) resource identified by "U#F" is determined by interpreting "F" according to the specification associated with the Internet Media Type of the representation."

What if the scheme is not HTTP and media types are not used (e.g. because the URI uses the file: scheme or for some other reason)? Do fragment identifiers work only with media-typed representations? We hope not.

issue schema6: [3.3.1] Do fragment identifiers work only with media-typed representations?
clarification raised 2004-03-04

This reader wonders at this point whether there are any constraints on the interpretation which the definer of a media type can place on fragment identifiers for the media type. Can one, consistent with Web architecture (if not necessarily with good design) define a media type (let us say application/sortes) where the meaning of a fragment identifier is identified by taking a checksum of the octet string returned, the conventional numerological value of the string used as the fragment identifier, multiplying the one by the other, and using the product to look up a passage in a copy of Vergil, with the stipulation that the meaning of the fragment identifier is "the meaning of the passage found by this method"?

issue msm12: WD-webarch-20031209, Section 3.3.1, para 1: Are there constraints on the interpretation of fragment identifiers?
error raised 2004-03-04

[[Note that one can use a URI with a fragment identifier even if one does not have a representation available for interpreting the fragment identifier (one can compare two such URIs, for example). Parties that draw conclusions about the interpretation of a fragment identifier without retrieving a representation do so at their own risk; such interpretations are not authoritative.]]

This is a place where some qualifying context about the nature of the Web to which this architecture applies would have been helpful. For example, suppose I have a collection of RDF or OWL statements having as subjects the URI "http://www.example.com/images/nadia#hat", and the RDF/OWL statements assert that the subject is of class "Hat" in some ontology, that it's blue, and so on. On one hand, it seems as if one could reasonably draw conclusions about the interpretation of this fragment identifier (or rather the whole URI including it) *from the RDF/OWL* without dereferencing the URI (using the URI to retrieve a representation, whose media type specifies the authoritative interpretation), assuming that the RDF/OWL itself is from a sufficiently "authoritative" (in some sense) representation somewhere. Saying "such intepretations are not authoritative" without any further qualification or discussion, while it makes perfect sense given the way the Web works now, doesn't seem to take such additional usage (which, after all, is described in W3C Recommendations) into account.

The TAG intends to clarify the text to indicate that parties who draw conclusions from syntactic analysis of URIs alone do so at their own risk.

issue manola19: Please provide qualifying context about the nature of the Web
clarification decided 2004-03-10

Per [URI], in order to know the authoritative interpretation of a fragment identifier, one must dereference the URI containing the fragment identifier. The Internet Media Type of the retrieved representation specifies the authoritative interpretation of the fragment identifier. Thus, in the case of Dirk and Nadia, the authoritative interpretation depends on the SVG specification, not the XHTML specification (i.e., the context where the URI appears).

Given a URI "U#F", and a representation retrieved by dereferencing URI "U", the (secondary) resource identified by "U#F" is determined by interpreting "F" according to the specification associated with the Internet Media Type of the representation.

Interpretation of the fragment identifier during a retrieval action is performed solely by the agent; the fragment identifier is not passed to other systems during the process of retrieval. This means that some intermediaries in the Web architecture (such as proxies) have no interaction with fragment identifiers and that redirection (in HTTP [RFC2616], for example) does not account for them.

Note that one can use a URI with a fragment identifier even if one does not have a representation available for interpreting the fragment identifier (one can compare two such URIs, for example). Parties that draw conclusions about the interpretation of a fragment identifier without retrieving a representation do so at their own risk; such interpretations are not authoritative.

3.3.2. Fragment Identifiers and Multiple Representations

Section 3.3.2, para 3 ("On the other hand ...") says "it is considered an error if the semantics of the fragment identifiers used in two representations of a secondary resource are inconsistent." What does "inconsistent" mean here? How do the responsible parties determine whether a given plan of using fragment identifiers is or is not compliant with this rule?

Suppose that an internet media type (application/my-magic-mediatype) is defined with the basic rule that it is represented by servers as an XML data stream rooted in a particular namespace (e.g. one for purchase orders), and that its fragment identifers are syntactically identical to those of the application/xml media type, but denote not individual XML elements or attributes but instead whatever real-world objects are represented by those elements or attributes (a customer, an invoice, a payment obligation, ...), if any, or else have no denotation.

Suppose further that a resource owner serves the same octet sequence as two different media types (e.g. application/xml and application/my-magic-mediatype). Is the resource owner (a) obeying the principle enunciated here, given that the denotations of the fragment identifier in the two cases stand in a predictable and plausible relation to each other? or (b) violating this principle, given that in the two cases the fragment identifier identifies objects of radically different classes (XML elements on the one hand, people and other non-XML entities on the other)?

The TAG resolved to make the following changes to the document:

Include three examples about coneg as proposed by TBL. State clearly that it's an error for representation providers to provide representations with inconsistent frag id semantics. Talk about consistency as being in the eye of the representation provider (not forgetting that users also have expectations). Thus, the answer to the reviewer's last question is: the notion of consistency is in the eye of the representation provider.

issue msm13: WD-webarch-20031209, Section 3.3.2, para 3: Consistency of fragment identifiers
error decided 2004-03-04

For a given resource, an agent may have the choice between representation data in more than one data format (through HTTP content negotiation, for example). Since different data formats may define different fragment identifier semantics, it is important to note that by design, the secondary resource identified by a URI with a fragment identifier is expected to be the same across all representations. Thus, if a fragment has defined semantics in any one representation, the fragment is identified for all of them, even though a particular data format may not be able to represent it.

Suppose, for example, that the authority responsible for "http://weather.example.com/oaxaca/map#zicatela" provides representations of the resource identified by http://weather.example.com/oaxaca/map using three image formats: SVG, PNG, and JPEG/JFIF. The SVG specification defines semantics for fragment identifiers while the other specifications do not. It is not considered an error that only one of the data formats specifies semantics for the fragment identifier. Because the Web is a distributed system in which formats and agents are deployed in a non-uniform manner, the architecture allows this sort of discrepancy. This design allows authors to take advantage of new data formats while still ensuring reasonable backward-compatibility for users whose agents do not yet implement them.

On the other hand, it is considered an error if the semantics of the fragment identifiers used in two representations of a secondary resource are inconsistent.

Inconsistent fragment identifier semantics are one potential source of URI ambiguity.

See related TAG issues httpRange-14 and RDFinXHTML-35.

3.4.1. Inconsistencies between Metadata and Representation Data

Should this be reworded in "User agents MUST NOT silently ignore authoritative metadata."? If so, is it still worth mentioning? (ie, is there any point in saying "do what the protocol says to do"?)

issue dhm6: Use of "server" in "...authoritative server metadata..."
clarification raised 2004-02-20

[3.4.1] Says that user agents must not silently ignore server metadata. Metadata covers a lot of ground: what is its scope? May a user agent ignore a server-specified DTD or Schema and choose to apply a local variant (e.g. because the user so specifies in a local configuration file or a launch-time option)? Why not?

issue schema7: [3.4.1] What is scope of metadata?
clarification raised 2004-03-04

If the sender is not a trusted authority, it would be foolish for the recipient to rely on the principle of sender-makes-right. A well written production server runs an unacceptable risk if it accepts at face value everything an untrusted client tells it. Must it inform the client each time it follows its own instructions by ignoring client information?

Overtaken by events.

issue schema8: [3.4.1] Authority and trust
error decided 2004-03-04

(We also note in passing that focusing on the interactions between "user-agents" and "servers" is fundamentally limiting in the sense mentioning in our opening comment. Are not peer-to-peer interactions covered by this architecture?)

Overtaken by events.

issue schema9: [3.4.1] Are peer-to-peer interactions covered?
error decided 2004-03-04

[[User agents should detect such inconsistencies but should not resolve them without involving the user.]]

Now the term is "user agent" rather than "agents". Is there some particular reason for distinguishing between these terms?

issue manola22: "Agent" or "user agent" meant?
clarification raised 2004-03-10

We believe that charset handling, the way it is currently specified in various specs (i.e. outer information has priority to inner information), is basically okay (with the exception of the (irrelevant in practice) iso-8859-1 default given in the HTTP spec, and the us-ascii default for text/foo+xml, which makes text/foo+xml rather useless. It might be good to reach some consensus about this, and document it.

Overtaken by events.

issue i18nwg19: text/foo+xml considered useless?
proposal decided 2004-03-18

"Furthermore, server managers can help reduce the risk of error through careful assignment of representation metadata (especially that which applies across representations). The section on media types for XML presents an example of reducing the risk of error by providing no metadata about character encoding when serving XML."

This seems to pick out a somewhat arbitrary detail, without stating the much more important underlying principles, such as:

Always make sure you know what the character encoding of a document or message is. Make sure that it's easy for server managers and authors to configure and test metadata on the server, to make sure it's correct. No arbitrary defaults for specs No out-of-the-box with arbitrary settings The description of the example also is too general, because there are ways to implement/operate a server that make it much more easy/appropriate to put the 'charset' into the header than into the body, e.g. when producing content in a pipeline from a database.

issue i18nwg20: text/foo+xml considered useless?
proposal raised 2004-03-18

Inconsistencies between the data format of representation data and assigned representation metadata do occur. Examples that have been observed in practice include:

• The actual character encoding of a representation is inconsistent with the charset parameter in the representation metadata.
• The namespace of the root element of XML representation data is inconsistent with the value of the 'Content-Type' field in HTTP headers.

User agents should detect such inconsistencies but should not resolve them without involving the user.

Thus, for example, if the parties responsible for "weather.example.com" mistakenly label the satellite photo of Oaxaca as "image/gif" instead of "image/jpeg", and if Nadia's browser detects a problem, Nadia's browser must not silently ignore the problem and render the JPEG image. Nadia's browser can notify Nadia of the problem or notify Nadia and take corrective action. Of course, user agent designers should not ignore usability issues when handling this type of error; notification may be discreet, and handling may be tuned to meet the user's preferences. See the TAG finding "Client handling of MIME headers" for more in-depth discussion and examples.

Furthermore, server managers can help reduce the risk of error through careful assignment of representation metadata (especially that which applies across representations). The section on media types for XML presents an example of reducing the risk of error by providing no metadata about character encoding when serving XML.

3.5.1. Unsafe Interactions and Accountability

Para 3 seems to contradict the last statement of para 1. In para 1 it is said that POST requests and responses cannot be referenced by URIs, yet para 3 describes a means to do just that. It seems that what is meant to be said in para 1 is that, per the default behavior of POST, the request and response are not normally assigned distinct URIs by which they can be later referenced. ???

The Editor will review 3.5.1 and propose a revision to the TAG that more clearly distinguishes the two topics of bookmarking results of POST and paper trails (both safe and unsafe contexts).

issue stickler6: Section 3.5.1: POST requests and URIs
error decided 2004-02-03

[3.5.1] Says:

"There are mechanisms in HTTP, not widely deployed, to remedy this situation. HTTP servers can assign a URI to the results of a POST transaction using the "Content-Location" header (described in section 14.14 of [RFC2616]), and allow authorized parties to retrieve a record of the transaction thereafter via this URI (the value of URI persistence is apparent in this case). User agents can provide an interface for managing transactions where the user agent has incurred an obligation on behalf of the user."

Yes, but is this saying specifically that content-location SHOULD be used? If so, so. If not, then make clearer what's intended.

issue schema11: [3.5.1] Best practice that content-location SHOULD be used?
clarification raised 2004-03-04

It is a breakdown of the Web architecture if agents cannot use URIs to reconstruct a "paper trail" of transactions, i.e., to refer to receipts and other evidence of accepting an obligation. Indeed, each electronic mail message includes a unique message identifier, one reason why email is so useful for managing accountability (since, for example, email can be copied to public archives). On the other hand, HTTP servers and deployed user agents do not generally keep records of POST transactions, making it difficult for all parties to reconstruct a series of transactions.

There are mechanisms in HTTP, not widely deployed, to remedy this situation. HTTP servers can assign a URI to the results of a POST transaction using the "Content-Location" header (described in section 14.14 of [RFC2616]), and allow authorized parties to retrieve a record of the transaction thereafter via this URI (the value of URI persistence is apparent in this case). User agents can provide an interface for managing transactions where the user agent has incurred an obligation on behalf of the user.

3.6.1. Representation availability

Owners of URIs should be free to decide whether any representations are made available, and should *NOT* feel obligated to provide representations if they themselves have no need to do so. URIs without representations may simply be less valueable/useful than those with representations. But it shouldn't be considered bad practice to not provide any representations. I recommend that this particular "good practice" be removed, even though language should remain which reflects that URIs with accessible representations are usually more useful than those without.

The TAG intended to indicate that people SHOULD provide representations; the community is poorer where representations are not available. "SHOULD" allows URI owners to make a choice.

issue stickler4: Section 3.6.1 Proposed removal of good practice note
request decided 2004-02-03

[3.6.1] Good practice: Available representation Publishers of a URI SHOULD provide representations of the identified resource.

We are concerned that this appears to privilege dereferenceable URIs over other sectors of URI space; in particular to denigrate all uses of URIs as pure (non-dereferenceable) identifiers, such as namespaces, QT functions, SOAP extensions, SAX properties, etc. etc. There are often pragmatic reasons for declining to make URIs dereferencable (unwelcome load on servers, for example, or identifiers that are intended purely for software systems and that humans will never see or need to dereference to obtain useful information). It seems to us that at least a coherent story should be told about how this pure-identification use fits into the overall Web architecture.

Decided at the Ottawa f2f. Added good practice about unnecessary network access.

issue schema12: [3.6.1] [3.6.1] Good practice: Available representation. Too preferential to dereferencable URIs
error decided 2004-03-04

The authority responsible for a resource may supply zero or more representations of a resource. The authority is also responsible for accepting or rejecting requests to modify a resource, for example, by configuring a server to accept or reject HTTP PUT data based on Internet Media Type, validity constraints, or other constraints.

3.6.2. URI Persistence

Scenarios appear to be based on "static" URI's; i.e.: "persistent" URI's (reference chapter 3.6.2). Suggest discussion of "dynamically generated" URI's; particularly addressing situations where dynamic URI's are bookmarked or forwarded by a user.

issue diwg1: Add scenario(s) with dynamically generated URI
proposal raised 2004-02-25

There are strong social expectations that once a URI identifies a particular resource, it should continue indefinitely to refer to that resource; this is called URI persistence. URI persistence is a matter of policy and commitment on the part of authorities servicing URIs. The choice of a particular URI scheme provides no guarantee that those URIs will be persistent or that they will not be persistent.

The terminology "authorities servicing URIs" seems to be not consistent with that used elsewhere; e.g. "authority responsible for a resource" at the start of section 3.6.1., and "URI producers" in section 2.1.

As I draft this, I think there's maybe a deeper omission here: a lack of separation between the owner or authority responsible for a resource, and the authority for a particular part of URI space that may be used to identify a resource. (cf. also my previous comment above.) If not clarified, I think this could be a source of continuing miscommunication.

The TAG believes that the following minor changes to the document are sufficient to address the reviewer's concern.

In 2.2, change to "(for example, to a server manager or someone who has been delegated part of the URI space on a given Web server). s/authorities servicing URIs/URI owners

issue klyne15: Lack of separation between owner of a resource and authority for a part of URI space used to identify a resource?
error decided 2004-03-05

I made a note to myself at the end of this section: "Maye add a comment about metadata consistency and problems that may occur of a resource is not persistent" but now I not sure what it is I meant by this.

I think I may have been thinking about a case where RDF is used to describe some resource, but the resource whose representation is served at a given URI is allowed to change over time. Then, any RDF that uses said URI to describe the resource at some point in time becomes completely incorrect if the URI is assigned to a different resource. Is it worth trying to make a point that the value of RDF descriptions depends to a considerable extent on the stability/persistence of the URIs used?

Decided at Ottawa f2f. (No action.)

issue klyne17: Worth pointing out value of RDF descriptions depends on URI persistence?
proposal decided 2004-03-05

There are strong social expectations that once a URI identifies a particular resource, it should continue indefinitely to refer to that resource; this is called URI persistence. URI persistence is a matter of policy and commitment on the part of authorities servicing URIs. The choice of a particular URI scheme provides no guarantee that those URIs will be persistent or that they will not be persistent.

Since representations are used to communicate resource state, persistence is directly affected by how well representations are served. Service breakdowns include:

• Inconsistent representations served. Note the difference between a resource owner changing representations predictably in light of the nature of the resource (the changing weather of Oaxaca) and the owner changing representations arbitrarily.
• Improper use of content negotiation, such as serving two images as equivalent through HTTP content negotiation, where one image represents a square and the other a circle.

4.2.1. Versioning

No version info in media types? Media type as special case of content negotiation?

The TAG agrees that more needs to be stated about trade-offs. The TAG has created a new issue mediaTypeManagement-45.

issue diwg4: Suggest discussion of the limitations of Internet media types as the prime mechanism for selecting between different representations of a resource.
proposal decided 2004-02-25

[[Good practice: Version information Format designers SHOULD provide for version information in language instances]]

What are "language instances"?

The TAG agreed to accept this change: "A format specification SHOULD provide for version information."

issue manola29: What are "language instances"?
clarification decided 2004-03-10

There is typically a (long) transition period during which multiple versions of a format, protocol, or agent are simultaneously in use.

4.2.2. Versioning and XML Namespace Policy

Section 4.2.2, Story. The text says that defining a new optional "lang" attribute on a "film" element does not affect the conformance of any existing data or software. This isn't quite true: it changes some invalid data (data with the undefined attribute "lang") into valid data, and some non-conforming software (software which erroneously accepts that invalid content) into conforming software.

The text is correct if, but only if, the universe of discourse is restricted to valid data.

The TAG agrees with the reviewer regarding the general case, but it doesn't apply to this specific instance. The TAG does not feel changes to the document are required.

issue msm14: WD-webarch-20031209, Section 4.2.2, Story: Allowing extra attributes does change the conformance of existing data
error decided 2004-03-04

Dirk and Nadia have chosen a particular namespace change policy that allows them to avoid changing the namespace name whenever they make changes that do not affect conformance of deployed content and software. They might have chosen a different policy, for example that any new element or attribute has to belong to a namespace other than the original one. Whatever the chosen policy, it should set clear expectations for users of the format.

As an example of a change policy designed to reflect the variable stability of a namespace, consider the W3C namespace policy for documents on the W3C Recommendation track. The policy sets expectations that the Working Group responsible for the namespace may modify it in any way until a certain point in the process ("Candidate Recommendation") at which point W3C constrains the set possible changes to the namespace in order to promote stable implementations.

Note that since namespace names are URIs, the party (if any) responsible for a namespace URI has the authority to decide the namespace change policy.

4.2.3. Extensibility

[4.2.3] The discussion of mustIgnore & mustUnderstand should clarify the difference between marking the distinction in the document instance, in a schema, or in prose documentation. SOAP does it with an attribute in the instance. Schema content models do it in the schema. Other systems provide rules in the specifications. These have different tradeoffs.

issue schema14: [4.2.3] Must * rules in instance v. documentation
clarification raised 2004-03-04

[[As part of defining an extensibility mechanism, a specification should set expectations about agent behavior in the face of unrecognized extensions.]]

The following good practice then says

[[Language designers SHOULD specify agent behavior in the face of unrecognized extensions.]]

It's not clear that a specification "setting expectations about" agent behavior is the same as it "specifying" it. Why the difference in wording?

Delete "As part of defining ..." sentence.

issue manola30: Difference between "setting expectations" and "specifying"?
clarification decided 2004-03-10

Designers can facilitate the transition process by making careful choices about extensibility during the design of a language or protocol specification.

Application needs determine the most appropriate extension strategy for a specification. For example, applications designed to operate in closed environments may allow specification authors to define a versioning strategy that would be impractical at the scale of the Web. As part of defining an extensibility mechanism, a specification should set expectations about agent behavior in the face of unrecognized extensions.

Two strategies have emerged as being particularly useful:

1. "Must ignore": The agent ignores any content it does not recognize.
2. "Must understand": The agent treats unrecognized markup as an error condition.

A powerful design approach is for the language to allow either form of extension, but to distinguish explicitly between them in the syntax.

Additional strategies include prompting the user for more input, automatically retrieving data from available links, and falling back to default behavior. More complex strategies are also possible, including mixing strategies. For instance, a language can include mechanisms for overriding standard behavior. Thus, a data format can specify "must ignore" semantics but also allow people to create extensions that override that semantics in light of application needs (for instance, with "must understand" semantics for a particular extension).

Extensibility is not free. Providing hooks for extensibility is one of many requirements to be factored into the costs of language design. Experience suggests that the long term benefits of extensibility generally outweigh the costs.

4.2.4. Composition of Data Formats

[4.2.4] Says:

"In principle, a SOAP message can contain a JPEG image that contains an RDF comment which refers to a vocabulary of terms for describing the image."

This is untrue: SOAP is XML, JPEG is not. MTOM may do something to extend SOAP to make this true, but as it stands the statement is false. Perhaps "... can contain an SVG image that contains ..." is what you meant to write.

The TAG believes the 10 May 2004 draft addresses the reviewer's concerns.

issue schema15: [4.2.4] SOAP message cannot include JPEG
error decided 2004-03-04

RDF allows well-defined mixing of vocabularies, and allows text and XML to be used as a data type values within a statement having clearly defined semantics.

I couldn't figure precisely what this was trying to say.

Change third bullet to: "The semantics of combining RDF documents with multiple vocabularies is well-defined." Delete "and allows text and XML to be used as a data type values within a statement having clearly defined semantics."

issue klyne19: Unclear statement about mixing RDF vocabularies
clarification decided 2004-03-05

Note however, that for general XML there is no semantic model that defines the interactions within XML documents with elements and/or attributes from a variety of namespaces. Each application must define how namespaces interact and what effect the namespace of an element has on the element's ancestors, siblings, and descendants.

I think that there may be an important point to be made here about the relationship of the "Semantic Web" with what I might call the "Hypertext Web" upon which it is built, that the "Semantic Web" provides a well-defined way to combine statements that draw upon an arbitrary number of different namespaces. (I regard this as one of the more important contributions of the Semantic Web.)

Maybe this is what the subject of my previous comment was trying to say?

The TAG resolved (SW abstaining):

Create a new section 4.6 about use of media types to build new applications that make use of the information space. Explain that you create new "applications" such as the semantic web through new media type definitions. "Above we describe a global hypertext application which has been defined using specific Media types. The creation of other media types allows new applications to be build in the same space, using the same information space infrastructure. The semantic web is one such application, which is not described in detail in this version of this document. We expect future versions of the Arch doc to describe the semantic web in more detail." Remove sem web from discussion in 3.7 Respond to reviewer that we expect future versions of the arch doc to go into more detail about the relationships among various systems.

Overtaken by events.

issue klyne20: Say something about relationship between Hypertext Web and Semantic Web?
proposal decided 2004-03-05

Third bullet [[ * RDF allows well-defined mixing of vocabularies, and allows text and XML to be used as a data type values within a statement having clearly defined semantics.]]

"...allows text and XML to be used as data type values..." (delete the "a")?

Within the same statement? What does "having clearly defined semantics" modify? Should this be "...within statements having clearly defined semantics"?

The TAG believes this issue has been addressed by virtue of deletion of the text in question.

issue manola31: Questions about RDF, text, XML mixing
clarification decided 2004-03-10

Many modern data format specifications include mechanisms for composition. For example:

• It is possible to embed text comments in some image formats, such as JPEG/JFIF. Although these comments are embedded in the containing data, they have little or no effect on the display of the image.
• There are container formats such as SOAP which fully expect to be composed from multiple namespaces but which provide an overall semantic relationship of message envelope and payload.
• RDF allows well-defined mixing of vocabularies, and allows text and XML to be used as a data type values within a statement having clearly defined semantics.

These relationships can be mixed and nested arbitrarily. In principle, a SOAP message can contain a JPEG image that contains an RDF comment which refers to a vocabulary of terms for describing the image.

Note however, that for general XML there is no semantic model that defines the interactions within XML documents with elements and/or attributes from a variety of namespaces. Each application must define how namespaces interact and what effect the namespace of an element has on the element's ancestors, siblings, and descendants.

See TAG issues mixedUIXMLNamespace-33, xmlFunctions-34, and RDFinXHTML-35.

4.4.1. URI References

I found the text of this section less clear than was offered in an email from TimBL:

It is important to distinguish between the string which identifies something and the BNF for a string in a document which is used to specify the first string. The first is an identifier. The second has been called a "reference". A reference can use a relative form.

issue klyne23: Clarify section (see TBL text on identifier v. reference?)
clarification raised 2004-03-05

Links are commonly expressed using URI references (defined in section 4.2 of [URI]), which may be combined with a base URI to yield a usable URI. Section 5.1 of [URI] explains different mechanisms for establishing a base URI for a resource and establishes a precedence among the various mechanisms. For instance, the base URI may be a URI for the resource, or specified in a representation (see the base elements provided by HTML and XML, and the HTTP 'Content-Location' header). See also the section on links in XML.

Agents resolve a URI reference before using the resulting URI to interact with another agent. URI references help in content management by allowing authors to design a representation locally, i.e., without concern for which global identifier may later be used to refer to the associated resource.

4.5.1. When to Use an XML-Based Format

Another reference with discussion relating to this topic of choosing to use XML can be found in RFC3117, section 5.1

Decided at Ottawa f2f. (No action.) The behavior suggested by RFC3117 was actually reversed when the actual spec went through standardization so we aren’t going to reference it.

issue klyne25: Add reference to RFC3117, section 5.1?
proposal decided 2004-03-05

XML defines textual data formats that are naturally suited to describing data objects which are hierarchical and processed in a chosen sequence. It is widely, but not universally, applicable for data format specifications; an audio or video format, for example, is unlikely to be well suited to expression in XML. Design constraints that would suggest the use of XML include:

1. Requirement for a hierarchical structure.
2. The data's usefulness should outlive the tools currently used to process it (though obviously XML can be used for short-term needs as well).
3. Ability to support internationalization in a self-describing way that makes confusion over coding options unlikely.
4. Early detection of encoding errors with no requirement to "work around" such errors.
5. A high proportion of human-readable textual content.
6. Potential composition of the data format with other XML-encoded formats.

4.5.2. Links in XML

in section 4.5.2, I'm uncomfortable with the recommendation to use XLink when using XML, except perhaps when authoring documents which are intended for human consumption. I believe that RDF/XML provides superior linking capabilities for XML than does XLink, and IMO preference should be given to it. Alternately, listing both as options would be adequate.

issue baker4: 4.5.2: Preference for RDF linking over XLink linking
error raised 2004-03-05

Sophisticated linking mechanisms have been invented for XML formats. XPointer allows links to address content that does not have an explicit, named anchor. XLink is an appropriate specification for representing links in hypertext XML applications. XLink allows links to have multiple ends and to be expressed either inline or in "link bases" stored external to any or all of the resources identified by the links it contains.

Designers of XML-based formats should consider using XLink and, for defining fragment identifier syntax, using the XPointer framework and XPointer element() Schemes.

See TAG issue xlinkScope-23.

4.5.3. XML Namespaces

"Namespaces in XML provides a mechanism for establishing a globally unique name that can be understood in any context." What does it mean to understand a name? Should this say that the globally unique name can unambiguously identify the intended meaning of the element/attribute?

issue kopecky4: 4.5.3 use of "understand"
clarification raised 2004-02-23

[4.5.3] States:

"Namespaces in XML" [XMLNS] provides a mechanism for establishing a globally unique name that can be understood in any context.

This is a false statement and should not be continued to be repeated.

Delete "that can be understood in any context" (Already done in 10 May 2004 draft.) Modify remaining sentence to say: "Namespaces in xml use URIs in order to obtain the properties of a global namespace." Include a reference to 2.2 URI ownership.

issue schema17: [4.5.3] Statement about XMLNS and unique names false
error decided 2004-03-04

[4.5.3] Says:

"The type attribute from W3C XML Schema is an example of a global attribute."

This should indicate type in the Schema Instance namespace, preferably with a suitable link to our spec. Perhaps

"The type attribute from W3C XML Schema namespace is an example of a global attribute."

There are also type attributes in the schema document vocabulary, e.g. on <xsd:element>, and those are not global. Furthermore, we see above in 4.5.6 that a prefix is used to indicate xs:ID as a type. So, why not use xsi:type for this one:

"The xsi:type attribute, provided by W3C XML Schema for use in XML instance documents, is an example of a global attribute."

Include a clearer reference to the XML Schema specification.

issue schema18: [4.5.3] Clarification on "type" in XML Schema
clarification decided 2004-03-04

[4.5.3] Says:

"Attributes are always scoped by the element on which they appear. An attribute that is "global," that is, one that might meaningfully appear on different elements, including elements in other namespaces, should be explicitly placed in a namespace. Local attributes, ones associated with only a particular element, need not be included in a namespace since their meaning will always be clear from the context provided by that element."

This appears to mix the notion of element instance and what DTD-oriented minds would call 'element type'. Perhaps this should read

An attribute that is "global," that is, one that might meaningfully appear on elements of any type, including elements in other namespaces, should be explicitly placed in a namespace. Local attributes, ones associated with only a particular element type, need not be included in a namespace since their meaning will always be clear from the context provided by that element."

The TAG agreed with the reviewer.

issue schema19: [4.5.3] Element type/instance confusion
clarification decided 2004-03-04

How do the application designers ensure that there are no naming conflicts when they combine elements from different formats (for example, suppose that the "p" element is defined in two or more XML formats)? "Namespaces in XML" [XMLNS] provides a mechanism for establishing a globally unique name that can be understood in any context.

Language specification designers that declare namespaces thus provide a global context for instances of the data format. Establishing this global context allows those instances (and portions thereof) to be re-used and combined in novel ways not yet imagined. Failure to provide a namespace makes such re-use more difficult, perhaps impractical in some cases.

Attributes are always scoped by the element on which they appear. An attribute that is "global," that is, one that might meaningfully appear on different elements, including elements in other namespaces, should be explicitly placed in a namespace. Local attributes, ones associated with only a particular element, need not be included in a namespace since their meaning will always be clear from the context provided by that element.

The type attribute from W3C XML Schema is an example of a global attribute. It can be used by authors of any vocabulary to make an assertion about the type of the element on which it appears. The type attribute occurs in the W3C XML Schema namespace and must always be fully qualified. The frame attribute on an HTML table is an example of a local attribute. There is no value in placing that attribute in a namespace since the attribute is unlikely to be useful on an element other than an HTML table.

Applications that rely on DTD processing must impose additional constraints on the use of namespaces. DTDs perform validation based on the lexical form of the element and attribute names in the document. This makes prefixes syntactically significant in ways that are not anticipated by [XMLNS].

4.5.4. Namespace Documents

However, the term "definitive" is missing. Was this intentional? Based on a quick skimming of the issue, it looks like the TAG is in agreement that the namespace document should directly or indirectly provide *definitive* material about the namespace, but I'm not sure.

The TAG agrees but for consistency prefers the term "authoritative".

issue booth3: 4.5.4: NS document as definitive source of info on namespace
clarification decided 2004-02-20

There are many reasons to provide information about a namespace. A person might want to:

• understand its purpose,
• learn how to use the markup vocabulary in the namespace,
• find out who controls it,
• request authority to access schemas or collateral material about it, or
• report a bug or situation that could be considered an error in some collateral material.

A processor might want to:

• retrieve a schema, for validation,
• retrieve a style sheet, for presentation, or
• retrieve ontologies, for making inferences.

In general, there is no established best practice for creating a namespace document. Application expectations will influence what data format or formats are used to create a namespace document. Application expectations will also influence whether relevant information appears in the namespace document itself or is referenced from it.

For example, the following are examples of formats used to create namespace documents: [OWL10], [RDDL], [XMLSCHEMA], and [XHTML11]. Each of these formats meets different requirements described above for satisfying the needs of an agent that wants more information about the namespace. Note, however, issues related to fragment identifiers and multiple representations if content negotiation is used with namespace documents.

See TAG issues namespaceDocument-8 and abstractComponentRefs-37.

4.5.5. QNames in XML

Below the Good Practice: QName Mapping - the section (or some other) should probably say more on the interaction of QName Mapping, fragment identifiers in XML (4.5.8) commonly used for this mapping and namespace documents (4.5.4)

Overtaken by events.

issue kopecky5: 4.5.5 More info on qnames, fragids, ns docs
request decided 2004-02-23

Section 3 of "Namespaces in XML" [XMLNS] provides a syntactic construct known as a QName for the compact expression of qualified names in XML documents. A qualified name is a pair consisting of a URI, which names a namespace, and a local name placed within that namespace. "Namespaces in XML" provides for the use of QNames as names for XML elements and attributes.

Other specifications, starting with [XSLT10], have employed the idea of using QNames in contexts other than element and attribute names, for example in attribute values and in element content. However, general XML processors cannot recognize QNames as such when they are used in attribute values and in element content; they are indistinguishable from URIs. Experience has also revealed other limitations to QNames, such as losing namespace bindings after XML canonicalization.

For more information, see the TAG finding "Using QNames as Identifiers in Content".

Because QNames are compact, some specifications have adopted the same syntax as a means of identifying Web resources. Though convenient as a shorthand notation, this usage has a cost. There is no single, accepted way to convert a QName into a URI or vice-versa. Although QNames are convenient, they do not replace the URI as the identification mechanism of the Web. The use of QNames to identify Web resources without providing a mapping to URIs is inconsistent with Web architecture.

For examples of QName-to-URI mappings, see [RDF10]. See also TAG issues rdfmsQnameUriMapping-6, qnameAsId-18, and abstractComponentRefs-37.

4.5.6. XML ID Semantics

This section lacks a conclusion, any kind of statement on what should/should not be used. Or words that at the moment there is no conclusion.

The TAG believes this is an open issue in Web architecture, which the Editor should highlight more in the text.

Overtaken by events.

issue kopecky6: 4.5.6 What's the conclusion?
request decided 2004-02-23

[4.5.6] Fails to careful highlight the particular flavours of "ID" in play, and that they are NOT the same thing. For example, consider the following three statements:

"Does the section element have the ID "foo"?" (This needs to be something like "Does the section element have what the XML Recommendation refers to as the ID "foo"? ") "Processing the document with a W3C XML Schema might reveal an element declaration that identifies the name attribute as an xs:ID." (This one is probably OK.) "In practice, processing the document with another schema language, such as RELAX NG [RELAXNG], might reveal the attributes of type ID." (What is a "type ID" here? If it's RELAX using the schema data types, then isn't it xs:ID in this case?)

In practice, applications may have independent means of specifying IDness as provided for and specified in XPointer. XPointer carefully discusses these options.

The TAG believes that the 10 May 2004 draft addresses the reviewer's concern, with the following changes:

change fourth bullet in 10 May 2004 draft to read "In practice, applications may have independent means of locating identifiers inside a document such as provided for and specified in the XPointer specification." Include a reference to section 3.2.

issue schema20: [4.5.6] Flavors of ID not discussed
error decided 2004-03-04

Consider the following fragment of XML: <section name="foo">. Does the section element have the ID "foo"? One cannot answer this question by examining the element and its attributes alone. In XML, the quality of "being an ID" is associated with the type of the attribute, not its name. Finding the IDs in a document requires additional processing.

1. Processing the document with a processor that recognizes DTD attribute list declarations (in the external or internal subset) might reveal a declaration that identifies the name attribute as an ID. Note: This processing is not necessarily part of validation. A non-validating, DTD-aware processor can perform ID assignment.
2. Processing the document with a W3C XML Schema might reveal an element declaration that identifies the name attribute as an xs:ID.
3. In practice, processing the document with another schema language, such as RELAX NG [RELAXNG], might reveal the attributes of type ID. Many modern specifications begin processing XML at the Infoset [INFOSET] level and do not specify normatively how an Infoset is constructed. For those specifications, any process that establishes the ID type in the Infoset (and Post Schema Validation Infoset (PSVI) defined in [XMLSCHEMA]) may usefully identify the attributes of type ID.

To further complicate matters, DTDs establish the ID type in the Infoset whereas W3C XML Schema produces a PSVI but does not modify the original Infoset. This leaves open the possibility that a processor might only look in the Infoset and consequently would fail to recognize schema-assigned IDs.

See TAG issue xmlIDSemantics-32.

4.5.7. Media Types for XML

These Internet Media Types create two problems: First, for data identified as "text/*", Web intermediaries are allowed to "transcode", i.e., convert one character encoding to another. Transcoding may make the self-description false or may cause the document to be not well-formed.

The statement "Web intermediaries are allowed to "transcode ..." seemed to me to be rather broadly applied here. Is there a specification that asserts this in general? If not, I think the comment should be constrained to something like "in some Web applications, intermediaries are allowed to transcode.

issue klyne26: Transcoding allowing by some or all intermediaries?
clarification raised 2004-03-05

RFC 3023 defines the Internet Media Types "application/xml" and "text/xml", and describes a convention whereby XML-based data formats use Internet Media Types with a "+xml" suffix, for example "image/svg+xml".

These Internet Media Types create two problems: First, for data identified as "text/*", Web intermediaries are allowed to "transcode", i.e., convert one character encoding to another. Transcoding may make the self-description false or may cause the document to be not well-formed.

Second, representations whose Internet Media Types begin with "text/" are required, unless the charset parameter is specified, to be considered to be encoded in US-ASCII. Since the syntax of XML is designed to make documents self-describing, it is good practice to omit the charset parameter, and since XML is very often not encoded in US-ASCII, the use of "text/" Internet Media Types effectively precludes this good practice.

4.5.8. Fragment Identifiers in XML

The section on media types and fragment identifier semantics discusses the interpretation of fragment identifiers. Designers of an XML-based data format specification should define the semantics of fragment identifiers in that format. The XPointer Framework [XPTRFR] provides a interoperable starting point.

When the media type assigned to representation data is "application/xml", there are no semantics defined for fragment identifiers, and authors should not make use of fragment identifiers in such data. The same is true if the assigned media type has the suffix "+xml" (defined in "XML Media Types" [RFC3023]), and the data format specification does not specify fragment identifier semantics. In short, just knowing that content is XML does not provide information about fragment identifier semantics.

Many people assume that the fragment identifier #abc, when referring to XML data, identifies the element in the document with the ID "abc". However, there is no normative support for this assumption.

See TAG issue fragmentInXML-28.