W3C | TAG | Previous: 29 Sep teleconf | Next: 20 Oct 2003 teleconference

Minutes of 6-8 October 2003 TAG face-to-face meeting in Bristol

Nearby: Teleconference details · issues list (handling new issues)· www-tag archive

TAG group photo

Roll call from right: Stuart Williams (Chair), Roy Fielding, Norm Walsh Chris Lilley, Tim Berners-Lee (Virtually), Paul Cotton, David Orchard, Tim Bray (front), Ian Jacobs. Regrets: Dan Connolly. Photo by Stuart Williams.

Agenda:

  1. Administrative
  2. Architecture Document
  3. Findings and Issues

1. Administrative

The TAG would like to thank Jan Ward, Dave Cartwright for networking, Julie Lamphere and Deb French for other local arrangements, Peter Cook for other local arrangements, Mike Womham for A/V in the US, Stuart Williams for hosting, and Hewlett-Packard for outstanding support of this face-to-face meeting.

  1. Accepted the minutes of the 29 Sep teleconf
  2. Accepted this agenda
  3. Next meeting: 20 Oct 2003 teleconference

1.1 TAG update at Nov 2003 AC meeting.

  1. Completed action SW 2003/09/29: Draft summary based on monthly reports from previous six months (for AC meeting). See previous highlights.
  2. What to do with TAG slot?

[Ian]

PC: I think "drier" material can go in COO highlight; punch up the presentation for the TAG's ftf update to AC.
Resolved: SW to send summary of TAG accomplishments to Steve Bratt, with some editorial changes.
Action SW to send summary of TAG accomplishments to Steve Bratt, with some editorial changes.
TAG update at AC meeting.
IJ: We have about an hour, including discussion.
Action DO, CL: Draft outline of a presentation for the AC; details to follow.
PC: Should mention of binary XML workshop be part of report? I haven't seen any report from workshop.
DO: We could talk about which constraints imply. which properties.
PC: We could ask the AC if they agree with the findings
IJ: Do we really want to solicit review of the findings in tha forum?
PC: Mostly about presenting technical work to the AC.
IJ, SW: We are also happy to help CL and DO prepare a report.

1.2 TAG participation in Tech Plenary 2004 (1-5 March)

  1. Completed action SW 2003/09/29: Status of SW response to TP planners.

See thread with concrete commitments

PC: Some discussion last night at Stuart's house. Big advantages of TAG presence at Tech Plenary:
  1. Hallway talk
  2. Coordination with other groups
SW: I think I can be there for a TAG meeting
Completed Action SW: Schedule a TAG meeting for Monday and Tuesday of Tech Plenary week.

2. Architecture Document

The TAG reviewed the 1 Oct 2003 WD of the Arch Doc.

  1. Overall sense of document
  2. Walk-through 6 Oct
  3. Walk-through 7 Oct
  4. Walk-through 8 Oct
  5. Review of action items related to architecture document
  6. Last call expectations, schedule

2.1 Overall sense of document

[Ian]

TB: Let's start with a meta-discussion: "Is the document roughly ok?" The document is missing an important arch principle, along the lines of: "Specify interoperability at the level of syntax, not in data structures."
RF: Self-descriptive syntax.
[Ian]
Round the table on the question of "Sense of the document generally"
DO: While I think the doc is shaping up, I don't think we will leave this meeting with a last call document. We need to be more precise with our terminology. I'd like to be sure we include architectural diagrams.
NW: I think the doc is shaping up. I think that the things it says it says reasonably well.
CL: Yes, shaping up. Not sure reading order is quite right. I think we need to go to last call to get feedback from wider audience.
RF: The doc is significantly better than ones we've published in the past. However, it addresses two audiences, falling somewhere between a set of point findings and a 12-year-old level tutorial on how to operate a Web browser. Alternating between audiences. My overall view of around the first third of the document, we have lots of technical direction, almost no rationale, and nothing on requirements for what the Web actually needs.
PC: I am more date-driven than content-driven; I think we need to get to last call.
RF: We need to be clear that the document says what the customer wants and that the document states what that is. I think that the demand was for more rationale.
SW: I like the tripod shape of the document. I am disappointed that we don't have more in the interaction section. I find that the document meanders. I'm not sure what the message of the document is. I'd like the document to be very compact, with rationale available but external. I think the findings series is very useful. Is a collection of findings, I wonder, more useful than a single "masterwork". Process question - what is the (normative) status of findings? This is more relevant if we take the path of writing a terse arch doc.
TB: I think I agree with PC here: I think the document is useful and doesn't have egregious bugs. We should ship it (to last call). I think the document is pretty good. I read it and was left with a generally good impression. On the question of "what's the audience", I'm not sure. But I have a gut sense that the document will be useful. I strongly move that we advance to last call after one more round of edits. I acknowledge RF's point that there's not enough in the way of rationale. I'm ok with that and ok with the two tones (story/highly technical point). The only way I know of right now to find out if useful is to get it out to the world.
PC: Noah Mendelsohn (at tech plenary 2003) gave a similar response as RF - not sure the document conveys "the architecture of the Web". One reason that may be the case - the TAG has been responding to issues, and those issues are documented in our findings. Arch doc needs to make a clear statement about relationship to findings; ensure that all normative bits are in arch doc. I think the "requirements" are probably what the community asked us as questions during the first 20 months of the TAG.
NW: As I was reading, I asked myself "Is there anything I would be embarrassed to ship as a last call doc?" I think it's ok, even if it's imperfect.
RF: The arch doc is effectively a table of contents. Why not publish the findings as last call documents? The arch doc contains very little "verifiable" material.
CL: One reason the doc doesn't look like a "classical" arch document is that we are deriving the model from experience, not designing it up front.
DO: In our early meetings we established that we were not going to work on a classical arch doc. We might want to explain this position in the architecture document.
[Some consenting nods around the table]
DO: In this version (v 1.0) we should "set up" what we would need in a later, more formal version. For example (to reiterate), formalizing terms and using diagrams.
[Discussion of findings -> Note]
IJ: My comments on the doc: Not the doc I would write, but probably an accurate reflection of our consensus. I would like to have more rationale. I am very happy with the findings process and would like us to be sure to continue to invest there.
CL: Findings more visible from TR page.
PC: I think that we should ensure that normative bits are in arch doc (not just in the findings) and say so in the arch doc. I think the arch doc needs to be approachable by Web designers. The same goes for the findings.
RF: Who do you mean by Web designers? Software developers, authors, or spec designers?
TB: I want implementers to read this.
RF: I want this document to be readable by software developers. To be so, it needs to be readable at a consistent level. If we are going to use the scenarios the way we are using them, we have to assume the reader is familiar with the Web. We don't want to take time to explain what a browser or Web site are. We definitely want a glossary, but in describing a scenario, we don't want to explain the terms. Don't make developers read lots of non-normative text. If we're not going to cover rationale and requirements, why are we covering material that our audience already knows?
TB: They don't know; people get it wrong all the time.
RF: But that's because they don't understand the rationale.
IJ: I am looking for suggestions on making the arch doc development process run more smoothly. I feel I am waiting for text at times. Can I help get the juices flowing somehow? Any suggestions for improving efficiency?

RF: Some statements are wrong; would have been revealed sooner if there was more rationale.

2.2 Walk-through 6 Oct

[Ian]
Abstract
TB: One material comment: "and reason about". Not sure what is meant by that.
RF: "Reason about" is a bone for the Sem Web folks. Includes inference engines in the system.
TB: s/reason/compute inferences/?
SW, RF: Prefer "reason"
[IJ discusses some history of this abstract.]
DO: I have some problems with this abstract; favor talking about URIs and representations.
TB: I think this approach is more useful as a tutorial.
DO: Talking about the Web as an information space as a system of resources (including me, since I can have a URI) confuses me; I don't understand in terms of an information space.
RF: Consider object-oriented design: each object has identity and state information. You can be in information system since I see you, and that is conveyed to me. The only thing that crosses the Web (interaction) is information. We can only exchange information; I can't reach over and tap you on the shoulder. If we talk about the Web as an infospace, we can talk about its effect on various systems that use the space. E.g., how does the Web Services system relate to the info space? E.g., addressability. Fine with me if abstract of document reduced to one sentence and the rest of the material moved to the introduction.
IJ: My questions related to the abstract:
  1. Why not list examples of systems that make use of the info system? (Doing so helped me.)
  2. If talking about info space, need to say more about how it ties into the rest of the document. What does it motivate?
[Looking at first sentence of intro]
RF: I'd rather not talk about "information objects"; too much preconception attached.
CL: Propose to reorient the abstract to focus on URIs. Have two properties - identify resources, used as links.
RF: It is reasonable to do so; URIs distinguish the Web from other hypertext systems. You could say "in which things of interest, referred to collectively as resources"
IJ: I have a preference for resource-centrism over URI-centrism in the abstract.
SW: Caution - fewer changes we make, more likely we are to make fewer changes at this point. Can people live with the abstract as is?
IJ: Sentence "Web architecture is influenced by social..." could live happily in intro.
NW: Write the abstract after we've written the rest of the document.
Action IJ: Add ed note to abstract that the abstract will be rewritten.
Status of this document
PC: In status section, indicate that all normative stuff is in the arch doc, may be repeated (and annotated) in findings.
IJ: What does it mean to be normative for this document? Sub-question of usage of RFC2119.
PC: In general, groups within W3C or outside who don't feel they should follow this document should come to the TAG and explain why.
IJ: What does conformance mean to it? I don't know how much a conformance section applies in this document.
RF: Normative not same as conformance. This document and things that have been reviewed formally would make this entire document (but not, e.g., findings) normative.
IJ: What does MUST mean here?
[We review RFC2119]
RF: We don't need the MUST/SHOULD/MAY.
IJ: In UAAG 1.0 we use the imperative. The question is: do we need finer granularity than that? Also, note that in some cases we use specific subjects (e..g, server managers). I hear (1) some statements relate closely to protocols; use MUST/SHOULD/MAY for those OR, (2) don't use them, and rewrite the principles to be, e.g., statements of fact (CANNOT v. MUST NOT).
RF: It doesn't add much value to say "MUST" instead of "must" since we are not measuring conformance.
PC: We may want conformance for WGs to certain of the notes.
IJ: My question remains, who would want to say (ever) "I conform to the arch doc"?
PC: Different principles are addressed to different, or multiple audiences.
RF: Reserve usage of MUST/SHOULD/MAY to cases where we expect a W3C group (or some other body) to conform.
TB: I'd like to tell the programmers of the world "do this".
[Chris]
expected readership should be explicitly noted in the status of this document
[Ian]
IJ: I kind of hear people talking about profiles, but I"m not sure that all audiences will be interested in claiming conformance in practice.

IJ proposal: Don't use capital letters with MUST/SHOULD/MAY. Provide a view of the document for each type of audience (e.g., developers v. authors).

IJ: Proposal -(1) use 2119 terms appropriately, and only use those terms for things related to conformance (2) Provide views for different audiences (e.g., authors, server managers)
IJ: I think I will add ed note talking about ongoing work related to what conformance means.
TB: Also, write principles with specific audiences in mind.

Resolved:

  1. Use 2119 appropriately, with the semantics of MUST/SHOULD/MAY
  2. Assert in front matter that we are so doing.
  3. List targets of assertions explicitly.
CL: We must define what conformance is before we go to last call. We must have addressed the concept of conformance, otherwise people will complain.
1. Introduction
PC: My browser (IE Windows) handles boxes around stories badly when printed.
First sentence of intro.
Some support for "things of interest" instead of "information objects"
[No consensus to get rid of <code> around URIs]
PC: In bullet three after story, change "A resource communicates everything about its state through these representations" to "A resource communicates state information through these representations"
PC: Bullet three - not all messages carry representations. Only some do.
Agreement on two things:
  1. Only some messages carry representations
  2. Some representations available but not through messages (e.g., file access)
CL: In bullet two, "Web agents exchange information over a network via messages."
DO: In bullet two, this sentence leans towards "traditional" Web rather than e.g., Web services: "these messages arise as the result of actions requested by a user or called for by a rendering engine while processing hypermedia-aware data formats. "
IJ: Move the interaction bit down to the story: "In this scenario, Nadia initiates a series of messages by telling her browser...." (I.e., move the bit about messages to the story).
RF: You could avoid the concept of messages here, and just talk about protocol interactions.
DO: I would like to have messages up front.
RF: But it's not always about messages; sometimes it's about file system, e.g., I suggest d/Web agents exchange information via messages; these messages arise as the result of actions requested by a user or called for by a rendering engine while processing hypermedia-aware data formats/. And d/Messages carry representations of a resource/.
[Roy]
in paragraph above numbered items, s/divisions/dimensions/
[Ian]
Resolved: Delete first sentences (about messages) from bullets 2, 3.
[RF comments about relevance v. completeness in talking about messages]
On the image in the introduction.
PC: Please make the example html -> Xhtml (since scenario says so). Please label first figure "Fig 1" for backwards refs.
---
Editor's note: The TAG may include additional illustrations in this document to help explain important terms and their relationships.
DO: Where would we put global diagram to tie terms together?
IJ: Glossary. I think the diagram is the culmination of explanation; if the relationships are not discussed in the text, then there's a problem.
DO: I think there are advantages to an image for conveying complex relationships.
SW: I want the glossary to capture the definitions (duplicating what's in the narrative).
[Consensus to repeat term definitions in the glossary.]
We look atDO diagram
DO: Media type is important w.r.t. frag id, metadata, language.
IJ: Let's model these relationships in RDF and generate the diagram.
SW: Yes to such a diagram in the glossary.
TB: This diagram doesn't help me (if it's not in the text).
[Chris]
http://forums.objectsbydesign.com/showthread.php?s=&threadid=121
The production of this diagram was a breeze using Together Control Center 5.5 from TogetherSoft since the latest version now supports direct export of diagrams as SVG.
for example
http://www.objectsbydesign.com/tools/svg.html
check out that UML diagram, where the terms in the diagram hyperlink to their definitions
[Ian]
DO: I assert that the labels need to be defined as well.
TB: Would you be satisfied by links from the graphic to the sections in the doc where the relationships are defined? I want to avoid redefining relationship terms in the glossary; the narrative needs to do this (i.e., in one place).
[Chris]
Technical Report: Using XML and SVG to Generate Dynamic UML Diagrams
Authors: Justin Elsberry and Nicholas Elsberry
[Ian]
Action IJ: Starting from DO's diagram, create a diagram where the relationships and terms are linked back to the context where defined. Ensure that the relationships are in fact used in the narrative; any gaps identified?
RF: Make sure that the meaning of shapes and arrows are made clear.
1.1.1. Audience of this Document
CL: Break bullet three into two audiences:
  1. Implementers
  2. Publishers and authors
PC: Make sure the entities listed here correspond to entities that are the subjects of the good practice notes.
2. Identification and Resources
TB: In "When a representation of one resource refers to another resource with a URI, this represents a link" to "this constitutes a link".
RF: Delete "(URI), defined in "Uniform Resource Identifiers (URI): Generic Syntax" "
SW: On end note "1": Are there nuances between identify, designate, denote, refer to?
RF: Sem Web has a different definition of "identify" than other communities. "identify" is not equivalent to "name". It might satisfy the sem Web folks if we define what "identify" means. In end note, s/name/to distinguish it from all other things.
Action RF: Explain "identifies" in RFC 2396bis
RF: Create a new section on "Links" before "When a representation of one resource...."
TB: s/namespace references/resources in second para of 2.
RF: I have editorial comments on third para of section 2. [See RF's printed edited copy.]
TB: "Semantic Web assertions can be seen as links."
RF: s/namespace references/assertions/
[Discussion of ontology of links]
TB: A strength of the Web is that once a link is defined, it can be used in many ways and the arch doesn't get in the way.
DO: Diagram is missing the term "link"
RF: Links can occur in metadata and header fields.
IJ: Do we intend to use the word "hyperlink" in the document (as a subclass of link)?
TB: I suggest we stay away from it. Instead focus on different behaviors user agents can engage in (depending on context) once the relationship has been established.
RF: "Hypertext" is a UI-defined concept. Hypermedia is a subset of hypertext.
IJ: I like the idea of talking about application-specific uses of links and avoiding laden terms.
RF: It will be hard to talk about interaction without talking about hypertext.
Consensus: s/represents a link/constitutes a link/
DO:
IJ trying to summarize: Links represent relationships. How the relationships are exploited by agents depending on context. Application context may involve additional metadata (such as link type).
RF: Avoid "represent", "object" and other terms we use frequently. A link *is* a relationship.
IJ writing more clearly: A link is a relationship. User agents may exploit this relationship in diverse ways (give context examples from TB). In a given context, a relationship may involve additional information (e.g., link type).
TB: I propose we delete ed note before 2.1.
PC: Could move to "future work"
SW: Let's discuss this when TBL is on the call (tomorrow): whether to delete the end note.
IJ: What about s/URIs identify resources/ with text in fourth para: "A URI must be assigned to a resource in order for the resource to be named, shared, or linked to within the information space. "
RF: A URI must be assigned to a resource in order for the resource to be linked within the information space.
2.1. Comparing Identifiers
TB: Good practice note in 2.1 doesn't work as written. What it's trying to say is: "If you get a URI, don't mess with it."
RF: "Use URIs consistently". This is for people who are transcribing URIs or who are writing code that processes URIs. I've seen code that gratuitously escapes characters (e.g., "-"). We're talking about people who create references.
TB: Or transcribe them.
RF: The motivation for this section is not comparing identifiers, it's reducing duplication of information. Comparing identifiers is something that happens in the process.
TB: Two issues
  1. Don't create URIs that are arbitrarily different.
  2. Don't mess with URIs when you transcribe them.
RF: The section advocates that people use URIs consistently.
TB: This is about syntactic consistency of URIs.
RF: If you change the section heading to "URI consistency" or "Syntactic consistency" and you start the section with: "URI producers should be conservative about the number of URIs they produce," then you can say why.
DO: Can we talk about "robustness" here?
[Chris]
avoid needless duplication
[Ian]
TB: Then, the orthogonal problem is people changing URIs on the way through. The reason is the same for both scenarios; people want to use strcmp.
RF: Start off with URI producers. Then say "Likewise, transcribers should..."
PC: Having multiple URIs for the same resource might help users by helping correct typing mistakes.
TB: I propose that we say that we also say that it's ok to mint more than one URI for the same resource when merited.
IJ: We need more motivation in front.
TB: I buy that, but I don't buy that it's to promote communication. The main usage I think of here is in my browser's cache.There are issues of efficiency and robustness (for programmers).E.g, don't publish www.example.com and www.Example.com since it requires more implementation work.
IJ: I'd still prefer to leave the section to be about URI comparison, and to leave the good practice note as an operational issue, within this section (rather than turning the section into a section on "Syntactic consistency").
Summarizing:
Proposal: Replace "There are many benefits to assigning a URI to a resource. Some are by design (e.g., linking, book marking, and caching), others (e.g., global search services) were not predicted.3" With better link to the URI finding AND a link to the finding.
PC: Include a forward pointer to "Web architecture does not constrain resources to be uniquely named; a resource may be assigned more than one URI." to the next section.
RF: I'm not sure whether "Unique name" is the right phrase in that section.
PC: "Web architecture does not constrain resources to be identified by a single URI"
CL: Be careful, I don't want people to conclude that a resource can be identified by zero URIs.
RF: Resources exist before URIs. It doesn't matter that the system can't see them. You can't say "Important resources have URIs" if they can't exist before URIs.
[Chris]
well, you can, but it becomes trivially true
2.1. Comparing Identifiers
[Ian]
RF: Please simplify "Although it is possible to determine that two URIs are equivalent, it is generally not possible to be sure that two URIs that are not equivalent identify different resources.". Get rid of double negative.
SW: I suggest "different".
s/agent/component in that sentence.
RF: One sentence paragraphs are bad. This page has a lot of them.
IJ: I may need to put "that are not based on strcmp" closer to "establish" just before 2.2.
2.2. URI Opacity
IJ: I think we need to fix the first sentence since it's over constraining; need to relax it (since some things are licensed by specs). Let's talk about the benefits of opacity up front. E.g., use this sentence up front "The more a piece of software depends on such inferences, the more fragile it becomes to change and the lower its generic utility."
RF: I agree with this move.
CL: Move the whole para, or try to combine.
IJ: Other args than robustness?
SW: If you are going to embed identifying information in a URI, don't put things in that change when the representation changes?
IJ: Don't put "/finaldraft" in the URI...
SW: Don't include metadata that you might want to include over time, do include metadata that won't change. Don't include mime types, do include the data of the document. I find the phrase "mint a URI" irritating.
[Chris]
coin a phrase, mint a uri
[Ian]
IJ: In short, I'd like more rationale up front of 2.2 about opacity as a design choice.
SW: On the question of authority....Larry Masinter has been talking about "authority" as a syntactic piece of a URI; authority (owner) of a URI is a non-existent concept.
RF: LM is overextending his point when he says that there are not authorities over a URI. To me, the authority means the organization that has been delegated the authority to mint URIs within that portion of URI space.
[Chris]
which can be at a finer level of granularity than the domain owner
[Ian]
RF: In good practice note of 2.2, delete "outside of their own authority" and "normative". For humans, it's ok to infer some properties, but not to dependent on them. For software, however, it's dangerous.
Software making use of URIs MUST NOT attempt to infer properties of the referenced resource except as licensed by relevant specifications or by URI assignment policies published by the relevant URI assignment authority.
s/Software/Web agents
"Web agents making use of URIs MUST NOT attempt to infer properties of the referenced resource except as licensed by relevant specifications."
Then, outside the note, indicate that in some cases relevant specs license assignment authorities to publish assignment policies.
RF: The following sentence is false: "On the other hand, the "mailto" URI scheme specification states that mail URIs identify Internet mailboxes." The spec says that mailto: URIs specify a form to be created for the process of sending mail.
"The mailto URL scheme is used to designate the Internet mailing address of an individual or service. In its simplest form, a mailto URL contains an Internet mail address." The "Usual semantics" discussed in section 3.
RF: Choose another URI scheme than "mailto" for point to be made in 2.2. URI schemes are primarily about the mechanism for assigning names, not about the type of thing identified. Maybe move 2.5 to section on Interaction.

2.3 Walk-through 7 Oct

section 3 Interaction

[Ian]

TB: Though it is incomplete, I would live with going to last call with 3 as is.
RF: Move much of 2.5 to section 3
TB: What distinguishes the Web from other distributed systems is that people can see the wire formats. The interaction between components is based on defining the wire formats. It's not about APIs.
Action TB: Write up a paragraph for section 3 on syntax-based interoperability.
RF: Rather "Networked-based API"
SW: Rather "Networked-based Interface"
[Roy]
http://www.ics.uci.edu/~fielding/pubs/dissertation/evaluation.htm#sec_6_5_1
[Ian]
RF: Move the part about media type from bullet 2 of 3 Interaction to its own section on Internet Media Types
[Chris]
putting Internet media types section in interaction reinforces that, for example, charset and other headers are only around while message passing is happening
[Ian]
RF: Put that section on media types before 3.2
In 3.1, the whole thing before "As described by the HTML spec" is story; belongs in a box.
PC: Move "This will include the role of architectural styles, such as REST and SOAP, and the impact of meta-architectures, such as Web Services and the Semantic Web." to future work.
TB: But this sentence needs surgery; SOAP is not an architectural style. Also, I don't know what a "meta-architecture" is.
IJ: Would we talk about info systems here (since Sem Web and Web Services mentioned).
RF: Yes, info system would be defined here. What makes it a system is the interactions between components. There would be a separate section on information systems.
DO: If we put a diagram in 3, put the generic diagram at the beginning of three, and the story-specific diagram in 3.1
RF: Clarification: "Information system v. Information space" would be a subsection of section 3. I would talk about information systems at the beginning of three, then a subsection on messages, and the story would be a subsection of the section on messages.
TB: 3.3 - turn the good practice note into an ordinary paragraph.
[Roy]
right
[Ian]
DO: People have told me that we need to distinguish more clearly things that produce and things that consume formats.
TB: Yes, we should make the point that Web protocols are not symmetric in general.
RF: For all URIs, you can use HTTP for GET since safe.
TB: HTTP URIs, as with many schemes, comes with an expected protocol, but that doesn't imply that (1) that protocol will be used or (2) other protocols will not be used.
IJ: I suggest making a new subsection of 2.5 (Using URI to access a resource) when it's moved to section 3.
SW: Are there other words than "expected Protocol" we could use?
[DO]
How about something like the following in 3.2. In this paper, we describe interaction between applications and languages in terms of senders and receivers. [Definition: A sender creates or produces an instance and sends it to another application for processing.] [Definition: A receiver consumes an instance that it obtained from a sender
[Roy]
http://www.gbiv.com/protocols/uri/rev-2002/rfc2396bis.html#identification
[Ian]
(Last para)
[IJ to distribute bullets in 3.4]
CL: "A format specification governs the handling of fragment identifiers." Only for the format itself, not for fragments contained in the format.
[Chris]
... only for inbound links to that format, not for fragments contained in that format that point to a different format
[Ian]
DO: Relation between "formats" and "languages"?
RF: Language is less specific than "format" in my experience. There are more languages and places where languages occur than formats. I Think that people who say "language" think of computer languages or human languages. But I think people use "format" for machine communication. In theoretical terms, they probably have the same meaning, but different social meanings.
SW: I could also see using "language" for more abstraction, "format" for serialization.
s/representations and formats/representation as section head
s/identification and resources/identification
TB: I'm uncomfortable talking about PNG as a language
SW: Need to be clear what we mean when we say vocabulary, format, language.
DO: I'm ok to say that a language is a subset of a format; just want to say what makes it a subset.
[Discussion of format/language]
NW, TB: Let's have an intro paragraph that says that we do not make a principled distinction between language and format. We use one or the other depending on context.
[DO]
Let's make it even stronger: format is a synonym for language in our document.
[Ian]
4.2. Error Handling
TB: In "specify error handling", make MUST rather than SHOULD. Specifying error handling promotes interoperability.
[Chris]
SVG error handling (to respond to Bray's comment): "There are various scenarios where an SVG document fragment is technically in error: When the content does not conform to the XML 1.0 specification [XML10], such as the use of incorrect XML syntax When an element or attribute is encountered in the document which is not part of the SVG DTD and which is not properly identified as being part of another namespace (see "Namespaces in XML" [XML-NS]) When an element has an attribute or property value which is not permissible according to this specification Other situations that are described as being in error in this specification"
[Ian]
RF: It's hard to make a MUST out of good practice.
[Chris]
also noteworthy: In particular, error processing shall be disabled whenever redraw has been suspended via DOM calls to suspendRedraw().
[Ian]
TB: I'm ok to buy that "MUST" is too strong. But let's include some examples from the Web (404, xml crash and burn on non-well-formed).
DO: Also, give some history about what the world was like before.
TB: TBL claims that one of the things that made the Web work was an explicit element in the protocol (404) to handle error conditions.
CL: Also need to handle how error handling imports into other specs (e.g., SVG imports xml well-formedness behavior).
[Chris]
and its not clear whether that is needed or not - did it need to be specifically imported?
[Ian]
TB: The experience from HTML suggested that ignoring unknown vocabulary elements was ok, but ill-formed syntax was not.
[Chris]
because of its alleged SGML basis, so empty elements were not recognizable. parsing not possible in the face of unknown elements
[Ian]
Action TB: Write a paragraph of rationale for why error handling good in the context of the Web.
IJ: General question - are there any subsections that are not specific to the architecture to the Web. What about binary v. textual?
TB: I'd keep it since "view source" is so important to the Web history. I think we can make a case on separation of content/presentation in terms of mobile devices.
IJ: Right, you don't know what device will be used at the other end. This distinguishes it from other systems, for example.
4.3. Information Hiding
CL: In SMIL, you have branching possibilities based on system parameters.
RF: I don't think 4.3 makes any sense.
TB: We're really talking about level mixing.
RF: Are we saying "Avoid level mixing?"
SW: Or "Respect abstractions"
[Chris]
so its not Information Hiding, its Respects levels of Abstraction
[Ian]
IJ: Can 4.3 (Info hiding) be moved to finding? Seems closely related since you would design components that (1) have the simplest interfaces possible and (2) don't use layer-peeking. Both reasons make the components more likely to be reusable.
DO: Is a SOAP header a different level than a SOAP body? There is flattening going on at the infoset.
CL: But different levels in terms of the tag meanings.
[Chris]
levels are not necessarily stacked above on another
[Ian]
NW: Levels of abstraction can occur within the same architectural layer.
[Chris]
eg html head and body - they are separate but one is not layered above the other
[Ian]
IJ: Information hiding is a theme throughout this document: URI opacity, XML language independence, specification independence.
RF: Orthogonal protocols deserve orthogonal specs.
TB: I think this is neither Web-specific.
RF: This should be in the introduction. It's the basis for the Web architecture. See my previous email.
CL: Avoid gratuitous dependencies.
TB: Yes, I would be inclined to put in the introduction.
[RF to suggest text in place of 4.3]
[Chris]
clearly call out interfaces or dependencies
[Ian]
RF: Add a section 1.2 on general principles It genuinely cuts across all three legs of the tripod.
TB: We need examples (including counter-examples from 4.3)
Action NW: Write up text on information hiding/abstraction respect for before 2/3/4.
PC: I think we are biting off too much by trying to do that. I think we could go to last call without this change.
TB: We can leave this as 4.3 for now if we prefer.
IJ: I think a forward reference from URI opacity to this section might be useful.
4.1. Interoperability and the Use of Standard Format Specifications
CL: "For example, if a format is required to contain human-readable text with embedded hyperlinks, it is almost certainly better to use HTML for this purpose than to invent a new format." It think this overstates the case. E.g., timed text. I agree with the principle to not create a new format gratuitously, but the previous sentence is too strong.
RF: I agree.
Resolved: Delete last sentence of para before 4.2.
PC: Please be sure when "HTML" v. "XHTML" that there is rhyme or reason to the choice.
[Chris]
4.4 - Ian suggested to shrink this?
[Ian]
IJ: There's no principle here. What's specific to the Web? I hear "view source" mentioned.
DO: There are other choices than binary v. textual when designing a format. Why do we emphasize this constraint?
Proposed: Good practice note. Make a considered choice between binary and text formats when designing a data format.
Resolved: Add a good practice note to this section.

Action IJ: Draft good practice note for 4.4.

2.3.1 Review of extensibility finding and section 4.3 of Arch Doc

Review of 3 Oct 2003 Draft of extensibility finding by DO and NW.

[Ian]
DO: Some of section 4.3 was incorporated into the finding
NW: I think that DO and I would like to replace 4.5 with some text from the finding; the text in 4.5 is compatible with the latest draft of the finding. Not sure if the same goes for 4.6.
Action DO/NW: Propose replacement text for 4.5.
[DO reviews TOC]
TB: I disagree with the definition of "extensible". Extensibility also allows the addition of new tags, in my opinion.
DO: What is a definition of "vocabulary" then?
TB: There is a "markup vocabulary". This is formally defined in the namespaces spec intro.
DO: XHTML has three different vocabularies, all drawn from a single namespace.
PC, TB: I think that's not a good example.
TB: A vocabulary is a set of terminals in a language. An xml markup vocabulary is generally considered to be a set of element names and attributes.
DO: But I don't know how to talk about the case of XHTML.
TB: At the very least, you have to explain the relation between do:vocabulary and xmlns:vocabulary.
NW: DO and I wrestled with this so it wouldn't be awkward for the case of XHTML.
TB: That's fine, but please connect to existing terms of art.
[Roy]
Extensibility is defined as the ability to add functionality to a system [108].
108. D. Pountain and C. Szyperski. Extensible software systems. Byte, May 1994, pp. 57-62.
[Ian]
TB: It would be useful to make the point that growth can be external (import) or internal (adding to this vocabulary).
RF: Extensibility also involves syntax around terms: if the grammar can't handle new terms, it's not extensibility.
[tim-away]
?really
[Ian]
TB: I thought we said we would break out xml schema stuff to a separate note.
DO: My understanding was to separate it, but not necessarily in another document.
PC: Section 5.1 tells me to do something that W3C has told me not to do - put something into a namespace owned by somebody else.
"No permission should be needed from the authors of the specification to make such an extension."
NW: Clarification - that is an extension into a different namespace.
DO: See 7.2: "Only the owner of a namespace can change (ie. version) the meaning of elements and attributes in that namespace."
[Roy]
I meant to say that part of being an extensible language is having a grammar that is able to accept new terms.
[Ian]
TB: I still think 9 belongs in another document.
[Discussion of schema authorship]
TB: The RSS folks don't have any schemas, but are designing for extensibility. They'll design a schema later. I think having a technical note on schema design might be useful.
NW: I hear TB saying "separate schema from general stuff." I hear PC saying separate the problem of extensibility from a particular solution.
DO: Almost all the good practice notes are in 4-8.;
[Chris]
DO: can either add new terms to a ns name or not. We said, pick one - ns owners *can* define more terms
PC: yes, unless the semantics changes in an incompatible manner. new elm and attrs are ok
DO: need to talk about which changes can be made to a language. We state how to identify a language, how to control its changes. Can't talk about changes before introducing the terms that are needed, such a s authority over change control
NW: last several paras of 1.1 deal with distinction between open and closed systems, development phase vs deployment/mature phase, and so on to address comments made on last version.
[Chris]
PC: 'probably change ns names for each WD' - probably? may? should?
DO: not clear if this finding is one doc, two docs with split between 8 and 9, or three with another split between 3 and 4. We say that you can reuse namespaces. Compatible extensions. key rule is the good practice in section 7. Good practice in section 4 allows extensibility either in one namespace or many. no real solution, more a set of design choices. Versioning doesn't work if you can't reuse the namespace names
TB: miss discussion of a version attribute. older drafts said 'don't do this'
NW: tried to find a middle ground between 'totally frozen' and 'big bang, any change gives a new namespace'
RF: suggest compressing sections 2 3 and 4 into one section with three subsections
IJ: similarly 1.2 to 1.5 could be condensed
NW: So material is ok, but looks odd as top level section?
RF: yes
DO: version attributes should only used to disambiguate compatible versions of one namespace name
TB: yes, if its a new ns name its a totally new thing; don't give it another version in the same series. So, I whined about material hidden away in section 5, and version numbers need to be more clearly discussed. In the TOC for example
RF: ok, terminology: in the intro, second para needs a lot of work on clarity. Forwards or forward? use one term consistently; use backward-compat not backward*s*-compat.
[DO]
Tim, this text had been in an Oct02 version: <p>Given that a namespace name is not for a single version of a language or set of names, it may be useful to identify the particular version. An example would be specifying in a policy statement the exact language supported by a software agent. This use of version identification could be considered each compatible "minor" version, with the namespace name identifying the incompatible versions. </p>
<p role="practice">Identify specific version with version attribute: The specific version of a set of names within a given namespace may be identified with a version attribute to differentiate between the compatible versions</p>
<p>This finding does discourage the use of version attributes. Namespace names provide a solution for identification in the large majority of the identification problems. Version attributes should only be used in a small minority of the cases. There is considerable danger that using version attributes to differentiate between compatible versions in a namespace will morph into differentiating between incompatible versions of a namespace and thus replacing
[Chris]
RF: definition is odd because it needs to focus on system changes not language changes (scribe is not sure that is correct)
DO: two different things, evolving the software and evolving the language
RF: can't actually make a fw compat change to a system. it can be designed to be fw compat without change. Can't take something that was not fw compat and makes it a new, fw compat language. If a fw compat language is changed and is still fw compat, you made a backward compat change
[Ian]
SW: Why talking about UA compatibility?
DO: There are rules like "MUST ignore" that are for agents.
SW: That's just language semantics.
TB: I think you need a lot of examples.
RF: Decreasing the number of elements does not increase forwards-compatibility.
[Chris]
TB: how much of this needs to be pulled into the arch doc?
DO: 1.2, 1.3, 2 (perhaps), 5 (except 5.1), 6, 7 (except 7.1) .... are the main parts
  1. provide for extensibility
  2. reuse ns names
  3. provide a processing model for extensions
  4. a common processing model is must ignore
  5. containers (in soap) give runtime overrides to must ignore
SW: Action NW and DO to make the summary to replace 4.5 (Extensibility Versioning) in the arch doc
[Roy]
A language that is designed for forward-compatibility defines a window within which future backward-compatible changes can be made. It follows, therefore, that failing to design for forward-compatibility will leave the size of that window up to chance and possibly preclude backward-compatible changes.
[Ian]
CL: I think a lot of this is covered by PNG as well.
[Chris]
CL: this is production stuff, its well deployed. (answer to TB: "Is this science experiments?"
IJ: CSS also deals with fw compat
DO: section 8 is less well understood, and 9 is very schema specific
TB: more examples would make it easier to follow and more examples
[Roy]
It isn't possible to make a language change that is forward-compatible, because changing the language creates a new language. It is desirable for a language to be designed with features that anticipate future change so that systems using that language now become forward-compatible with the future languages when they change.
[NW]
Roy, I think I see where you're going, but I'm still not sure I get it
[Roy]
s/when they change/when they are deployed/
[Chris]
timbl appears in voice chat in time for lunch break
[Ian]
PC: Two findings - one that is proposing a solution, and another one that is about extensibility and versioning in general.
[Chris]
PC: remove section 9 motivation and put in a separate, section 9 document (like TB suggested)
NW: I will take the action to do this - split into 2 between 8 and 9 and remove 9-specific material from the non09 document
[Roy]
A change is backward-compatible if the resulting language remains usable by implementations of prior versions of the language.
[Chris]
DO: the idea that extensions should be in a different ns contradicts ns versioning and reuse
[Roy]
Above, I am trying to restate the definitions such that they fit the meaning of forward and backward-compatible that are commonly accepted in industry.
[Chris]
TB: missing piece - application level requirements on versioning are highly heterogenous and carry a lot of application-specific semantic baggage

2.3.2 Continue walk-through at section 4.6 of Arch Doc

[Ian]

4.6. Composition of Data Formats
TB: I propose removing this section. Not enough experience.
RF: What if we just had a table of considerations when designing new data formats?
IJ: This is not covered in extensibility finding?
NW: No. Related, but not the same.
[There is not consensus around:http://www.w3.org/DesignIssues/XML]
IJ: Let's move this to future work.
Resolved: Move 4.6 to future directions section for representations.
4.7. Presentation, Content, and Interaction
DO: I think 4.7.1 is more closely related to extensibility...
CL: I don't like the split between final form and reusable.
DO: I think that if we talk about categorizations (as we do in finding on extensibility), then we might include this material there as well.
CL: I think this section needs to exist in the architecture document.
[Chris]
See latest version of draft content/presentation finding.
[Ian]
IJ: I like the rationale of saying that you don't know the characteristics of the user agent on the other end; experience shows that flexibility is gained by separating UI concerns where possible. I think it's also useful to talk about the tension between device-independence/device-specifics. Whether you make available device-specific version AND make other info also available, or do the split client-side is a good question.
Proposal:
  1. Replace text in 4.7 with short text and one principle.
  2. Publish latest version of draft content/presentation finding, even though incomplete.
TB: In arch doc 4.8, s/genericity/generic: "Do not constrain URI schemes"
4.8. Hyperlinks
RF: s/One of the greatest strengths of HTML as a format/One of the most interesting features of the Web/. I am confused by "But" in second para (beginning of second sentence)

Tim Berners-Lee joins meeting by video link from the US.

[back to 4.8]
RF: I think 4.8 adds no value as written. What 4.8 should say is: "Data formats (languages) should incorporate hypertext if they have that as a user interface paradigm. Otherwise they become terminal nodes on the Web." There's no rationale here (as written). I think the third point in 4.8 relates to the orthogonality principle we discussed earlier.
TBL: I think it makes more sense to talk about the information space, then talk about the hypertext layer built on top of it. So the first two notes are more about hypertext, and the third is more generic to infospace.

TB: This is the section of the document on representations....so more specific than just about the infospace. I agree that there could be more motivation.

RF: I'd like it to say that, if you have a hypertext document format (i.e., you're designing a format that includes hypertext features), then you must use URIs to do so. Don't just say "Use hypertext" (first note). Say instead "Use URIs when you do hypertext (on the Web)."
TB: I'd be willing to redraft this section..
[tim-away]
We need separate distinctions for information space and systems built on it - global hypertext, semantic Web are two different examples
[Ian]
IJ to TBL: Yesterday we talked about adding a new section on the information space (shared by several systems). I kind of hear TBL saying that "When you want to use the (Web) information system, the way to do so is to use URIs to constitute relationships (i.e., links).
IJ: What in section 4.8 as written is actually specific to the Web, as opposed to Web services or the Semantic Web?
[tim-away]
Change the heading form "hypertext links" to using URIs in document formats
[tim-present]
http://owl.bbn.com/validator/
For RDF-based applications, OWL is designed as a namespace document format.
[Ian]
IJ: What in section 4.8 as written is actually specific to the Web, as opposed to Web services or the Semantic Web? So I would split (1) Using the information space implies using URIs (2) Formats should allow embedding of hyperlinks.
[tim-present]
For RDF-based applications, OWL is designed as a namespace document format.
[Ian]
TB: Yes, and (3) don't constrain schemes, and (4) allow Web-wide linking.
TBL: Is there anything that people want to say about hypertext that's about the information space in general? If a WSDL file refers to a message type with a URI, I wouldn't call that a hypertext link in the same way as an href in HTML. So there, e.g., I wouldn't say "Use xlink".
RF: Call 4.8 "Web-enabled data formats" instead of "4.8 Hyperlinks"
SW: "Format specification designers SHOULD provide mechanisms that allow Web-wide linking, not just internal document linking." The WSDL folks are using QNames for internal linking.
PC: If you're using a schema language and it provides a URI type for linking, use it.
TBL: We also need to say that when you use a URI, it is a global identifiers. Don't use it for different types. You get benefits of the global information space, but there also constraints that come with it.
PC: What did schema get wrong?
TBL: You can use a URI to name an attribute, but you can use the same URI in another context to name an element.
TB: This is an example of URI ambiguity (which we discuss elsewhere)
PC: We don't use URIs in query.
TBL: The decision to be able to use URIs to mean different things in different contexts is a mistake. Scope of URIs is global.
TB: I agree with what TBL is saying, but I think that it's not about 4.8. Should we say here "Use URIs alone (and not qnames)"?
DO: When I've talked to the WSDL WG about this, there are a number of people who have heartburn about using Qnames instead of URIs. But our finding doesn't go far in saying "Don't use QNames"
TB: That's because we don't have a universal way to map from QNames to URIs.
TB: "Don't use QNames to identify things unless you provide a mapping to URIs". This is a corollary to "Use URIs".
[Support for this from the TAG]
PC: Should we extend our finding on QNames to say this?
NW: So we want to say in section 2.
  1. Use URIs
  2. If you use Qnames, provide a mapping to URIs.
RF: Also "Don't define an attribute that can take either a URI or a QName since they are not syntactically distinguishable."
Action NW: Revise QName finding to say this. We will also add those two good practice notes to section 2:
  1. If you use Qnames, provide a mapping to URIs.
  2. Don't define an attribute that can take either a URI or a Qname since they are not syntactically distinguishable.
4.9. XML-Based Data Formats
TB: I don't agree with "The most significant technical drawback to using namespaces is that they do not interact well with DTDs." There are also people complaining about additional complexity when you mix namespaces.
TBL: Rephrase to be more historical: One piece of motivation to move from schemas to DTDs was that they did not play well with namespaces.
Action NW: Rewrite the last paragraph of 4.9.2 to be less inflammatory.
4.9.2. XML Namespaces
CL: I would like to be sure that the intent of the text covers the case, e.g., of format attributes, which would help deal with inheritance.
TB: Yes.
4.9.3. Hyperlinks in XML
Resolved: Delete good practice note in favor of NW's upcoming text on Qnames.
TBL: I'm uncomfortable with "inspiration" in second para.
NW: We said "Use xlink" and that was not well received.
[tim-present]
If checked the OWL validator will automatically load all referenced namespaces in the above file.
[Ian]
NW: s/should examine.../should consider using XLink and XPointer/

2.3.3 Namespace documents and section 4.9.4 of Arch Doc

[Ian]

4.9.4. Namespace Documents
We are awaiting a draft finding from PC and a proposed piece of text for this section.
DO: I propose that most of section 4.9.4 be deleted; it's not widely deployed.
PC: See the W3C site.
TBL: Yes, this is deployed.
TB: MS Office 2003 uses namespaces and namespace documents.
PC: There are many people that have followed the TAG's early agreement on the principle that the namespace document be human-readable. Whether namespace documents meet other needs as well (machine-process-able) is another question. The TAG is trying to promote this practice by doing the arch doc, a finding, and a Note on RDDL.
TB: I would add that namespace names are very widely deployed. The curiosity in the community about "what do these things point at" is manifest. The attempt of the inventors to say "they don't point at anything" has failed miserably. I'm happy with the text in 4.9.4.
TBL: I'm pretty happy with current 4.9.4. However, s/of other Web resources/of Web resources/. Don't define an architecture where that information is secondary. Remember, the information appropriate for an application will determine what is suited to the namespace document. Change para beginning to: "There are many reasons why a processor might want more information about the namespace. Useful information to processors includes:" Furthermore, factor into:
  1. Many reasons
    1. People
    2. Agents
TBL: s/machines/agents in Good practice note. You can also make the point that information may be in the namespace document or referred to indirectly.
RF: d/to use for// in that section. Put the first two paragraphs inside the story, not just the first.
PC: Can people live with this document going to last call without a finding?
NW, SW, RF, CL, TB: Ok to go to last call.
TBL: To end of 4.9.4, indicate that for RDF, OWL is appropriate for a namespace document format. OWL represents a huge body of work.
IJ: Any reason not to push 4.10.1 back up to 4.9.4 if we talk about OWL in 4.9.4?
NW: What if people say "For WSDL, WSDL is a good format" at last call?
TBL: We've put pointers to other specs to show where they fit into the architecture. This is where OWL fits into the architecture.
IJ: I'm for having several examples of namespace document formats in 4.9.4. I am uncomfortable having some examples in 4.9.4 and others in 4.10.1. The title "4.10.1 Namespace Document Formats" needs to be changed to "RDDL" if we are not going to move RDDL to 4.9.4.
PC: We seem to have a requirements mismatch between the RDF community and other communities. Having multiple kinds of namespace documents is something we will regret.
IJ Proposal: Include three example formats in 4.9.4: OWL (for RDF apps), RDDL, WSDL (for Web services apps).
TB: We don't have consensus about best formats. The best we can say is to provide some examples.
NW: I'm not moved by TBL's discussion of "that's the way the sem Web works today."
PC: I like IJ's proposal to move both OWL and RDDL reference 4.9.4. If people are unhappy with the way the OWL stuff is being done, people can file objections. I think that ten years from now that we will have regrets if we have more than one namespace document format.
TBL: I think that fixing one format for all time is naive and short-sighted. Just as we introduced a single language for hypertext, we are introducing a new language (OWL) for a global reasoning space. If we say that folks should always use RDDL, then we would need to fix the metalanguage. The flexibility that allowed us to use the info space for global hypertext and global reasoning was valuable. When we introduce a new metalanguage, it's likely that the new metalanguage will be more sophisticated. To constrain people to use namespace docs that they must always be primarily human-readable is overly constraining for what new technologies could do.
IJ: Proposal: In 4.9.4, include three examples of namespace doc formats: OWL for sem Web docs, rddl, and wsdl for Web services.
TBL: Please talk about RDF documents for OWL.
IJ: "WSDL for Web Services"?
TBL: Hmm...
[tim-present]
OWL or namespaces which are RDF
[Ian]
CL: There is a boot-strapping problem if your namespace doc format is unknown ...
[Roy]
I don't see why this is different from any other situation where content negotiation is appropriate.
[Ian]
RF: I see absolutely no reason to constrain applications.
[TB]
Content negotiation is 100% inappropriate; it is commonplace for an XML vocabulary to have a run-time schema, an authoring schema, and a debugging schema, all in the same media type. Similarly it is reasonable to have 5 different CSS style sheets for different device classes
[skw]
+1 on what Roy said
[Roy]
The choice on Accept is made by the consuming application, not the data format.
[NW]
Are you saying that the OWL CR spec actually says explicitly that an OWL document should be at the end of a namespace name?
[Ian]
TBL: The reason I wanted OWL in a separate box is that it's much cleaner.
[TB]
That's why RDDL has a two-part selector, "nature" (== media type) and "purpose" (== application need)
[Ian]
TBL: The RDF folks have a consistent story and a working system. We should point to that since it exists.
[Roy]
There is no situation in which an application would be confused regarding whether it prefers to see human-readable vs owl vs wsdl -- if there are more than one profiles for a namespace, then I assume each namespace description document (regardless of format) would refer to those profiles. Coneg is only needed to choose the initial format.
[Ian]
DO: My problem is that we are not telling the WSDL folks what to do for namespace documents.
TB: That's right, we don't know yet.
TBL: Right. Don't let the fact that the WSDL folks have not yet solved the problem for their application stop the OWL folks from talking about their solution for RDF.
PC: I don't think that, in order to get to last call, we should have anyone in the room trying to drive their position into the document. I think that the document should reflect what the Web is doing today. I think that the paragraph on future work should point out the division we are feeling.
TBL: I am troubled if we talk about RDDL (which is not even a note or rec track) and to ignore OWL (a CR).
[paulc]
Proposed text: "In general, there is no "best" data format for encoding a namespace document. For example, the following are examples of formats used to encode namespace documents:
  1. OWL ontologies,
  2. XML Schemas,
  3. HTML Documents,
  4. RDDL Documents.
Each of these formats meets different requirements described above for satisfying the needs of a person or agent that wants more information about the namespace.
[TB]
I don't suppose we can put [this sucks] after item (2)...
[Ian]
IJ: I support the idea of saying "This is what people do today." I think the *finding* should talk more about the issues driving us nuts.
[TB]
I'm OK with this
[Ian]
TBL: I'll be happy with a statement of what is currently happening.
Resolved: Accept text from PC with minor editorial tweaks ("currently used") and addition of references.
SW: What do we do about 4.10.1?
IJ: PC might use some of that text for the finding on namespace docs.

Resolved: Delete section 4.10.1.

2.3.4 Continue walk-through at section 4.9.5

[Ian]
4.9.5. Fragment Identifiers and ID Semantics
s/defines/identifies in first sentence.
[TB]
"If all that is known about a representation of the resource http://example.com/oaxaca is that it is encoded in XML, what is the correct interpretation of http://example.com/oaxaca.com#x23 ?"
[tim-present]
Again, for RDF there is a specific answer
[Ian]
RF: I don't like the first two paras of 4.9.5, but don't have any replacement text yet.
[IJ to fix up first two paragraphs]
DO: "The same is true if the assigned media type has the suffix +xml (defined in "XML Media Types" [RFC3023]) as there is no normative specification of fragment semantics in this case."
TB: When you define wsdl+xml, then you'd better define the semantics of frag identifiers since you don't get anything for free.If the application is image/svg+xml then the frag id semantics are clear since the SVG spec states what the semantics are.
[Zakim]
tim-away, you wanted to ask whether there is anything new to say about hypertext per se
[Ian]
DO: We should tell people what is known in each of these cases: application/xml, new media type without frag id semantics defined, and with those semantics defined.
CL: If you define */*+xml, you are leaving an open hook if a spec comes along later that defines semantics for such formats.
[NW]
RFC 3023 could be modified so that it defined the fragid for */*+xml.
[Ian]
TBL: Fragment id semantics for W3C specs should appear in W3C specs.
RF: Frag id semantics is one of the questions on the new form for registering a mime type.
[tim-present]
Specs of new mime types MUST define fragment ID semantics.
[Ian]
PC: May need a forward reference (or cross refs) between 2.4.1 and 4.9.5.
TB: I think 4.9.5 is ok modulo editorial clarification. There is confusion out there about magic behavior about ids. Having said that, I'd be ok with nuking 4.9.5 since I don't think this problem actually arises in practice.
SW: They're not using xpointers?
TB: If they are, they're doing the right thing. People aren't using IDs with RSS.
CL: I'd like to look at what xsmiles and deng rae doing. And ice browser.
TB: The message is that you don't get frag id semantics for free by using XML. Similarly, I don't think that solving the xml id problem is worth it; people aren't doing this.
NW: However, I *want* to be able to do this.
TB: The more I think about this, the less I understand why people want to serve something as "just xml". It tells you so little.
NW: There's no media type for docbook.
TB: The right answer is not to serve it as xml and expect the right thing to happen; the right answer is to register a media type.
[Zakim]
tim-present, you wanted to say that that sentence is junk and to say that there is a requirement for anyone defining a mime type to define the syntax AND semantics of fragids and to say they are using fragids with RDF,and with well-defined meaning.
[Ian]
TBL: This is interesting since the point of XML was to have enough info to be able to get XML and "take it from there." But I'm hearing that it's not sufficient to know that it's XML; you need more information.
TB: I never believed the direction of the HTML WG; to be able to get generic XML and run with it. I'm fine with leaving text in as is, or nuking it.
TBL: This is broken: "The same is true if the assigned media type has the suffix +xml (defined in "XML Media Types" [RFC3023]) as there is no normative specification of fragment semantics in this case." Rather:
TB: The real point is that just knowing it's xml doesn't give you frag id semantics

2.3.5 Media Types for XML and RFC 3023

[Ian]
4.9.6. Media Types for XML
[TB recaps TAG discussion from yesterday about 3023]
Completed action TB: Ask DC and TBL for their opinions on moving forward w.r.t. 3023. [Done yesterday]
TB summary: Problems related to text/* for XML. And, if you do use application/*, you should probably not use the charset.
See alsocomments from DC: "case against text/* overstated", and ff.
TB proposal:
  1. We should ask editors of 3023 to fix 3023 w.r.t the charset.
  2. The question of "id" semantics is separate and requires more discussion
TB: I'd like the TAG to, orthogonally, encourage the editors of 3023 to submit and updated Internet draft and request comments.
TBL: Reminder - I think there's a standards process screw-up if there's have a standard in one document and half in another. In particular, it's important that the entire document go through the same review process. The principle is that a W3C spec should have all the media type registration information in it.
NW: I observe that XML 1.1 is well on its way through the W3C process. To ask us to add stuff at this phase will likely cause discomfort for the Core WG.
TB: But that is orthogonal to the question of whether we should fix 3023.
NW: If we the TAG want to ask the Core WG to do this, that's fine. But please realize that this is likely to ruffle some feathers.
TBL: But this was discussed a long time ago.
NW: Frag id semantics were not in 1.1 requirements, or in first WG, or in last call draft. We should have noticed earlier.
[NW: I am not speaking for the Core WG here.]
RF: It would certainly be appropriate to start with an apology here.
[NW]
Nor is it in the CR draft, nor was it a comment at any time earlier. XML 1.1 has been at CR since last February.
[Ian]
TB: I propose that:
TB: That leaves the question of frag id semantics on the table. I do not propose that we put the resolution of the problem of "id-ness" on the critical path for fixing 3023 and getting xml 1.1 done. The question of how an attribute in an xml element has "id-ness" is a hard problem, and the Core WG has been laboring mightily but has not yet solved it.
[Roy]
I suggest that XML 1.1 only needs to include the normative bits of 3023 and registration forms for application/xml and text/xml
[Ian]
TB: I'd like, thus, a very narrow change in scope for xml 1.1 based on wide consensus in the community. Let's fix it.
TBL: This was discussed in the XML CG (some time ago).
TB: The proposed changes for 3023 are (1) text/xml not be recommended and (2) charset param ok for application/xml and application/*+xml but there are dangers.
SW: So, the long-term solution is to have id-ness in the XML Core spec as well.
TBL Proposal: Let's put 3023 as corrected as a normative appendix in xml 1.1.
TB: That also would be easier path for XML Core WG.
TBL: However, in this case, do NOT revise it on the RFC track as well.
TB: If the IETF can make 3023 go away, then I'm fine to not get revision on the RFC track as well.
RF: They can just mark it as historical.
The TAG recognizes the outstanding work done by Simon St. Laurent, MURATA Makoto, and Dan Kohn on RFC 3023!
Actions:
  1. NW to liaise with Paul Grosso and the XML Core WG
  2. TBL to liaise with the IETF regarding obsoleting RFC 3023.
  3. TB to talk to authors of 3023 about inclusion as appendix in xml 1.1.
  4. TBL will talk to the Architecture Domain Lead.
Action IJ: Update OWL spec reference.

2.3.6 End Notes

[Ian]
8. End Notes
SW: The sentiment has been expressed that we don't want end notes. If it's important enough to say, say it in the document.

2.3.7 Return to section 2.3

[Ian]
2.3. URI Schemes
TB: Delete the examples.
IJ, CL: Show people that there are other schemes than http
TB: Get rid of mailto: example. There is much room for reasonable people to disagree about what mailto URIs identify.
RF: Using mailto as a canonical example is a bad idea.
[tim-hp-cam]
s/mailto URIs identify4 Internet mailboxes:/mailto URIs in simple form identify4 Internet mailboxes:/
[Ian]
RFC 2368: "The mailto URL scheme"
[There is support for a non http example]
[skw]
http://www.iana.org/assignments/uri-schemes
[Ian]
RFC 1738: "The news URL scheme is used to refer to either news groups or
individual articles of USENET news, as specified in RFC 1036."
RF: RFC 1738 is in a state of pseudo-deprecation.
[Chris]
RFC 2056: Uniform Resource Locators for Z39.50
[Ian]
[Discussion of what URI scheme to use for example]
[Chris]
The Z39.50 Session URL may be informally described as providing the mechanism to switch the user to a Z39.50 client application.
[skw]
We are discussing this text from the arch doc: "On the other hand, the "mailto" URI scheme specification states that mail URIs identify Internet mailboxes. That normative specification authorizes Web agents to infer that the identified resource is an Internet mailbox, although it doesn't guarantee that the authority who minted the URI is actually using the URI to identify a mailbox."
[Ian]
TBL: d/, although it doesn't guarantee that the authority who minted the URI is actually using the URI to identify a mailbox.
[tim-hp-cam]
"although it doesn't guarantee that the authority who minted the URI is actually using the URI to identify a mailbox." is junk
[Ian]
TBL: Even if specs are a bit confusing, it's our job to sift out the underlying design.
[tim-hp-cam]
"On the other hand, the "mailto:xxx@yyy" URIs identify Internet mailboxes. This authorizes Web agents to infer that the identified resource is an Internet mailbox"
[Ian]
SW: I would rather say "designate" than "identify" here. I realize that may not be the TAG's consensus position, but it would be my preference to say it the way they do. I can accept TBL's language with some discomfort. I would object to a direct quote if misquoted. What grates me is that the RFCs talk about "URIs designating". Is "designate" the same as "identify"? The second point is that it's not a closed definition - other specs are ambiguous as to whether a URI of scheme S cannot identify other types of resources.
TBL: This is our chance to fix the ambiguity. We are capturing how the Web works. When someone uses a mailto URI, they mean the mailbox. Some URI schemes are designed to identify resources of a particular type.
RF: That's incorrect.
TBL: Attempts to remove this does damage to the Web architecture.
RF: I haven't seen that it's necessary that a thing using a URI understand via the scheme name what the identify of the target is.
TBL: The sequence of states that are followed, however, is consistent with our expectation that it be used to identify an Internet mail box. This is a fundamental concept in the email architecture. There are some properties of what you expect to do with this thing that follow directly from the fact that it starts with "mailto:".
RF: It's not the URI scheme that implies the action, it's the content. E.g., assertions.
TBL: But you are still making assertions about the mailbox in that case. You are making a mistake if you use a mailto URI to identify a car. Because they have global scope, doing so is harmful. I don't want to lose the ability to make such inferences. We could replace the paragraph in question with an mid: URI for example.
[tim-hp-cam]
news:xxx@yewruiwueyrui
[Ian]
(Identifies a news message)
TBL: I think the principle is important - there are certain schemes that you use to identify things of certain classes.
RF: Certain, yes. The data scheme does so. news: is tough since there are three variations or so.
TBL: It's not as though there's confusion about the architecture here; just that some specs as written could be improved.
[tim-hp-cam]
I think mailto is a good idea because people actually come across it, and it handled specifically with an understanding of what it identifies.
[Ian]
RF: Z39.50 is not widely deployed.
TB: You can't give it to a Web browser....
[skw]
3.6. NEWS "The news URL scheme is used to refer to either news groups or individual articles of USENET news, as specified in RFC 1036."
[Ian]
RF: The mailto: scheme definition differs from what the goal of the paragraph in question is. Until we update the mailto: scheme definition, it's difficult to make the inference that's made here.
[tim-hp-cam]
I disagree. I think that though the wording may be old, the point is still valid
Ian]
IJ: See section 3 of RFC2368: "A mailto URL designates an "Internet resource", which is the mailbox specified in the address."
TBL: First keep to the simple URI (without "?" in it).
RF: The mailto:foo@example.com indicates that the URI refers to a mailbox.
[tim-hp-cam]
"On the other hand, the "mailto:xxx@yyy" URIs identify Internet mailboxes. This authorizes Web agents to infer that the identified resource is an Internet mailbox"
[Ian]
TB: Let's just make this an example: mailto:joe@example.com identifies an Internet mailbox.
RF: It identifies an Internet mailbox because the mailto URI scheme specification (2368) says that mailto: URIs of this format designate an Internet mailbox.
[tim-hp-cam]
The mailto: scheme specification RFC3268 says that mailto:URIs of this format designate an Internet mailbox
[Ian]
Resolved: Change the paragraph in question to use RF's text with a concrete example.
TB: Say "of this form"
RF: Yes. I propose we (1) delete the pre-Web distinction and (2) lose the descriptions of types of objects identified.
TB on 2.3: "Furthermore, designers should expect that it will prove useful to be able to share a URI across applications, even if that utility is not initially evident."
TB: I think that this is an important point. It deserves it's own paragraph. And should be moved higher in the document. I wrestle with my developers frequently on this one. Just do it!
RF: I suggest adding that sentence to the last bulleted list (e.g., first bullet).
DO: I'd like to see more rationale here.
IJ: You can point to URI addressability (finding) here.
Action TB: Propose a revised paragraph to replace "Furthermore" sentence.
Proposed: Merge two bulleted lists in front of 2.3, remove the pre-Web/post-Web distinction, remove the descriptions identifying the types of resources.
TBL: I'd like to register my discomfort at removing this information. After last call, we'd do well to start cleaning up our ontology of URI string relationship to thing, what scheme you use in which contexts. I think we'll come up with useful things like "dereferenceable URIs". I've always wanted this table...what can you deduce from a URI scheme.

Proposed: Create a section on "future work" for identifiers - to summarize URI types and what you can infer for each scheme.

Action IJ: Add such a section.

2.4 Walk-through 8 Oct

[Ian]
2.4. Fragment Identifiers
[TB]
Move the para beginning "The secondary resource" down one para, after the one beginning "Fragment identifier semantics.." Then rewrite it to say "Existing URI schemes specify a variety of roles for fragment identifiers, including some portion of..."
[Ian]
For editor's note:
  1. Meaning of frag id depends on media type
  2. Authors should not have inconsistent frag id semantics across representations served with content negotiation
[TB]
potential problem: someone gets an SVG, pulls out their own fragid by looking at it, sends it to friend, friend gets a png and it doesn't work
[Ian]
CL: The story starts when you have a PNG and an SVG. You type in the URI, and you get back the SVG. You don't necessarily know (yet) that there's a PNG representation. Given SVG, you construct a new URI and send to a friend, who only has a PNG viewer.
IJ: That's the user's problem; they don't get to mint URIs indiscriminately...
[Roy]
I think the whole concept is a bit goofy -- it is okay to get 404 in response to some requests, so it should be reasonable to have secondary resources that are only meaningful for some representations.
[Chris]
SW: No, its not the users error. They had no way of knowing
CL: So in consequence, we are saying never coneg resources that have different fragid syntaxes
[Ian]
RF: If you take the position that the secondary resource is defined by the union of all representations of that resource, if a fragment is identified in any one representation, it's defined for all of them, even though a particular representation can't represent it.
[Roy]
Then the issue becomes that the fragment id, if named, must have consistent semantics for all representations in which it appears.
[Ian]
TB: I see two scenarios (1) you get frag id with SVG but not PNG; that's not great but not architecturally broken. (2) ....
NW: Servers don't see frag ids (with HTTP0
[Chris]
SW: this is only true of HTTP not of generic URIs
[Ian]
RF: It's true across URI schemes - the frag id is never sent across the wire.It's a matter of opinion whether it should be sent across or not.
[Chris]
SW: so a future protocol could indeed say that frags are sent to the server
[Ian]
TB: Continuing the PNG /SVG story,
[Chris]
TB: the story can show a variety of problems arise. Elaborate xpath will be less likely to work. However the risk is clearly higher and we can't just say 'this must work'
IJ: if you get a fragid with PNG its not great but not broken
TB: Need to explore the tradeoffs
SW: If it resolves across any one of the representations then it has meaning
Action CL: Write up this story (due 22 Oct)
PC: what is the conclusion?
TB: Its not neat and tidy. It breaks in various ways, which we describe
PC: so we restrict to single representations?
TB: No, thats way too limiting. We don't have a zero risk solution here
[Ian]
I think it's a positive feature to be able to use formats with different capacities; allows incremental improvement with the ability to retain backward compatibility with some loss of expressive power.
[Chris]
SW: If a fragid selects a portion of a representation, it should select a consistent portion across all representations
IJ: this feature lets you evolve formats gradually. So its legal to use fragids with SVG conegged with PNG, and the PNG guys get something useful but without the full power. This is like accessibility: don't penalize the people who have full capability but give something, not nothing, to the others
RF: this is one of the features of coneg, independent of fragids
IJ: So coneg still works. Its consistent with the desirable feature of coneg
RF: coneg is not format selection - you can have multiple choices in the same format
TB: two classes of error here. Server and provider does something stupid and serves 2 radically different reps of the 'same thing'. Secondly, where it a) does not have fragids or b) an xpath gets different stuff. This is undesirable but can't be avoided and is not broken.
SW: in the event that a fragid selects anything, it should be consistent across all representations
PC: its still misleading - should be consistent across all negotiated contents
[Ian]
Can we frame this in terms of "secondary resources"? Any advantage in doing so?
[Chris]
RF: my suggested text does
[Ian]
Action IJ:
- Add story that shows how two classes of errors can arise
- Frame in terms of secondary resources per RF text.
[Chris]
TB: so we will discuss the story, the two classes of error, and use secondary resources as the description
IJ: So who gets to mint URIs?
RF: You are authorized to do that. Only the primary is authoritative, from the server
IJ: Independent of IDness - on the one hand, its not ok for the author use one URI that identifies two different secondary resources. On the other hand, no promises of consistency across secondary representations
RF: No guarantee that a primary will be consistent, over time. Good practice note is over constraining authors of stuff on server. Sufficient to note that it might produce an error. Question is, how does the client deal with this error.
[Ian]
CL: It may be ok to described as benign if the client doesn't get back something for a given frag id.
[Chris]
CL: not selecting is ok, selecting radically different is not ok
RF: the client would never know
SW: is it a common misconception that Ids can be used by the user to select things?
RF: just like the common misconception that two hits on a URI get the same content
IJ: no guarantees but its not a misconception
RF: uri does not become cool until long after minting; depends on usefulness and degree of deployment. Better to mint many URIs and let some be of common use
SW: we need to focus on minimizing the number of changes in our text
IJ: would rather be as clear as possible
[Ian]
2.5. Using a URI to Access a Resource
[Chris]
RF: the resource identified by the URI - don't say identified. Say "referenced" here
[Ian]
(In "To dereference a URI means to access the resource identified by the URI")
TB: "A succession of agents carries out the retrieval by implementing the following relevant specifications:"
[Chris]
TB: 2.5.1 long list, sentence just before implies the software is reading the specs! Needs to be clearer that its the programmer, not the software, that consults the specs
RF: user agent applies mechanisms according to relevant specifications. Dereference is the first part of access.
SW: dereference is not synonymous with access. its going to the other end of the pointer
RF: its defined in 2396bis, section 1.2.2:
[Roy]
URI "resolution" is the process of determining an access mechanism and the appropriate parameters necessary to dereference a URI; such resolution may require several iterations. Use of that access mechanism to perform an action on the URI's resource is termed a "dereference" of the URI.
[Chris]
SW: I am comfortable with the current text
CL: so getting the DNS etc is part of resolution
[Roy]
dereference: To access the thing to which a pointer points, i.e. to follow the pointer.
[Chris]
TB: 2.5 is pretty well OK
PC: certainly for last call
[Ian]
2.6. URI Persistence and Ambiguity
[Chris]
IJ: User should be aware that there are no guarantees of persistence
TB: don't want to give providers an out here
IJ: users should go to server managers to complain 'take back the night'
RF: Server gives a greater quality of service by striving for persistence. Wording of good practices is odd
TB: 'service'? Parties who publish URIs should.....
[Ian]
RF: "Publishers of URIs should provide representations (or not) predictably and consistently."
[Chris]
CL: prefer a previously defined term, to this unique use of 'service'
[TB]
... should provide representations (or not) predictably and consistently
[Chris]
IJ: communicate meaning through representations
TB: Communicates state. State is orthogonal to this
IJ: yes but I am trying to tie it to later text
[NW]
Change "When the two data sets are merged" to "If the two data sets are merged carelessly"
[Ian]
(IJ notes to use joe@example.com wherever mailto: is used...)
On the Moby Dick paragraph.
NW: The example has no context before or after...
[Chris]
RF: delete clause with 'costly nonsense'
[Ian]
d/, resulting in potentially costly nonsense./
[Chris]
Action NW: Massage there three paras
[Ian]
"Save Moby" ;)
[Chris]
RF: explicit mention that we don't know which of these three things it identifies
[Ian]
TB: Since ambiguity is a problem, it's important to be clear when engaging in person-to-person narrative (and even more for machine-to-machine).
[Chris]
RF: interweave Moby with ambiguity so its an example of ambiguity
[Ian]
[IJ will delete editor's note]
[Chris]
RF: delete "HTTP [RFC2616] has been designed to help service URIs."
[Stuart]
Let's review TBL's text from this section
[Chris]
IJ: first para has been taken and added, second was not included
SW: seems to relate to assertion of metadata
IJ: avoid 'on the semantic web' until we have 'on the web' defined. I don't want to remove the http redirection para.
RF: mechanism to ensure consistency over time ...
IJ: so move the redirection para to the previous section on persistence
[Ian]
Action IJ: Move http redirection para to section on persistence, with appropriate edits for incorporation.
Action IJ: Split persistence and ambiguity into two separate subsections.
2.7. Access Control
RF: Make story clearer "Because they are both subscribers.....offer to all subscribers.....not to unauthorized parties."
TB: " For more information on identification and access control, please refer to the TAG finding "'Deep Linking' in the World Wide Web." No, fix to be about deep linking.
[Chris]
s/identification and access control/this
[Ian]
In 2.8.2, s/state ? or at least claim ?/assert
s/formally//

2.5 Review of action items related to architecture document

[Ian]

IJ: The TAG believes it will be done with actions items as summarized below before 22 Oct 2003.
TimBray
  1. Write up a paragraph for section 3 on syntax-based interoperability.
  2. Write a paragraph of rationale for why error handling good in the context of the Web.
  3. Completed action TB 2003/08/18: Bring some Vancouver ftf meeting photos to IJ attention (of whiteboard, re: CL action about illustration of two resources). Done, but IJ has not incorporated images in 18 Sep draft.
Stuart
  1. Completed action: Send to IJ draft diagrams
Ian
  1. Add ed note to abstract that the abstract will be rewritten.
  2. Starting from DO's diagram, create a diagram where the relationships and terms are linked back to the context where defined. Ensure that the relationships are in fact used in the narrative; any gaps identified? With DO, work on term relationship diagram.
  3. Draft good practice note for 4.4.
  4. In 2.4, add story that shows how two classes of error can arise (inconsistency v. no frag id semantics defined). Frame story in terms of secondary resources.
  5. Split persistency section into two and move http redirection para there, with appropriate rewrites.
  6. Updated OWL ref since in CR
David
  1. With NW, make the summary to replace 4.5 Extensibility and Versioning in the arch doc
Paul
None.
Chris
  1. Dropped action CL 2003/07/21: Create an illustration of two resources, one designated by URI without fragment, and one designated by same URI with fragment.
  2. With IJ, CL 2003/07/21: Discuss and propose improved wording of language regarding SVG spec in bulleted list in 2.5.1.
NW
  1. Write up text on information hiding/abstraction respect for before 2/3/4.
  2. Revise QName finding. We will also add those two good practice notes to section 2:
    1. If you use Qnames, provide a mapping to URIs.
    2. Don't define an attribute that can take either a URI or a Qname since they are not syntactically distinguishable."
  3. Rewrite the last paragraph of 4.9.2 to be less inflammatory about DTDs
  4. Massage three paragraphs following good practice note about persistency at beginning of 2.6.
Roy
  1. Explain "identifies" in RFC 2396.
TBL
  1. Action TBL 2003/07/14: Suggest changes to section about extensibility related to "when to tunnel".
DC
  1. Action DC 2003/07/21: Propose language for section 2.8.5 showing examples of freenet and other systems.

The following action items were marked completed or dropped at the meeting:

2.6 Last call expectations, schedule

  1. Most TAG participants expressed a preference for a new mailing list for last call comments.
  2. IJ will have new issues list for issue tracking.
[Ian]
PC: Announce or LC decision at the AC meeting in the TAG presentation.
IJ: From whom do we expect to get reviews? What our our "CR expectations"?
PC: I'd go straight to PR, after lots of comments during last call.

IJ: Where the doc reflects current practice, how much new implementation is required? Also, not sure what two implementations means...

Schedule:

3. Findings and Issues

  1. deepLinking-25
  2. whenToUseGet-7
  3. contentTypeOverride-24
  4. xmlIdSemantics-32
  5. contentPresentation-26
  6. metadataInURI-31
  7. abstractComponentRefs-37
  8. siteData-36
  9. charmodReview-17

See also TAG findings home page.

  1. Resolved to drop action IJ 2003/06/09: Turn TB apple story into a finding. This topic covered in the Arch Document.

3.1 deepLinking-25

Issue deepLinking-25

[Ian]

Resolved: Publish 11 Sep 2003 draft of Deep Linking in the WWW as accepted.

Action IJ: Republish as accepted and signal to person who raised the issue (Michael Kay).

3.2 whenToUseGet-7

[Ian]

DO: Not done. I can have this done next week.

3.3 contentTypeOverride-24

Action IJ: Produce a new draft of the finding that takes into account comments from reviewers on MIME finding.

3.4 xmlIdSemantics-32

[Ian]

CL: Some comments from Noah and Paul Grosso already.
PC: What's our expectation about what's going to happen in the Core WG?
CL: Our expectation is that we're happy that others are working on this; we want to see a solution and are glad this is happening. I added another possible solution to the finding (based on Core WG comments)
[NW summarized status of XML Core WG work in this area.]
CL: Finding is in pending state; awaiting solution from Core WG. I will undertake to revise the finding as necessary if Core wants other info added to it.

[IJ reminder to self: Update issues list with link to draft finding]

3.5 contentPresentation-26

Action CL: Talk with others about aspects of this finding and revise it.

3.6 metadataInURI-31

SW: Not done.

DO: I won't have this done for a month.

3.7 abstractComponentRefs-37

IJ departs meeting at this point. TBL joins meeting.

[DO]
The latest email from Jonathan Marsh. WSDL F2F minutes. Check out the 10 am time slot.
[tim-mit]
Stuart: they define a message component (in WSDL 1.1)
Propose: They outlaw the same URI for different things in different contexts
[TB]
the 0075 proposal is interesting
[DO]
TB: Problem with frag-id was that it required wsdl document at ns (couldn't use rdf...) in order for frag-id to work correctly
[tim-mit]
TB: The problem with using fragid is that the WSDL document becomes a namespace document with a special fragid syntax, and so needs a new MIME type, and some people might like to use something like RDDL.
[DO]
TB: Problem with using QueryString is that it's a land grab in the URI query portion.
[Stuart]
The WSDL WG's actual question to the TAG is: "Is it wise to use fragment IDs for identifying abstract components within a namespace, even though it is the most natural and convenient mechanism? Is there another mechanism that would be preferable?"
[tim-mit]
TB: The problem with using the query component t is that they are doing a land-grab -- they mess up anyone who wanted to use the query component for anything else. I think that the query component method is an architecture abuse.
DO: We will have to follow through with ____ if RDDL becomes a namespace document format
NW: The fragment identifier syntax will work with content negotiation.
[NW]
More specifically, if you imagine that the RDDL resolution is a "level down" in the retrieval process, you'd get back a document of the right content type for the fragid that you planned to use.
[DO]
The latest edition of the finding doesn't include JMarsh's latest proposal.
[CL_]
concat http://example.org/foo# and bar
[DO]
Are we resolved that ns name # frag-id for abstract components is not broken?
[CL_]
concat http://example.org/foo and #bar
same, no?
(yes)
however, xml:base does not apply to bare fragments, they relate to the current document
[tim-mit]
actually they are suggesting things like concatenate the namespace, a hash, some function of the type of the thing, some function of the local name of the thing.
[TB]
if they took care to have id="TicketAgent.listFlights.listFlightsRequest" etc in their WSDL docs then they would have bought a lot of media-type independence
[CL_]
So #bar means bar In the current document
[tim-mit]
Resolved: It perfectly reasonable to use a fragid to identify an abstract component
PaulC: Will they know whether it is actually resolvable.
TB: First, everyone agrees to use the hash syntax. Second, IF they go and fetch it AND t is there AND the mime type is understood, AND they have software which groks it, then things work. But if any of the AND s fail, it is still a good identifier.
PaulC: Users have to understand that.
[DO]
TimBray, that's option #2. Use IDs
[TB]
yep, but they should do it anyhow: belt and suspenders
[tim-mit]
PaulC: I find it hard to believe that a user reading documentation with a URI .... I am feeling really uncomfortable about this.
TB: I am less worried about that than you are. If they get 404, they get 404. too bad If something is there, served as WSDL, If they don't understand WSDL it will be saved to disk.
[TB]
PC: was looking at OWL Features. Displayed namespace doc as XML
TBL, TB: probably wrong mime type
[tim-mit]
W3C has just changed to use the new application/rdf+xml for the .rdf documents
[TB]
TB: No, that's not the owl namespace (I don't think)
PC: problem is that their namespace doc is going to have to be in their own media type so their own software can get at it. But we have agreed that namespace docs should be human-readable. Which won't happen if some are wsdl and others are other little languages. But it's OK if it's just an abstract label with no intent to dereference & look at
[CL_]
If the entirety of the functionality has to be at the namespace URI, then
  1. We should point to the /TR spec as the namespace name
  2. We should prohibit multi-file html documents
[TB]
PC: look at his Functions & Ops document, he doesn't want to have each of the 350 F's & O's in his namespace doc
[CL_]
that way, we can be sure to get all of the functionality as a fragment from a single uri
[TB]
DO: they want to pass around the name of a service or of a port within a service. They do this by qname. If they pass around URIs that would be better. But they should be real URIs that point to something useful. So maybe they're not abstract at all.
Q: how do they use qnames?
DO: A: they've been using a name attribute on each element
TB: that's their "option 2?"
[Discussion of ids/names]
Q: can we see an example?
[paulc]
OWL Language Reference defines the Namespace http://www.w3.org/2002/07/owl#
[TB]
DO: <things that you have to understand about WSDL to understand>
[tim-mit]
namespace # symbolspace _ name
[TB]
NW: Owl ontology doc is served as text/xml <barf>
[CL_]
With an xsl stylesheet to turn it into 'html for display'
[TB]
NW: e.g. of functions & operators, fn:multiply could be turned into f-and-o-doc#multiply
[CL_]
Oddly, MSIE displays the source anyway. Mozilla displays the html rendering. Opera displays the source as inline text mess
[TB]
NW: it's abstract in that it points at the description not the implementation
[Stuart]
I said "What Norm said"
[TB]
PC: if I wanted to point at the "sum" function, should I point at the F&O doc?
NW: yes
[Roy]
All resources are abstract
[TB]
Several: so spec is namespace doc even if they don't have the same URI. Note that a spec doc could easily be a RDDL
[tim-mit]
NW said that they would like to see the f&o namespace return a description of each document.
[TB]
NW: even if you published it in eleven pieces, you could publish the monolithic doc at the namespace name
TBL: why?
CL: because you get something useful if you follow it
PC: also, I don't have to generate 300 new URIs, they're already there
NW: when SemWeb publishes Owl ontology, they can have a RDDl that allows choice
[Zakim]
tim-mit, you wanted to say that if our architecture document gives a preference to human over machine readable aspects then it is wrong and that is not a healthy or useful bias.
[TB]
TBL: my math example, in mozilla, shows the XML source
[CL_]
An example of doing exactly that (not for namespace URIs, but other URIs used as labels):
http://www.w3.org/TR/SVG11/feature.html
[TB]
TBL: this doc is useful for validation & inferencing
[CL_]
All the feature string URIs in SVG 1.1 refer to the part of the spec that defines that feature.
For example: http://www.w3.org/TR/SVG11/feature#SVG-dynamic
[TB]
TBL: can answer queries directly by machine processing it
[DO]
Interesting chain of thought. The "meaning" of a name consists of many things: descriptions, syntactic constraints, etc. A specification may refer to a schema, but typically the spec is the "normative" definition. This seems like an authoritative and right thing to put in a ns name doc.
[NW]
Indirection allows us to present both kinds of documents without bias. And if someone asks for application/rdf+xml, I don't see why we wouldn't return the ontology document directly
[TB]
TBL: people can follow links, they just need a clue RDF supports indirection. A function is still an abstract thing. The point is: if current arch doc says that human-readable is more important than machine-readable, that is an inappropriate bias.
SW: +1
[tim-mit]
We should work toward both human and machine readable namespace documents without detriment to the other.
[DO]
TB: listening to this, RDDL is even better, but requires frag-id indirection.
[TB]
All this discussion increases my conviction that RDDL hits the sweet spot for this, if you allow indirecting the fragid semantics
[NW]
We should do nothing that makes it harder to publish machine readable documents, or treats them in a second class way, but I don't think it's wrong to say that a human readable document should be available in a namespace document.
[tim-mit]
frag-id indirections: defining RDDL mime type to take any frag id and have a way of RDDL telling you that the fragid refers to that in a given linked document . - timbray
[TB]
CL: Currently it's not possible for authoring tools to allow people to set up smart coneg. But RDDL would be a documented way to achieve this effect
DO: Want to ensure that a doc retrieved from NS name, whichever one you get, the URI that refers to that name doesn't change. So the type of the related resource can't be in the URI, i.e. you can't say: http://rddl#wsdl#foo.bar.baz. You just have to say http://rddl#foo.bar.baz
RF: agrees
TB: webarch says that the meaning of http://foo#bar shouldn't change based on the media-type of the representation
[tim-lex]
TB: A URI with '#' had better mean the same thing in whatever document type
[Zakim]
tim-mit, you wanted to say that content negotiation for fragids has problems. It should not be done unless you are using just # localname in practice. Instead, just use the most powerful language.
[TB]
TBL: we now that fragids & coneg have problems with potential bugs, we should advise against. But if you really want to do this, you have to ensure that no breakage ensues. This is easy with for example RDF & N3, or HTML & XHTML TBL's examples would be useful to whoever's writing up that bit we assigned today.
[DO]
Try to say this a bit clearer, that RDDL or WSDL or RDDL->WSDL or HTML, should use the same URI for the name. Defining a "service" can't have "WSDL" in the URI. To refer to the WSDL definition of "service", the URI must have in some optional piece that says wsdl, maybe ;wsdl?
[TB]
TBL: We could suggest that it looks like WSDL has really complex syntax this reduces the likelihood that coneg or equiv will work. This idea of RDDL fragid transparency sounds complicated & hairy and needs some research done. If you're pointing to lots of things, you have to be really clear which should be used for the fragid.
CL: and it would be impossible to point into a piece of the RDDL doc
RF: Put a catalog in the RDDL doc

TB: It already has a catalog. So it needs a virtual ref to itself in the catalog.

CL, TBL: you can't point inside the RDDL doc
[CL_]
AHA! if you get example.org/foo.rddl#html then you get the human-readable html stuff, complete with text/html media type and you can get at the parts of the document
[tim-lex]
foo.rddl#plus
[TB]
TBL: it breaks if the RDDL doc has another URI...
[CL_]
No, if it has the *same* uri, but a different media type and thus different frag handling
[NW]
That identifies #plus in whatever you get back. What you get back depends on what you asked for.
[CL_]
#self ??
[TB]
Oops, I got that backward: TBL: if *works* if you have another URI for the html version of the RDDL
[NW]
So if you ask for foo.rddl#plus,wsdl, you get the wsdl back and #plus is a fragid in the wsdl
[Stuart]
Chris/Norm, but the server doesn't see the fragIDs
[TB]
Exactly Chris
[NW]
If you ask for foo.rddl#plus,rddl, you get back the rddl document and the #plus is a fragid in the rddl
Stuart, who said anything about the server?
[TB]
TB: We need to write a response to JMarsh's latest '?' proposal. Point out it's a land grab on the URI space
TBL: Would like encourage the use of #fragids
[Stuart]
Well there seemed to be a bunch of talk that sounded like the fragId has some effect on the representation returned (or at least that's what it sounded like)
[TB]
Roy's manifesto:
  1. All resources are abstract
  2. All URIs are names
  3. The only distinction between left#right is who gets to map left vs right
  4. All resources can be represented using descriptive data formats
  5. All fragments are URIs that are identifiers for resources that can be represented with a multitude of formats, i.e. the same way any resource can.
[tim-lex]
I disagree with 1, agree with 2, don't understand 3, think that 4 shows a lack of well-defined meaning of "represents"
[tim-lex]
RF: The fragment ID is interpreted by the client according to the spec of the Internet media type.
[Roy]
I know, I invented that piece of the architecture
[TB]
TBL: The WSDLers are going to a lot of work to make a new XML data format. This is a lot of work which has been done already for RDF. But since they didn't use the RDF model, they have to do all this MIME type stuff.
[DO]
Should all xml vocabularies that want to describe abstract components use RDF?
TBL: Not use RDF, but model as RDF.
[TB]
TB is going to write an essay on why RDDL provides a good answer if we can sort out the #fragid redirecting, and will propose a clean way to do that
TBL: Not necessarily required to RDF/XML syntax. As long as you implement RDF model
TB: TBL points out that there are good solutions in place for those in RDF data model, but empirically there is lots of stuff being created outside that model and we need something to say for them
TBL: My proposal is that the WSDL people, when making new languages, use fragids, document it via a mime type.: Proposal 2: model WSDL in RDF, describe how to map WSDL into RDF (or just use RDF syntax). Proposal 2 is better in the long term, but proposal 1 is better than the other ones we've seen.
[tim-lex]
I agree that proposal 1 is better than the other proposals except proposal 2. I agree that proposal 1 is better than the other proposals which involve WSDL as an XML language.
[TB]
DO: we need to not only bless the notion of fragids, but in the case of WSDL we should look at the way they're constructing them, because there has been push-back
TBL: agree that we need to drill down
http://lists.w3.org/Archives/Public/www-ws-desc/2003Sep/0075.html
NW: how about replacing '?' with '#' in the above
CL: Note that this means that it does not get sent to the server.
[Stuart]
Is it wise to use fragment IDs for identifying abstract components. Within a namespace, even though it is the most natural and convenient mechanism? Is there another mechanism that would be preferable?
[TB]
RF: has concerns with syntax of that fragid
SW: I don't think we have to design their syntax for them
[Stuart]
http://lists.w3.org/Archives/Public/www-tag/2003Feb/0042.html
[TB]
RF: if they have a WSDL API with large numbers of function/variable names, treating it as a single namespace could be messy
[NW]
I propose that how they do the software engineering is something they are more qualified for than us.
[TB]
RF: We should recommend that they have a way to compose WSDL docs
TB: +1 to Norm
DO: Note that their proposed scheme has brackets
[CL_]
Recent xpointer schemes do
[TB]
NW: note that the latest JMarsh proposal has no parens or anything, very nice & clean
[tim-lex]
Resolved: Using fragid is not only acceptable but preferable. We like the 0075 solutions with s/?/#/
[TB]
DO: and to update draft finding saying that we like the latest best of all the ones we've seen
[tim-lex]
Action DO: Write up this resolution in his finding on abstractComponentRefs-37

3.8 siteData-36

[TB]

PC: what is the "SHOULD/MUST" statement in the webarch doc that comes out of this?
NW: App designeres MUST not assert that specific files go in specific locations in your webspace
TBL: strawman doesn't solve the problem becasuse it requires each page to claim site membership. If you could program server to do it in an HTTP header that would be easier. That would be better for someone who has a large site as opposed to a little blog in AOL-space
RF: prefers <link rel= or Link: <url>;rel="site"
TB: yeah, but for 10,000 HR pages on enterprise web site it would be nicer to set up HTTP headers
[tim-lex]
aboutEachPrefix
[TB]
Action TB: Refine strawman and produce draft finding
[tim-lex]
{ ?x.log:uri string:startsWith "http://www.w3.org/2000/10/swap/" } => { ?x web:site Swap }
[TB]
CL: Could redirect thorugh that to get robts etc like RDDL
[tim-lex]
siteDesc
[TB]
TBL: call this thing a "site description" might work better than "site document"
[tim-lex]
siteDesc#thisSite
[TB]
TBL: two options: point to a site description doc which has lots of interesting metadata. Or you give a fragid. TB's draft finding should explain how for example you replace robots.txt.

3.9 charmodReview-17 and status of Charmod spec

[TB]
PC: propose we ask Stuart to send a note to i18n WG expressing concern that the intent of our comments are not receiving attention. We are concerned that due to overload we will have a very long wait for the parts that the world needs.
[tim-lex]
PaulC: What shall we do about Charmod? We asked the I18n WG to publish what they had ASAP and split the rest off so that they can get the stable bits out so that others can reference it. We are worried that recsources are getting scarcer in I18n and that the doc will be later and later
Proposal: Produce a fiunding with he good bits of charmod copied and pasted?
Proposal: repeat our request, and ask for their rationale.
[CL]
http://www.w3.org/International/Group/charmod-edit/
[tim-lex]
PC: Please contact the I18n chair directly.
[CL]
last call disposition of comments
http://www.w3.org/International/Group/2002/charmod-lc/
[TB]
Action Stuart: Contact the i18n group to express our concerns.
[tim-lex]
PaulC: I think the I18n group underestimates the resistance which is going to occur to the unbaked material in charmod.
[CL]
C119SRCChris Lilley: Split the document in two
Decision: Rejected.
Rationale: The proposed approach would result in a lot more work, as all the chapters have been written as part of a single document. Note also that other chapters (including 6 String Identity Matching and 7 String Indexing) would have to be dropped from such an early document, as both depend on Early Uniform Normalization. This would, effectively, leave only chapters 3 Characters and 9 Referencing the Unicode Standard and ISO/IEC 10646.

4. Not covered during the meeting

4.1 Identifiers (URIEquivalence-15 , IRIEverywhere-27)

4.2 Qnames, fragments, and media types(rdfmsQnameUriMapping-6, fragmentInXML-28, putMediaType-38)

4.3 New and other Issues requested for discussion. (mixedUIXMLNamespace-33, RDFinXHTML-35, siteData-36 plus possible new issues)

Existing Issues:

4.4 Miscellaneous issues

5. Other actions

Ian Jacobs for Stuart Williams and TimBL
Last modified: $Date: 2003/10/16 15:47:09 $