Topic

• ❑ key:
  • ❑ quoted text
  • ❑ commentary/justification
  • ❑ replacement text
  • ✓ agenda request
• ❑ Architecture of the World Wide Web, First Edition Editor's Draft 28 September 2004 http://www.w3.org/2001/tag/webarch/
  • ❑ global comment: the document makes a large number of important points, some of them quite subtle. In some cases, the organization into story, principles, etc. is clearly effective, but in other cases, I guess we got tired because it looks like we just sorta pasted a bunch of thought-fragments together. I wish we had sufficient inspiration to give a uniformly excellent treatment.
  • ❑ copyright
    • ❑ Your interactions with this site are in accordance with our public and Member privacy statements.
      • ❑ that always seemed curious to me.
  • ❑ Abstract
    • ❑ In each of these systems, people and software retrieve, create, display, analyze, relate, and reason about resources.
      • ❑ people retrieve representations of resources. Yes, this is just the abstract, but it's not exactly written in newspaper English. Let's either be conversational or precise, not academic and confusing.
    • ❑ constraints on the behavior of systems that use the Web
      • ❑ I thought the constraints were on things like clients, servers, and data formats, not systems like the hypertext web and the semantic web. hmm..
    • ✓ The World Wide Web is the result of relatively simple technologies with sufficient scalability, efficiency and utility that they have resulted in a remarkable information space of interrelated resources, growing across languages, cultures, and media. In an effort to preserve these properties of the information space as the technologies evolve, this architecture document discusses the core design components of the Web (identification of resources, representation of resource state, and the protocols that support the interaction between agents and resources in the space) as well as constraints and good practices and relates them to the principles and properties they support.
      • ✓ I left out "information systems"; is it needed in the abstract?
      • ✓ I left out "people and software retrieve, create, display, analyze, relate, and reason about resources"; is it needed in the abstract?
  • ❑ 1 Intro
    • ❑ in which the items of interest, referred to as resources
      • ❑ no <dfn> around resources?
    • ❑ Examples such as the following travel scenario are used throughout this document to illustrate typical behavior
      • ❑ overly self-referential; suggest just:
        • ❑ Consider:
      • ❑ move Web agents stuff to after 1st story blurb. or get rid of it; why is it here, rather than, say, under interaction? just:
    • ❑ the properties we desire
      • ❑ 1st person?
    • ✓ The terms MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY are used in the principles, constraints, and good practice notes in accordance with RFC 2119 [RFC2119]. However, this document does not include conformance provisions for these reasons
      • ✓ that's contradictory; RFC2119 says MUST/MAY/SHOULD are all about conformance.
    • ❑ This document is intended to inform discussions about issues of Web architecture.
      • ❑ what's that got to do with audience? suggest striking it.
    • ❑ Participants in W3C Activities
      • ❑ the main point is to preserve principles of web architecture as we evolve the technologies, so:
        • ❑ developers of new web technologies, especially participants in W3C Activities
    • ❑ Other groups inside and outside W3C also address specialized aspects of Web architecture, including accessibility, internationalization, device independence, and Web Services.
      • ❑ + QA; cf metadata inconsistency stuff
    • ❑ For instance, when a graphical user agent running on a laptop computer or hand-held device encounters an error, the user agent can report errors directly to the user through visual and audio cues, and present the user with options for resolving the errors. On the other hand, when someone is browsing the Web through voice input and audio-only output, stopping the dialog to wait for user input may reduce usability since it is so easy to "lose one's place" when browsing with only audio-output.
      • ❑ isn't there a more relevant section for that comment?
  • ❑ 2.1. Benefits of URIs
    • ❑ There are substantial benefits to participating in the existing network of URIs
      • ❑ "substantial" is like "very"; never use it. suggest:
        • ❑ The benefits of participating in the existing network of URIs include:
    • ❑ To benefit from and increase the value of the World Wide Web, agents should provide URIs as identifiers for resources.
      • ❑ agents? I think this is more relevant as a constraint on data formats, near the discussion of the qname mess and Good practice: Link identification under 4.4:
        • ❑ To benefit from and increase the value of the World Wide Web, data formats should use URI references to refer between resources
      • ❑ hmm... I guess it's relevant to server design, i.e. using REST rather than hiding structure in javascript. hmm... how to say that more directly...
  • ❑ 2.2
    • ❑ We do not limit the scope of what might be a resource. The term "resource" is used
      • ❑ the 2nd is actually the defining occurrence, no?
  • ❑ 2.3
    • ❑ Web architecture allows the association of more than one URI with a resource. URIs that identify the same resource are called URI aliases. The section on URI aliases (§2.3.1) discusses some of the potential costs of creating multiple URIs for the same resource.
      • ❑ delete 2nd sentence; move defining instance to 2.3.1
    • ✓ 2.2.1.1. URI ownership
      • ✓ where did the example of http/DNS go?
    • ✓ For example, the specification of the data URL scheme [RFC2397] serves as owner of all data scheme URI
      • ✓ no! data: URIs have no owner; they just are.
    • ❑ 2.2.3. Indirect Identification
      • ❑ cite foaf:mbox, owl:InverseFunctionalProperty
      • ❑ perhaps discuss reference by description; analogy: URI:name::ifp construct::noun phrase; move 2.7.2. Assertion that two URIs identify the same resource here
    • ❑ The community benefits when the URI owner supports redirection of an aliased URI to the corresponding "official" URI.
      • ❑ let's say how.
    • ✓ The distinguishing characteristic of representation reuse, as opposed to aliasing, is that the underlying resources are different.
      • ✓ not testable; perhaps...
        • ✓ that the URI owner has chosen different resources for them to refer to
  • ❑ 2.5 URI Opacity
    • ❑ Good practice: URI opacity
      • ❑ opacity is a MUST; if the point is too subtle to make in bumper-sticker style, delete the box?
    • ❑ The "mailto" URI scheme specification
      • ❑ cite by chapter and verse
    • ✓ 2.5. URI Opacity (whole section)
      • ✓ this section doesn't make the main point, which is that owners get to decide what URIs mean; opacity violations are the subject of siteData-36; where did the reference to that issue go?
  • ❑ 2.7 URI future directions
    • ❑ 2.7.2. Assertion that two URIs identify the same resource
      • ❑ move under 2.2.3. Indirect Identification
  • ❑ 3. Interaction
    • ❑ such as the "Alternates" and "Vary" HTTP headers
      • ❑ isn't Vary message metadata, rather than resource metadata?
    • ❑ The browser configuration determines how it locates the identified information, which might be via a cache of prior retrieval actions, by contacting an intermediary (such as a proxy server), or by direct access to the server identified by a portion of the URI.
      • ❑ in the story, pick one; discuss the others after the story box or in other story boxes
    • ❑ This section describes the architectural principles and constraints regarding interactions between agents, including such topics as network protocols and interaction styles, along with interactions between the Web as a system and the people that make use of it. The fact that the Web is a highly distributed system affects architectural constraints and assumptions about interactions.
      • ❑ overly self-referential; each section needs a preface now? plus, what's the point of this para? lose it.
  • ❑ 3.2
    • ❑ Efforts like the Semantic Web are seeking to provide a framework for accurately communicating the semantics of a resource in a machine readable way. Machine readable semantics may alleviate some of the ambiguity associated with natural language descriptions of resources.
      • ❑ this sounds like ambiguity is always bad. I don't see the point. strike?
  • ❑ 3.3
    • ❑ The Internet media type [RFC2046])
      • ❑ stray )
    • ❑ The Internet media type [RFC2046]) of a representation determines which data format specification(s) provide the authoritative interpretation of the representation data
      • ❑ obscures the point by talking too much about specifications.
        • ❑ a representation consists of a sequence of bytes plus an Internet Media Type [RFC2046] which tells whether the bytes represent text, graphics, video, a spreadsheet, etc. The IANA registry [MEDIATYPEREG] maps media type names to data format specifications (§4).
    • ❑ For instance, media type strings do not support versioning (§4.2.1) or other parameters.
      • ❑ yes they do; perhaps poorly, but they do.
    • ❑ delimiter from the URI syntax [URI]
      • ❑ [URI] seems spurious; delete?
    • ❑ without requiring an upgrade
      • ❑ ... upgrade.
    • ❑ The semantics of a fragment identifier are defined by the set of representations that might result from a retrieval action on the primary resource.
      • ❑ "might" seems awkward; perhaps:
        • ❑ are defined to be consistent across representations of the primary resource
    • ❑ # A resource may be both a primary and secondary resource since more than one URI may identify the resource. # One cannot carry out an HTTP operation using a URI that identifies a secondary resource.
      • ❑ contradictory; suggest striking the 2nd bullet (the point is made above already redundantly again) and moving the 1st bullet into the para above.
    • ❑ Content negotiation refers to the practice of making available multiple representations via the same URI.
      • ❑ move out of this subsection to 3.2.1. Details of retrieving a representation
    • ❑ see [CUAP] for additional suggested agent behavior in this case.
      • ❑ which section?
    • ❑ See related TAG issue RDFinXHTML-35.
      • ❑ move closer to bullet 1 re "The representation provider decides when definitions of fragment identifier semantics are are sufficiently consistent."
  • ❑ 3.4 Inconsistencies ...
    • ❑ At times, there may be inconsistencies between a message sender's data and metadata.
      • ❑ makes it sound like this is OK. suggest:
        • ❑ Sometimes shit happens and there are inconsistencies...
      • ❑ 1/2 ;-)
    • ❑ Nadia's browser must not ignore the problem (e.g., by simply rendering the JPEG image) without Nadia's consent.
      • ❑ TAG decided by fiat? say why:
        • ❑ without Nadia's consent, or it would no longer be faithfully representing Nadia and the information provider to each other.
      • ❑
    • ❑ Principle: Data-metadata inconsistency
      • ✓ change to constraint
      • ❑ fwd ref 5.3 esp "Principle: Error recovery"
    • ❑ Server managers SHOULD allow representation creators to control the metadata associated with their representations.
      • ❑ gee; can I have a GPN about my personal pet pieve too? Are we giving these to the squeaky wheel? what does this say about Web architecture? it's a QA issues; let's acknowledge the overlap with QA in the preface as well as citing [CUAP] and [CHIPS]. People who are fired up about this stuff should join the QA WG, not the TAG.
  • ❑ 3.5 Safe...
    • ❑ An agent may incur an obligation through other means (such as by signing a contract).
      • ❑ disconnected; suggest:
        • ❑ An agent may incur a related obligation through other means (such as by signing a contract before the retrieval).
    • ❑ Note that neither the data transmitted with the POST nor the data received in the response necessarily correspond to any resource identified by a URI.
      • ❑ move outside the story
    • ❑ Remember that search engines may follow such hypertext links.
      • ❑ you already said that already redundantly already.
    • ❑ At times, there may be good reasons (such as confidentiality requirements or practical limits on URI length) ) to conduct an otherwise safe operation ...
      • ❑ "at times" is awkward and irrelevant; suggest:
        • ❑ Some circumstances (such as confidentiality requirements or practical limits on URI length) ) merit conducting an otherwise safe operation ...
  • ❑ 3.6 Representation Management
    • ❑ see [Cool]
      • ❑ too cute; suggest
        • ❑ see [Berners-Lee90]
      • ❑ or some such; at least
        • ❑ see [CoolURI]
    • ❑ Since Dirk is also a subscriber to services provided by "weather.example.com,"
      • ❑ anthropomorphism. suggest:
        • ❑ services provided by that organization
  • ❑ 3.8 Future...
    • ❑ There remain open questions regarding Web interactions.
      • ❑ suggests once we answer the open questions, we'll be done. Not so; the web will continue to evolve as long as it's usefully in operation. suggest:
        • ❑ Web interactions are evolving beyond HTTP 1.1 and the other traditional Internet protocols (FTP, SMTP).
  • ❑ 4. Data Formats
    • ❑ Thus, before inventing a new data format (or "meta" format such as XML), designers should carefully consider re-using one that is already available.
      • ❑ hmm... is that worth generalizing and/or promoting to a box about technology reuse and deployment?
    • ❑ For a data format to be usefully interoperable between two parties, the parties must agree (to a reasonable extent) about its syntax and semantics.
      • ✓ this is the place to introduce/define internet media types, no? see comments on 3.3 above. neither "data format" nor "internet media type" occurs in the glossary; bug?
      • ❑ hmm... no story to hang the concepts in this section onto
      • ❑ this is an example of a point we don't make about URI-based pivot points
  • ❑ 4.1 Text/binary
    • ❑ and compressed data of all sorts
      • ❑ lots of compressed data is text, no? suggest: strike
    • ✓ Also, they can be consumed more rapidly by agents in those cases where they can be loaded into memory and used with little or no conversion.
      • ✓ need to note security issues there!!!
    • ❑ Textual formats are usually more portable and interoperable.
      • ❑ interoperable??? anybody have any data to support that?
  • ❑ 4.2. Versioning and Extensibility
    • ✓ In a perfect world...
      • ✓ well said!
    • ❑ Nadia and Dirk are designing an XML data format to encode data about the film industry.
      • ❑ Nadia was a naive web user when our story began; how about new characters here?
    • ✓ A specification SHOULD provide mechanisms that allow any party to create extensions.
      • ✓ The surrounding text is good, but this is still too strong. Should Euclid's list of 5 postulates be extensible? Maybe some sort of counter to the 0/1/infinity principle...
        • ✓ any essentially arbitrary list should be extensible
    • ❑ "Must ignore": The agent ignores any content it does not recognize.
      • ❑ please let's describe that in terms of meaning of documents, i.e.
        • ❑ the sender agrees that the resource is also represented by the results of deleting the "unrecognized" content
      • ❑
  • ❑ 4.3 Separation...
    • ❑ It is good practice for authors to create content that can reach the widest possible audience, including users with graphical desktop computers, hand-held devices and mobile phones, users with disabilities who may require speech synthesizers, and devices not yet imagined.
      • ❑ sounds like "By the power vested in the TAG..." i.e. fiat, again. suggest:
        • ❑ Because content is usually produced once and consumed many times, authors should create...
  • ❑ 4.4 Hypertext
    • ❑ Good practice: Link identification
      • ❑ The point is to use URI syntax for references. see comments on Good practice: Identify with URIs above. move under 4.4.1 URI references?
  • ❑ 4.5. XML-Based Data Formats
    • ❑ I'm mostly skimming this section
    • ✓ Good practice: QNames Indistinguishable from URIs
      • ✓ this is a constraint; s/SHOULD NOT/do not/
    • ❑ 4.5.8. Fragment identifiers in XML
      • ❑ should cite TAG issue RDFinXHTML-35 too; maybe the bit about fragment identifier consistency should forward reference to 4.5.8
  • ❑ 5.2. Extensibility
    • ❑ I wish we'd been more inspired about URI-based pivot points.
    • ❑ Subset language: 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.
      • ❑ I tried to formalize this (@@point to changePolicy.n3) and it fell apart; one document can't be in 2 languages as we've designed it
    • ❑ For further discussion, see the section on versioning and extensibility (§4.2).
      • ❑ this is no longer a forward reference; suggest make a forward reference from 4.2 to 5.2