W3C | TAG | Previous: 14 Jul teleconference | Next:28 July 2003 teleconf

Minutes of 21-23 July 2003 TAG face-to-face meeting

Vancouver, British Columbia (CA)

Nearby: IRC logs (21, 22, 23)| Teleconference details · issues list · www-tag archive

All present. Back row from left: Norm Walsh, Paul Cotton, Chris Lilley, David Orchard, Roy Fielding. Front row: Tim Berners-Lee, Stuart Williams (Chair), Dan Connolly, Tim Bray, Ian Jacobs (Scribe).

TAG, posing in front of same motorbike as in Sep 2002, in Vancouver

1. Administrative

  1. Resolved: Thanks to BEA, Schemasoft, and Antarctica for hosting the meeting!
  2. Accepted minutes of 14 Jul teleconference
  3. Accepted this agenda
  4. Next meeting: 28 July teleconf.
  5. Resolved: November face-to-face meeting moved to 15, 16, morning 17 November in Japan.

Agenda:

21 July

RDDL, namespaceDocument-8

See 1 June 2003 RDDL draft as part of addressing issue namespaceDocument-8

[IanYVR]

TBray: Should XSLT that transforms RDDL to RDF be included in an appendix of RDDL Note? Should we say anything about standing of that RDF? I have not yet created modular DTD.
SW: There's an issue about whether we should use XLink or not (per our other discussions about linking).
TBray: Original version of RDDL used XLink, but that seemed like a bad use of markup. There are well-known distinguished semantics in RDDL that would be stretching XLink semantics. Also, this is the smallest possible solution, which I thought would be the best.
Action PC 2003/04/07: Prepare finding to answer this issue, pointing to the RDDL Note. See comments from Paul regarding TB theses.
[Comments from PC]
TBray: My recollection is that the finding was going to (1) outline how we got here (2) say that it's a good idea to have a namespace doc and (3) RDDL is a candidate.
PC: There was a sticky point in the original theses about the use of URNs. There is no record of the TAG agreeing with all of the theses.
DC: We don't have to agree with all of them.
TBray: I think there was broad consensus about most of them except the last couple, #5, and #6. I propose that we:
  1. With the blessing of the TAG, revise the Note to provide a more obvious example.
  2. Dig up XSLT-to-RDF transform and put in appendix.
  3. PC writes a finding that says namespace docs can be useful and here's a Note that defines a format specific to this application.
TBray: I don't think we need to address all of the theses for us to finish this issue.
[Zakim]
DanC_jam, you wanted to test the queue and to play thru some scenarios: RDFS, XHTML, some namespace 'defined' with an XML Schema, some WSDL example
[IanYVR]
DC: I'd like to (1) See three examples of RDDL since it has costs and benefits and (2) I'd like the finding to say that xml schema is another option. I'd like examples with RDFS, XHTML, XML Schema, WSDL.
TBray: I think that it would be useful to put a RDDL document at the end of an RDFS namespace; for improved understanding of RDF Schema terms.
DC: Suppose we have http://www.w3.org/1999/.../rdf-schema@subClassOf as a namespace name. What would my browser show? How do I find RDF triple for subClassOf?
TBray: RDDL would point to a directory....
[DC draws RDDL document that links to another document with RDF assertions associated with subClassOf]
DC: Will the files (.rddl and .rdf) have the same names? I want to use content negotiation.
TBray: I think that in some cases you would want to use content negotiation (especially RDF case).
[Examine case where file names are different (i.e., no conneg).]
[Chris joins meeting]
TBray: So in this example, use nature"= "...rdf-syntax" and purpose = "formalDescription". You could have another document in .n3, with nature="n3" and purpose="formalDescription"
DC: What is content type of .rddl document?
TBray: application/rddl+xml or application/xhtml+xml. Most (modern) browsers will handle application/xhtml+xml
DC: I get a "save as dialog".
TBray: Then you might have to serve as text/html...
DC: If we use "text/html" we have to put the HTML WG in the critical path and they'll say no.
[See xhtml 1.0 for guidelines on usage of text/html and application/xhtml+xml]
DC: I don't have any problem with rddl+xml. I think the RDDL spec needs at least a finding on content type.
[Agreement]
TBray: The RDDL drafts come with a list of canonical natures and purposes.
TBL: You should be able to get machine readable data without redirection (e.g., through conneg, by embedding RDF in RDDL, or by using RDF in place of RDDL).
DO: Another solution - put metadata in the URI...
TBray: TBL can put RDF at end of namespace URI if he wants. I would argue with TBL but we have no business forbidding that.
NW: What is compelling reason for having RDF right off the bat?
TBL: If you can get data in time t, why take it in twice the time?
DC: It works today.
TBray: TBL's applications are atypical, in my opinion. The most common uses of namespaces is to compare namespace URIs as strings.
TBL: It is a core design item of the sem web to be able to get info with only one link, not an indirection.
TBray: In my opinion, the benefits of indirection are so high you'll end up doing this anyway.
PC: Why write a finding if there's no preferred format?
TBL: It's good to write a finding that says "It's good to put info at the end of a namespace URI."
CL: I don't see the point of a finding that doesn't make any recommendation about a format. Machines have no guarantee of what they'll finding.
DC: I think it's good to say "Here are some issues, they are approached different ways with different formats."
NW: I have found over last year that I would really like an indirection, and content negotiation is inadequate. It's a chicken and egg problem. APIs won't give indirection if there's no format out their they can know about. "May" use RDDL is good enough for me in a finding.
TBray: And in the finding, say that RDF has been useful for RDF applications.
Straw poll: (1) Finding says that namespace docs are useful, enumerates some issues, points to RDDL. (2) RDDL Note published.
Comfortable with that: NW, DC, TBL, CL, TB
PC: I want the finding to say that whatever is there should be human readable. We don't seem to be discussing that particular point.
TBL: I think that we agree that it's useful to have something human readable. But in a sem web application, the machine readable information is primary. There are other ways to make the data human readable (e.g., through a style sheet). Don't say "human readable as opposed to machine readable".
TBray: I think we can say that there are substantial advantages to human-readability; sem web applications can, for reasons of performance, do other things.
[Zakim]
DanC_jam, you wanted to ask if folks find http://www.w3.org/2000/10/swap/pim/email human-readable
[IanYVR]
[Some grumbling about level of human-readability ofhttp://www.w3.org/2000/10/swap/pim/email]
DC: If there are serious concerns about this being-human readable, I claim that "human-readable" not meaningful as a term.
[DanC_jam]
Now tell me if the following is human-readable: http://www.w3.org/2001/02pd/rec54
[IanYVR]
DO: My recollection is the same as Paul's. The second that the Sem Web folks put machine-readable docs that aren't human-readable, the Web Services folks are likely to as well. I'd like the finding to say "SHOULD be human-readable" and MAY for RDDL.
DC: My point is that an RDF document can be human-readable when displayed with style sheets.
PC: I don't think there's a way to make an XML Schema human readable in a way that meets my test.
CL: What's the test for human-readable?
PC: In many cases, a title at the top, "This doc defines the meaning of the namespace FOO. How it's used...what additional resources are available...purpose of namespace". Also include why someone might want to use the additional resources.
NW: Human readable is important, but not the only important thing; indirection also important.
TBL: I propose that we say that human readability is a good idea. When you are publishing something that is machine-readable, here are some techniques to make that information human-readable as well - use style sheets, embed human-readable information.
[DanC_jam]
hmm... the RSS case is an interesting case in point.
[IanYVR]
TBray: I would be ok with a compromise: (1) You should achieve human-readability (2) RDDL is an option. And here are some techniques for making information human readable.
PC: I'd rather point out conflict in a finding than hide it. I don't want to "hide behind a SHOULD"
[Chris]
Should means 'must unless you have an excuse'
[IanYVR]
PC: I think the TAG needs to give clear reasons for why one wouldn't put something human-readable at end of namespace URI.
TBL: There is a spectrum of applications from very human-readable to very machine-readable. This is not a "conflict" but should be considered as richness.
PC: I think it would be useful to tell the community about the advantages of indirection. The finding should help new WGs avoid pitfalls by conveying benefits of human-readable, and indirection.
[DaveO]
Is this "Namespace document Best Practices?"
[IanYVR]
PC: If you have multiple schemas for the same thing, RDDL gives you advantages. If you only have one format and it's absolutely a characteristic of the application that performance is important, ok to use single format, but cost to losing human-readability and indirection. I want to avoid creating subgroups on the Web.
DC: I have an outline for a finding.
DO: I'm hearing PC argue for best practices on how to use namespace names. What kind of apps should dereference them.
[TB to summarize points for PC's finding]
[TBray]
Finding should say:
  1. Having a document at the end of a namespace URI is good.
  2. It's good if those documents are human-readable.
  3. Indirection is useful in those documents. Point out the ability of RDDL to carry indirection..
  4. There is some risk involved if you bet on some format for such documents as being the One and Only Format.
PC: Usage scenario v. design scenario.There are advantages of indirection to have multiple different resources for human wanting to use the namespace.
[TimBL-YVR]
Point out the ability of RDF to contain arbitrary eg dublin core metadata.
[IanYVR]
TBL: Useful to have an example using RDDL and an example using RDF?
PC: I think the finding will give some examples of namespace docs.
TBray: For the Note, I've agreed to put some examples in, to include xslt script in appendix. And say a few words on content type.
NW: You need to inline natures and purposes (i.e., put the list in the spec)
DC: Put some examples showing their usage.
NW: One of the natures should be "RDDL Document" (forward versioning)
PC: I think that reasons for publishing Note have slipped by. There might be other technical issues, we might want to register content type.
TBray: I think if we publish Note we've done our job.
PC: We should also send email to the AC explaining our position.
IJ: I heard from AC meeting "Publish as Note first, then we'll figure out what to do."
[DanC_jam]
(did the minutes include tbray's RDDL todo? at the risk of redundancy: A: examples. B: XHTML DTD minutiae C: XSLT to convert to RDF, D: media type)
[IanYVR]
Action items for TB (RDDL Note) and PC (issue 8 finding) continued.
DC: I'm happy to contribute text to PC's finding on content negotiation.

Findings in progress

metadataInURI-31 and abstractComponentRefs-37

[IanYVR]
SW: Is "don't peek inside" enough advice? Questions about what one can infer from different pieces of a URI (e.g., resource nature from scheme registration) A number of perspectives: origin server (assignment authority) v. infrastructure (e.g., caches, libwww), v. applications.
[Roy joins meeting]
TBray: I think happy medium between minimal approach (DC) and SW's current finding is:
  1. When you are processing a URI, there are normative specs (starting with [URI], then scheme specs); it's fine to peek inside URIs and interpret per normative specs.
  2. Beyond that it's inappropriate to make other assumptions by peeking in URI UNLESS you have private agreements (i.e., rules published by the URI authority).
DO: I think that we need to describe when it's ok to peek inside a URI. And when it's ok to write a spec that says it's ok to peek inside a URI. I had an action item to talk to WSDL folks about why they want to peek inside their URIs. They have created a number of symbol spaces. Names are not unique across symbol spaces. They want to use the symbol space to differentiate items. [See issue abstractComponentRefs-37 and 19 June summary from DO]. They want to have metadata in a well-defined format so that software can have predictability for how to process URIs in WSDL docs. So the WSDL spec would be a normative spec for how to interpret the URIs in WSDL docs. I think that there is at least one group that believes that an example of a "normative" spec is the WSDL spec.
[Zakim]
DC to TB: How is what you said different from SW's draft finding? What is an example of one of these WSDL non-opaque URIs?
TBray: I think draft finding is too long, but I'm prepared to accept the assertion that SW's finding says what I mean. Do people agree that it's ok for the WSDL folks to say how to interpret their URIs?
[Zakim]
TimBL-YVR, you wanted to ask for a summary of any substantial points made on the thread not compatible with the finding as is and to ask a determining question of DO as to whether a non-WSDL-sware agent could be able to determine what is denoted by one of these URIs in the WSDL URIs.
[IanYVR]
TBL: I have a criterion for this: suppose that someone has not come across the WSDL spec. Given a URI that was constructed according to the WSDL rules, can someone with such a URI (alone) determine that it's a WSDL URI? For example, do they get back a description (e.g., in a representation) of how to use the URI?
DO: Part of issue 37 is to use the namespace name and frag id syntax that uses symbol space metadata. "Clever" use of frag ids. The domain authority can do what they want when they construct the URI. Then, the restrictions about the frag id kick in.
[TimBL-YVR]
DO: They plan to use a namespace name with has a particular frag id syntax. The sample URI is
http://airline.wsdl/ticketagent/#input(TicketAgent/listFlights/listFlightsRequest.
TB Proposal: Section 1 of Stuart's draft could stand alone and solve the problem
[DanC_jam]
I think I agree with Bray that replacing the finding by its 1st section would be forward progress
[IanYVR]
NW: You can't say squat about meaning of frag ids until you get the representation with the proper content type.
TBL: I'm fine to talk about an imaginary document. But if you do retrieve it, you need to register a new content type or a frag id syntax.
[Zakim]
TimBL-YVR, you wanted to say that if you want a funny fragid syntax you need a new mime type
[IanYVR]
DO: The WSDL WG wants to register a new content type.
[Stuart]
Re: specs defining patterns for using structure in URI assignments to name abstract things, how do you establish a chain to establish authority to make such an assignment? 2396 delegates assignment authority to URI schemes which in turn delegate onwards ultimately to some specification or person or organisation. Such an authority could then explicitly state that they do in fact make assignments according to the specified pattern.
[IanYVR]
DC: I second TB's proposal.
SW: There was feedback on the list that the parts after section 1 were useful.
TBray: In an ideal world, I would leave section 1 and provide a bunch of examples.
DO: I agree with section 1 with examples, including an example for what format spec designers can do. Also, what format spec designers should do about path components.
NW: I.e., using "/" instead of "#".
DC: I'm happy with DO's proposal.
RF: If a scheme does not provide for authoritative metadata, then it is normal to use the URI to get more information about what you might get back.
CL: If this is about HTTP only, we should say that. If about more schemes, we need to talk about RF's issue.
TBray: I think that the text as written is correct since it says that you can do what the spec authorizes you to do. So, for FTP, you can use path components for directory navigation.
[DanC_jam]
TBL, why not consider ftp? FTP is how a significant part of the Web is written
[IanYVR]
RF: I don't think we should make the finding specific to a URI scheme. Give an example of a relative normative spec that is providing policies for looking within the URI.
TBray: HTTP is distinguished in that other than the "/" there is no info you can use.
[Zakim]
TimBL-YVR, you wanted to examples and to ask Stuart to add a a mention that fragid needs mime type in 3.4
[IanYVR]
RF: Section 1.1, part one - We need an example.
TBL: 2.2 and following should be under 3 (stuff about HTTP). "And if it's HTTP...."
SW: I'd prefer to not go into a particular scheme. For me, section 2 was about client perspective and section 3 was from perspective of assignment authority. I could merge the two and do each component from both perspectives.
TBL: You need to say that the authority can never get to a server manager unless you have gone through a spec. And you need to use registration mechanisms (e.g., for new frag id semantics).
DO: I think 37 depends on SW's finding.
[Veering into issue 37 and discussion of 19 June summary from DO]
DO: One proposal is for metadata in path component v. fragment identifier.
RF: Not just putting metadata in the path. It's metadata that's to be interpreted by the client while inspecting the URI.
[Zakim]
DanC_jam, you wanted to ask that forms be one of the examples (perhaps redundant: other examples I agree would be good: making a new mime type that says how #blort works, and path components).

CL: Old bad HTML forms?
DC: HTML forms are bad?
CL: Hence their redesign, clearly.

[IanYVR]
DC: And mime types say how mime types work.
[Zakim]
Chris, you wanted to worry about implying that inferring anything from scheme is also bad, which it isn't
[DaveO]
Question: Can spec designers constrain the format of URIs to contain metadata in the path component of a URI?
[TimBL-YVR]
Yes lets discuss 19 June summary from DO. I disagree with 6 but agree with the rest.
[IanYVR]
SW: Question of whether mailto: URIs can only be used to refer to mailbox addresses.
[TimBL-YVR]
Answer: No they should not
[IanYVR]
IJ: It seems to me that a single finding might cover both issues.
SW: That might be an outcome.
DO: RF suggested that WSDL WG not use frag ids for metadata. RF suggested alternatives in the path component. Or use of ";"
RF: Traditionally identifiers are orthogonal to media type definitions. Putting metadata in URI puts a tie between how URI is constructed and how media type is constructed. It's worse to do this for the path component than for the frag id component.
10. Use a URI convention that slashes separate namespace URI and component identifier. Posted by Roy.
RF: The reason I included this option: http://airline.wsdl/ticketagent/TicketAgent/listFlights/listFlightsRequest;input
RF: It's associated with same level of hierarchy.
DO: When using frag id solution, problem of inconsistent frag id semantics across different representation media types. As part of issue 31, we need to say something in conjunction with issue 8. If you want to put your own semantics into frag id, you can't use RDDL or conneg.. If people want to use RDDL, they can't put metadata in their own frag id syntax.
TBL: The primary requirement is that you can do the right thing when you dereference the URI. I think that making the identifiers unique is reasonable. I think that there other ways to ensure uniqueness other than by prepending class description, however. The reason that you don't establish conventions for how to interpret the last few pieces of the path is that you lose if anybody else defines semantics for the same components. This part of the URI is not your space. This is server manager space. You can't control what people do with URIs. The Web architecture is that this is internal to the server.
[Zakim]
DanC_jam, you wanted to ask how an arbitrary party "groks" this example URI
[IanYVR]
DC to DO: Do you have questions about the solution with the hash in it? Earlier TBL asked how an arbitrary party figures out that a URI is governed by the WSDL spec. I'd like to walk through that.l
Example URI: http://airline.wsdl/ticketagent/TicketAgent/listFlights/listFlightsRequest
[TimBL-YVR]
The server writer and the server administrator own teh URI space on a server. As WSDL spec writer, you can't put constraints on that space, or there will be horrible clashes. The URIs on web servers are generated from exposed foreign systems, databases, etc.
[IanYVR]
DO: One of the issues is that, without a frag id, you don't know where the end of the namespace is. If you use this syntax, you can't get back to WSDL spec.
NW: You can dereference the URI. Send back the WSDL document. You can't tell what the URI means without the deref; but that's the same issue with the frag id solution.
[DaveO]
I was wrong, Norm's right.
[IanYVR]
RF: It's also fair do assume that if RDDL is going to be used as a descriptive text, that it's capable of defining an arbitrary number of frag names in the description.
[DanC_jam]
(if you continue that line of thought, you'll end up with RDF)
[IanYVR]
TBray: If you are putting metadata in a URI, it's at least questionable; this gets in the way of server administration.
DO: See option 9 for put semantics in RDDL frag ids.
TBray: Seems to me that the WSDL folks are pushing up against limits of what's comfortable to do with URIs. One could, for the RDDL media type, allowing redirection of a piece of a frag id to be interpreted according to the media type of the related resource.
DO: That's option 9.
[Zakim]
TimBL-YVR, you wanted to suggest the customer is right
[IanYVR]
TBL: What the WSDL folks want to do is a variant of what the RDF folks have done. And it's reasonable. The point is that if you find one of these URIs in space, you need to be able to find the link back to the defining spec.
[Zakim]
DanC_jam, you wanted to say that the WSDL folks are trying to give URIs to important resources
[TimBL-YVR]
RDF does this quite successfully.
[IanYVR]
DC: Bray observes that "it hurts when they do this"; I don't think we should tell them not to do this - we told them to give URIs to important resources.
NW: How does it help if the WSDL document is an RDF?
RF: RDF has not invented any of this stuff....
[Chris]
nw: rdf fails the same way this fails - no idea what the fragment means until you retrieve the resource
[TBray]
See my email about RDDL and abstractComponentRefs-37.
[IanYVR]
DO: For RDDL, we should look at this question of indirection, and how to include metadata in URIs that can be forwarded through RDDL.
PC: In version 1 of the Architecture Document?
TBray: Yes. I think it would be useful.
[Zakim]
TimBL-YVR, you wanted to propose we recommend [3]
[IanYVR]
TBL: The RDDL solution doesn't work with RDF. Anyone who uses RDDL has to put a wrapper around their frag id.
RF: If RDDL treats all frag ids as opaque strings....
[Chris]
http://airline.wsdl/ticketagent/#input/TicketAgent/listFlights/listFlightsRequest

Look: no parens

[IanYVR]
TBL: Suppose RDDL doc points to three alternative formats, you need to know format of related resource to interpret frag id semantics.
RF: Use flat namespaces.
[Zakim]
DanC_jam, you wanted to suggest RDDL has union links
[IanYVR]
DC: I claim that RDF solves these problems. But if you want to have RDDL doc in between - if you want to interpret the frag id w.r.t. a RDDL document, you are saying you can use a fragment in any of the alternative related resources.
TBL: This is only for the case of "ids".
[TimBL-YVR]
RDDL = Poor Man's Content Negotiation
[DaveO]
WSDL proposal does NOT use "ids".
[IanYVR]
TBray: Could write RDDL spec to say that you can't interpret RDDL instance until you've retrieved related resources.
[DanC_jam]
Using RDDL as the content of the HTTP 4xxx "multiple choices" would be pretty ideal.
[TBray]
Can't interpret RDDL #fragment IDs against RDDL itself, but against a related resource. The price of this is that you lose the ability to point to a thing inside the RDDL document itself.
[Zakim]
Chris, you wanted to wish fragment identifiers identified fragments not 'you get to rewrite any spec'
[IanYVR]
TBray: When you register a media type you should specify the frag id semantics. It's perfectly ok to specify the semantics to be "This frag id doesn't apply to me; it applies to a related resource representation."
[DanC_jam]
(this conflict between pointing at parts of XML documents and pointing at 'abstract components' is well known in RDF-land, fyi... it's related to our RDF in XHTML issue, and our fragments in XML issues)
[IanYVR]
RF:Unless you use xpointer, I don't see any reason why the syntax wouldn't be identical for the WSDL document as it would be for the RDDL document. E.g., if you use a dot-separated list of names as WSDL frag id syntax, there's no reason why that syntax and the RDDL syntax couldn't be consistent.
[Zakim]
TBray, you wanted to say that you can to point into a RDDL document just fine
[IanYVR]
[Walkthrough of options from 19 June summary from DO]
DO: First, let's look at requirements:
  1. It must be possible to identify each conceptual element in a WSDLvocabulary with a URI.
  2. It should be simple to create and use the URI
  3. It must be compliant with the URI specification.
  4. It should be able to identify WSDL extensions, ala soap:binding, soap:operation, soap:address, soap:body, soap:action, soap:fault, soap:header, soap:headerfault, http:address, http:binding, http:urlEncoded, http:urlReplacement, mime:content, etc.
  5. It should be possible to use relative URIs for the abstract components
  6. It should be possible to extract the type information from the URI.

    It should be possible to retrieve a namespace name document given an abstract component reference.

DC: I don't buy all of the requirements.
[Chris]
Comment on requirement 6: http://www.w3.org/TR/xmlschema-2/#dateTime
[IanYVR]
DC, TBL: I don't agree with 6.
[Chris]
I can extract a type (dateTime) from that URI or rather, I can use that URI to identify dateTime type
[IanYVR]
TBL: Req 6 is architecturally harmful.
[Zakim]
TimBL-YVR, you wanted to propose option 3.
DanC_jam, you wanted to note that issue 37 is now barely distinguishable from issue http://www.w3.org/2001/tag/ilist#fragmentInXML-28
[IanYVR]
CL: People who define URIs can put whatever metadata they want in the URI.
DC: Issue 28 related - do frag ids refer to syntactic element or can they refer to abstractions?
DO: Issue 37 proposes a particular interpretation for issue 28. But if we recommend another solution for 37, it's not related (i.e., frag ids not used).
RF: For req 5 - does "relative URI" mean relative to the namespace URI or unrestricted relative URIs? Only way you'll get unrestricted is if you don't use frag id syntax solution.
TBray: What are the identifiers used for in practice?
DO: E.g., identification of input when building tooling. They might have a lookup to see what the name is. There's talk about, on the wire, specifying what an action is in a SOAP header and mapping that to the input.
TBray: Sounds like they want to do what URNs are designed to do.
[Zakim]
DanC_jam, you wanted to ask that the record show that we has some comments and questions on requirement 5, 6, and 7, but that said, let's look at solutions in any order dave chooses.
[IanYVR]
DC: We've discussed the reqs to my satisfaction.
NW, SW, TB: Can live with option 1.
DO: Sometimes WSDL docs are modularized; hard to constrain uniqueness constraint across WSDL docs.
TBL, NW, DC, CL, TB: Can live with option 2
RF: I could live with it as well, but I don't think it's a realistic solution. Too many names.
PC: That's why I didn't put up my hand.
RF: Lots of human error possible in generation in individual names.
Option 3: Require Unique NCNames.
DO: You combine the symbol spaces into one. You combine the symbol spaces into a single space, within a particular WSDL document.
TBray: This is identical to choosing an id. 3 is a flavor of 2.
Option 4: Use XPointer
DO: I think this uses xpointer framework and element scheme.
{Nobody likes}
Option 5: Use element(), XPointer framework
CL: Problems with this option are fixable.
{But no strong support}
Option 6: Develop WSD specific Xpointer scheme
NW, CL: Can live with option 6
Option 7: Schema component designators
CL: Less ugly than 4!
[TBray]
Let the record to show that I don't vote for some of the options because I just don't understand them.
[IanYVR]
DC: Inasmuch as option 7 is not good for WSDL, I don't think that it's good for schema either.
PC: Schema's task is to define global and local things; different from WSDL task (global only)
NW, CL: Could live with 7
RF: Earlier I was going to say that info isn't metadata if it's necessary to identify the resource in question.
Option 8: Use namespace name and new fragment identifier syntax.

DO: This is the current Working Group proposal.

[DanC_jam]
(what Roy mentioned about 'not metadata' is the restrictive vs. non-restrictive clauses, as we discussed, Ian)
[IanYVR]
DC: I think that there's a risk, but not a violation. If you fetch the thing and get WSDL, you can get authoritative info. If you don't fetch it you take the risk that you're wrong.
DC: But someone else could have told you that the doc you get back is WSDL...
CL: What about ".....#/.../..."
DO: So that after "# and before first "/" is symbol space.
CL: I believe it's much clearer to use functional notation, and there might be text after the end of the closing paren.
TBray: I find option 8 unpalatable. RFC2396bis still says that the format and resolution of frag ids depends on media type. Option 8 is at odds with this.
DC: If the guy doesn't fetch the resource, it's not that RFC2396bis has been violated, but person who has dereferenced is taking a risk.
DO: If one follows option 8, it will lead people to put WSDL docs at end of their namespace URIs, and if they don't they incur risk that frag ids will not make sense.
RF: This is a restricted application; you're not going to ever want anything other than a WSDL document.

contentPresentation-26

See CL's "Separation of semantic and presentational markup, to the extent possible, is architecturally sound"

[DanC_jam]
no story? hmm... making up words... restylability
[IanYVR]
DC: The story should raise the issue.
IJ: Accessibility offers lots of good stories of why good to separate content and presentation
[TimBL-YVR]
Section 5.1 muddies level of abstraction and level of detail.
[DanC_jam]
Yes, please add figures.
Yes, well, Ian, I think it's useful for the TAG to let those authors know that they're fighting the medium. There's a time and a place for that, but we can and should be clear that it's not usually good.
[IanYVR]
IJ: I note that some of what CL is covered by the XML Accessibility Guidelines; see Guideline 2 and checkpoint 2.11 in particular. Also, there are costs to separation, including the need to repackage for distribution.
TBL: Sometimes you want to limit the amount of reusability. Distinguish level of abstraction and level of detail.
[Zakim]
DanC_jam, you wanted to note the 'possible' in the title
[IanYVR]
IJ: What about "On the separation of semantics and presentation"?
[Discussion of length of finding...]
CL: For the moment it's exploratory...
RF: Change "abstract" to "detail", or talk about granularity. Don't say "abstract"
DC: For me "abstract" worked.

22 July (Architecture Document)

16 July 2003 Editor's Draft of Arch Doc

Last call process

Note: Issue httpRange-14, although not formally on the agenda, affected the discussion of last call process.

[IanYVR]
PC: Need to schedule last call with groups where there are dependencies
[DanC-AIM]
Hmm... How to ask IETF to review it?
[IanYVR]
TBL: If there's a group where you know there are issues, resolve those before last call. Don't say "we think we're done" while people are still banging on the document on the list.
TBray: If we wait to go to last call before reaching consensus with web ont folks, that's going to take a long time.
TBL: We have an elephant in the room. People are telling us we're not using terms consistently. Namely, "resource" is being used in two different ways that makes the document unreadable (issue httpRange-14, affectionately referred to in this meeting as "the-issue-that-shall-not-be-named" or Volde----).
DO: I think you can elicit the problem without solving.
PC: Unlike other groups, we will have open issues when we go to last call.
[Chris and DanC join meeting]
DO: I think we need to explain to people why arch doc is different from other specs.
CL: The model is that we have a stream of issue and we gradually refine the document over time.
TBray: I think that we still can benefit the community by publishing something that's not complete.
DO: Need to explain why we chose to stop where we did for version 1 of the Arch Doc.
PC: Need to explain to people also that we expect to skip CR.
[DavidOrch]
And say that there will be a version 2.
[IanYVR]
TBray: We could call this web arch level 0 (à la DOM Level 0).
PC: Question of whether to create a new mailing list just for last call comments. I prefer a separate comments list.
SW: Me too, with discussion on www-tag
TBray: It's going to be hard from keeping discussion going on last call list.
PC: Create a monitored list and force every message to be permitted.
DC: I agree that cross-posted threads are a pain.
[DanC_jam]
hmm... a moderated list isn't a bad idea... we'll pretty much have to do the equivalent of moderating it anyway
yeah... public-webarch-comments@w3.org
[IanYVR]
SW: Cost of going to last call on group: increased tracking of issues on doc, ongoing agenda item
TBL: It's my opinion that the document is imperfect and we're saying we want to take to last call anyway.
TBray: It's incomplete, but I think good enough to go to last call.
RF: Last call fine with me. I think it needs a lot of work, but I think it's useful for the process to put out a draft.
TBL to RF: That's not a last call draft, that's a draft.
[TBray]
TBray: What we have is consistent and essentially correct, but not complete
[IanYVR]
TBL: I feel that if we don't address httpRange-14, this will be like the effect of the XML Namespaces Rec ambiguity.
[Zakim]
DanC_jam, you wanted to suggest that we *do* take advantage of Candidate Recommendation
[IanYVR]
DC: I think CR would be a good idea. The doc's intended to have an effect; we can test whether it has the intended effect.
PC: What's the success criterion?
DC: Yes, I think we can find groups to use the document.
TBL: XML Schema had a similar issue.
PC: The infoset spec from XML Core is an example of a spec that you don't implement; you reference normatively. The Core WG left CR when referred to normatively from other specs. Perhaps that's the best we can hope for.
TBray: I think we should go to last call sooner rather than later. I think a lot of what we've written hasn't been written down in one place before. I also perceive that the areas where we lack consensus all involve a layer that is "above" where we are now. These are additional constraints imposed on what we've said already. And layer cleanly. While I accept that the document does not reflect a reality shared by some, I'm convinced that there's nothing in their that hinders them in their goals.
RF: Pay Hayes' comments were that RFC2396 covers an information space that is larger than that covered by the Arch Doc. Pat is not "actually confused"; it's that the Web Arch document doesn't cover the entire space of the Web. He was saying that if you restrict your discussion to information resources, then the document makes sense. It also makes sense if you limit the scope to the information system that is the classic Web. But it doesn't if you include the infosystems that are the sem web or web services.
TBL: I believe that the document should not go to last call without this issue resolved.
PC Summarizing his interpretation: There's a thread on www-tag that TBL thinks needs to be resolved before we go to last call. Do you think that thread is separable from httpRange-14?
TBL: No. I think the change to the document is fairly easy: introduce "information resource" where appropriate. I don't know what the solution to the issue is. Perhaps we could resolve Pat's issue without mentioning HTTP. I don't know what the form the result would take.
DO: I'm disappointed that this is coming up. We told AC we were going to last call, agreed this would not be on the agenda, and now there's a sort of veto.
[TimBL-YVR]
TBL: However, the issue is so close to httpRange-14 that we couldn't discuss one without being allowed to discuss the other.
[IanYVR]
TBL: We could apologize up front that we use the term in two different ways. I might be able to live with last call if there's a red flag at the front of the document.
TBray: I think that Pat Hayes' comment is wrong. I can produce counter-examples. I think his assertion that we are using the term "resource" in two different ways is wrong. I think the document is consistent.
[Zakim]
DanC_jam, you wanted to say I disagree with PatH as well; the webarch doc is consistent; but I think it would be cost effective to try the 'information resource' edit; not that costly and could satisfy a lot more readers
[IanYVR]
DC: I disagree with Pat as well. I still think it would be cost-effective to talk about both classes of resources. Lots of people have that angst and that's our audience.
[Chris]
Is that just renaming one use, or both uses?
[IanYVR]
TBray: I've seen no evidence to convince me that if we proceed with this draft, we are cutting off options. We don't say much about "what a resource is"; we impose no constraints. People point out that in the real world there are constraints. We don't say that and I think that we're right not to make that distinction. There are a number of taxonomies we could choose for categorizing resources. I can give you examples of things that are resources but you'd have to stretch to think that they're information resources. There are other taxonomies that are at least as interesting: class of resources published by hostile govts. for example. I agree that we need a better way to talk about taxonomies of URIs. Our formalism is well defined: URI, resource, representation..The Web today doesn't have a way to talk about whether something is an information resource, and the software all works fine. I think that the document is well-enough along, passes the minimal progress necessary to declare victory. We can't ignore the angst; we need to say something about it, but we don't need to make a big change.
DO: I think most of the TAG feels we don't need to solve httpRange-14 before going to last call. Clearly TBL does.
[TBray]
nope
[IanYVR]
DO: I have concerns about the process. What does my vote mean? TBL has the last word anyway.
DC: Yes, and you signed up for the group knowing that.
TBL: I am definitely uncomfortable when my technical role and my process role overlap.
DO: We are trying hard not to put TBL in that position.
TBL: I have avoided talking about an issue that I think is fundamental for the last year. I've not acted in my role as Director as I'd like the group to reach consensus. I'm not sure that ignoring the issue is the solution.
SW: I note that httpRange-14 is open (from Feb 2003) even if not on this agenda.
[DaveO]
I also said that we just may have to vote and then live with a Director prohibiting Last Call publication, if he chooses to exercise that authority.
[IanYVR]
PC: Director doesn't gate advancement to Last Call.
DC: I'm not satisfied with how issue errorHandling-20 is handled in 16 July draft.
IJ: See "User agents should detect such inconsistencies but should not resolve them without involving the user (e.g., by securing permission or at least providing notification). User agents must not silently ignore authoritative server metadata."
DC: That's not enough about error-handling. Before reviewing the doc in substance, I'm not prepared to say "go forward"
Straw poll: Does TAG wish to advance arch doc to last call substantially as is (with some editorial changes)?
5 move forward, 1+.5+.5 against, 1 abstain
[DanC_jam]
DanC: I want the arch doc to say "silent recovery from errors considered harmful" and say that louder than "data format specs should say what to do in the presence of errors"
[IanYVR]
RF: It's hard to write down principles of things that have not been deployed.

Walkthrough of July 2003 Editor's Draft of Web Arch

16 July 2003 Editor's Draft of Arch Doc

1. Introduction

DC: What are we doing with Editor's notes?
"Editor's note: Todo: Introduce notions of client and server. Relation of client to agent and user agent. Relation of server to resource owner."
DC: I don't think that that's critical.
TBray: Seems appropriate for section 4 when it arrives.
DC: I like the intro.
TBray: Me too.
1.1. About this Document
RF: I don't understand why there's a 1.1 and 1.1.1
Idea: create 1.1.x on intended audience or drop 1.1.1. subheading.
IJ: I will try to integrate scenario more into section 2.
TBray: s/The TAG/This document is intended to inform (same for second "TAG" instance later in third para of 1.1.1).
DC: Paste some of that into status section.
2. Identification and Resources
TBray: Need to reword Principle: "Use URIs: All important resources SHOULD be identified by a URI."
DC: The doc doesn't say "if it doesn't have a URI, that doesn't mean it's not a resource."
RF: I have a rewrite of paragraph "Although there's not precise..." Don't mix up "identity" and "identify". Something can have identity (or many identities). There are means of identification (N-to-1) to those things.
TBray: I would be comfortable saying "URIs should be assigned for all important resources."
[Discussion of identify/denote/name]
TBL: Not all URIs are necessarily assigned. (e.g., hashes). Only in delegated spaces.
RF: That's still assignment.
TBray: Right, at the end of the day you end up with a string that has been assigned to some resource.
DC: I support TB proposed wording changed.
TBray: The reason I'm proposing this is to stay away from the word "identity".
DC: "Assign" is useful. The question is WHO should do something. I think therefore that "assign" is a step in the right direction. The idea is that if everybody shares, we all win.
TBL: It would help a lot if we say "Identifier" here is used in the sense of "naming". The difference is that Tim Bray is named by "Tim Bray", though he can also be identified by his flashy shirt.
TBray: I would be comfortable saying "using id in the sense of name". I am more worried about "denote".
DC: I concur. I think "name" helps and "denote" doesn't (without lots of explanation). Actually, maybe "denote" would be incorrect.
[We read a paragraph that RF has written on this section]
PC: I am wondering whether we might say something nearer to the top about "stable" URIs. Feature of "stability" is also an aspect of importance.
[Chris]
it all hinges on an appropriate definition of 'consistency'
[IanYVR]
TBL: I'm not happy with RF's text.
[TimBL-YVR]
s/produce or consume/convey/
[IanYVR]
TBL: RF's text doesn't address sem web resources.
TBray: General remark on the document - People are going to take this document seriously. There will be lots of debates. One of the ways we should be careful is to take out sentences that don't need to be here. Every sentence that is not "contentful" should be removed.
TBL: I feel that the namespaces spec would have been improved on if some of those sentences had not been removed. I don't want us to follow that path.
RF: Delete "transclude all or part of it into another resource." You can do transclusion without a URI.
RF: Transclusion is not a rationale for many people.
DC: I disagree.
TBray: Purists will debate our use here.
RF: Say instead "include by reference."
DC: Yes.
RF: Delete last para of 2 (before 2.1)
TBL: The second paragraph of 2 is where you would put in the distinction about an information resource. "A resource can be anything. Certain resources convey information when a resource has a link to another one."
TBray: Would it meet TBL's needs to ack the class of information resources? I suggest that we say that the universe of resources has a subset which we will call "information resources" that convey information. And stop there. We ack the distinction but don't put all HTTP URIs on one side of the border or the other.
CL: Add "electronic"?
TBL: No, could transfer via light, for example.
[Chris]
Not about transfer, about category of information, but okay.
[IanYVR]
IJ: About "on the Web"
TBray: I think "information resource" is isomorphic to DO's concept of "on the Web"
[Question of whether "on the Web" means "really does have a representation that is available"]
TBL: From the semantic Web point of view, things are on the semantic Web from the moment you use the URI. But in the common parlance, I think "it really does work" for information objects.
CL: In the common parlance, electronic is also understood...
[Chris]
The common parlance thus applies exclusively to electronic information objects
[IanYVR]
DO: I want "information resource" connected to "on the Web" in the document.
[TimBL-YVR]
URIs identify resources. A resource can be be anything. Certain resources are information resources, which convey information. These are termed information resources. Much of this document discusses information resources, often using the term resource.
[DanC_jam]
Bray: I like that paragraph.
DanC: it doesn't discuss "on the web". hmm...
[TimBL-YVR]
An information resource is on the Web when it can be accessed in practice.
[Chris]
Last sentence, change to "Much of this document, while discussing resources in general, applies primarily or most obviously toinformation resources"
[TBray]
+1 to Chris
[Chris]
Changes from an apology to an explanation
[IanYVR]
IJ: I can work with "on the Web" as a parenthetical remark, in association with other terms, but I don't think it needs to identify a formal part of the architecture and I don't imagine it being used later in the document.
DO: I think the definition should stay away from actual availability.
[Chris]
Ian, wsa does indeed want to use it as a defined term, I understand
[IanYVR]
DO: Fine by me to say that there's a general expectation that a representation will be available.
[DaveO]
Indeed, SOAP 1.2 does use the term "on the web".
[Roy]
I don't think that there is an information resource and non-information resource. I think that some resources are accessible on the Web information system and others are not (or are only indirectly accessible). That is because anything that has state is an information-bearing resource, but you may not have access to that information.
[Zakim]
DanC_jam, you wanted to ask for the figure to go in section 1 or 2; it has the word "identifies"
[IanYVR]
DC: The word "identify" is used in the illustration I'd like to see in section 1 or 2. I'd like the label "identifies" in the figure.
RF: That is Pat Hayes' objection. You can argue it with him.
Review of diagram from Stuart; see also compressed SVG version.
PC: What does "is a" mean.
DC: I believe it's clear enough.
TB, RF: Diagram doesn't add much.
TBray: Change camel case to English
[Support for that]
IJ: I would like to simplify diagram by removing dotted arrows
DC: It's critical that there be three things in the diagram. A lot of people miss that point.
Action CL: Redraw diagram with (1) English words (2) no more isa arrows; just label objects
[Chris]
ok since we just redrew it on the whiteboard, I won't send the old one to the public list but instead, the simplified new one
[DanC_jam]
Ian: yes, I intend to make "on the web" a term
[IanYVR]
TBray: Please lose "exponentially" in para 2.
DC: The point is that it's non-linearly.
TBL: use "dramatically"
DC: There's a lot of data to back up "exponential"; see this plot for example.
[No change; leave "exponential"]
2.1. Comparing Identifiers
RF: I think this isn't true: "An important aspect of communication is to be able to establish when two parties are talking about the same thing."
RF: It's an important aspect of someone else observing that they are talking about the same thing.
[TBray]
Quotation from my comments on 16 July draft: 2.1 Awkward start. Communication between parties is facilitated by the ability to establish when they are talking about the same thing. Then lose the second sentence.
[IanYVR]
TBL: Parties don't identify. They talk about or refer to. They don't identify.
[Chris]
+1 to timbl because context of use is important
[IanYVR]
Delete "In the context of the Web, this means when two parties identify the same resource."
TBL: Say "two parties are referring to the same resource" in following sentence.
DC: "Most straightforward' instead of "most common"
RF: Delete "Depending on the application, an agent may invest more processing effort to reduce the likelihood of a false negative (i.e., two URIs identify the same resource, but that was not detected)." It's covered better in the URI spec.
TBray: Anybody who cares about this really needs to read [URI]
DC: I'm happy to delete that sentence.
[DanC_jam]
pls change "The most common" to "The most straightforward"
[IanYVR]
TBL: I think that the last sentence is useful since it lets people know that there is a risk of false negatives.
TBray: Yes, it's worthwhile saying that false negs can occur; for details look at [URI]
CL: Some apps are more sensitive to false positives, some more sensitive to false negs; choose wisely.
Action IJ: Fidget with this text.
Editor's note: Dan Connolly has suggested the term "coreference" instead of "equivalence" to communicate that two URIs are referring to the same resource.
DC: I can live without that change.
[TimBL-YVR]
"coreference" isin the same class as "denote" - we had decided not to use technical terms.
[IanYVR]
2.1. Comparing Identifiers
TBray: There are two side trips into URI opacity. I think that we need to discuss separately (1) comparing and (2) looking inside
NW: "In general, determine the meaning of a resource by inspection of a URI that identifies it." I'll provide words...
CL: "Although that it's tempting to infer this by looking at the URI that it is about..."
TBL: "...not licensed by the specs..."
[TimBL-YVR]
I am editing a version of the spec with my changes as we walk through the document.
[IanYVR]
IJ: I'll try to create a section on opacity out of some text in 2.1
Resolved: Continue walking through arch doc until we get done.
RF: Don't use the term "spelling" URIs.
DC: The point is that the string has to have the same characters.
RF: Change good practice title to "Consistent spelling or URIs"
IJ: What about lexical?
DC: Same string of characters. The agent should use the same string of characters as originally provided.
Action IJ: Reword the good practice note with new term for "spelling" based on "character string".
2.2. URI Schemes
TBray: Why did "scheme" get changed to "scheme name"?
RF: If you're talking about the string before the colon, its the scheme name.
TBray: The *scheme* corresponds to a specification.
TBL: "There are other *schemes*..."
Action IJ: Prune instances of "scheme name" except for string component before ":".
RF: I use "scheme component" instead of "scheme name" for slot before ":"
[DanC_jam]
perhaps change "Each URI begins with a URI scheme name" to "Each URI follows a URI scheme" or ... hmm...
[IanYVR]
CL: s/to classify/to refer to/
[TimBL-YVR]
<defn>URI Scheme</defn> to be higher up in the para.
[IanYVR]
RF: Scheme names are always used in lowercase: "http URI"
TBL: I disagree; we're talking about the protocol HTTP
Resolved: Change "HTTP URI" to "http URI"
SW: s/identify identify/identify. The scheme definitions use the verb "designate". If we use a different term than the spec we are referring to, that's problematic.
DC: I think we have a good reason to use a different term.
Resolved: Add footnote that the other specs use the term "designate". We take "identify" and "designate" to mean the same thing.
[Lunch]
TBL: There was discussion at lunch about including more best practices.
[DanCon]
TBL: how about "don't use the same URI for something that's an information resource and something that's not". E.g. dublin core title. (Roy also sent a problem report w.r.t. XML encryption algorithm identifiers, suggesting they should *not* contain #s. have you seen that, timbl?)
[Ian]
[Continuing on 2.2]
RF: "Several URI schemes incorporate identification mechanisms that pre-date the Web into this syntax:" The examples are URIs; the identification mechanism is not sufficiently targeted in that sentence to distinguish talking about the URI or the information system. I would make one big list instead of two lists. Change to "incorporate information systems that predate the Web into the URI syntax..."
[Yes]
TB: "We note in passing..." Get rid of "Note in passing"
SW: IRIs are indeed proving expensive.
DC: I think the sentence is insufficiently motivated, but I can't think of anything better.
TB: I propose to delete "We note in passing that even more expensive than introducing a new URI scheme is introducing a new identification mechanism for the Web; this is considered prohibitively expensive."
[Discussion about whether IRIs are new identification mechanism.]
TBL: s/We note in passing/Of course,/. If we are going to make a manifesto, put it higher in the document.
Resolved: Delete "We note in passing that even more expensive than introducing a new URI scheme is introducing a new identification mechanism for the Web; this is considered prohibitively expensive." since network effect covered above.
IJ: I'll delete "When finding available based on Tim Bray's discussion of this topic, link from here."
RF: On "If the motivation behind registering ..." There hasn't been any demonstration that there's higher cost to registering URI scheme to registering content type. Registration process same for URI schemes and MIME types in IETF space.
CL: It's worth saying to not register new schemes that aliases and existing scheme.
IJ: I would move the first bullet to section on opacity.
DC: There is a choice to be made about when to register a new mime type and when to register a URI scheme. Proposed deleting from "If the motivation " through Editor's note.
IJ: I intend to keep the first bullet but move it.
TBL: I'd like to keep the list and add:
  1. Don't invent a new protocol when one exists that gets the job done. You'd have to replicate the caching structure, and the social behavior.
  2. Cost of reinventing something is that you often make the same mistakes.
RF: I agree with these points, but they belong in the section on protocols.
TBray: I agree.
[DanCon]
(I'm scanning the issues list... tim's comments about re-inventing HTTP are issue HTTPSubstrate-16; what's the status of that issue?)
[Ian]
TBL: Don't just remove text, leave a cross ref if you move it.
[DanCon]
(is issue 16 on our list of issues we intend to resolve for this last call?)
[Ian]
RF: Once you have a new protocol, you may want to say "you SHOULD have a new URI scheme for that protocol."
DC: There's a time and place for new uri schemes and new media types.
[DanCon]
items was a time for a new media type, not for a new URI scheme. but I'm not sure how to generalize
[Ian]
TBL: Don't create a new URI scheme if the properties of the identifiers and their relation to resources are covered by an existing scheme.
DC: I can tell when it's done wrong, but not sure I can write done the right thing.
PC: Even writing down the wrong thing is helpful.
DC: That's IJ's finding (from TB's blog)
[timbl]
If the properties of the space addressed (the set of things identifiable and their relationship with the identifiers) is essentially the same as any existing space, that space should be used.
[Ian]
TB, DC: Delete first bullet "The more resource metadata is included in a URI, the more fragile the URI becomes (e.g., sensitive to changes in representation). Designers should choose URI schemes that allow them to keep their options open."
Resolved: Delete "Reasons for this include" through bulleted list.
2.3. URI Authority
DC: I would have expected third paragraph in section 3.
[timbl]
The owner of a URI defines what it identifies. The web protocols allow the owner to run and control a server which provides representation, and so when such a representation has been retrieved it is reasonable to take it as authoritative.
[Ian]
TBL: There is a place here to say that, because the protocols allow the URI owner to control the server, since you have protocols, it's reasonable to hold the resource owner accountable for the representations.
TBray: I note move from "authority" to "responsibility"
[DanCon]
I could live without this section.
[Ian]
IJ: Point was to introduce authority in assignment of URIs. Later authority of producing representations.
Resolved: Delete 2.3, moving paragraphs 3 and 4 to section 3 of the document.
PC: Ensure that unused refs are deleted.
2.4. Fragment Identifiers
TBL: I think in the second paragraph that "reference to" and "with respect to" are insufficiently clear.
[We note that that text is from RFC2396bis]
TBray: I think that "with respect to that resource" is incorrect. "Additional information that is interpreted in the context of that representation."
RF: It's with respect to the *Resource*, across all representations.
Question: Does "foo#author" mean that "author" has to mean that this is the author of the primary resource? One could read it that way.
DC: I agree that "named in" works better.
TBray: So we are asserting that the frag id is interpreted w.r.t. the resource.
DC: We are observing that, yes. There are bugs and other weird things out there, but they are wrong.
TBL: If you dereference a URI and get a representation back, and you know the media type, and you know the frag id semantics, then you know what is identified by the frag id. That doesn't mean that the frag id doesn't have meaning if you don't dereference the URI.
RF: change "that is merely named with respect to the primary resource." to "named by the primary resource."
[Norm]
"The fragment identifier component of a URI allows indirect identification of a secondary resource, by reference to a primary
resource and additional identifying information that is named by that resource. The identified secondary resource may be some portion or subset of the primary resource, some view on representations of the primary resource, or some other resource that is merely named by the primary resource.
[Chris]
RF: delete next paragraph
'Although the generic URI syntax allows ...'
NW: see above, did we agree to this
TBL: no not really
[Norm]
"The fragment identifier component of a URI allows indirect identification of a secondary resource by reference to a primary resource and additional identifying information that is named in that resource. The identified secondary resource may be some portion or subset of the primary resource, some view on representations of the primary resource, or some other resource that is merely named by the primary resource. The fragment identifier component of a URI allows indirect identification of a secondary resource by reference to a primary resource and additional identifying information. The identified secondary resource may be some portion or subset of the primary resource, some view on representations of the primary resource, or some other resource."
[timbl]
When an information resource has a URI and has a representation; and in the language of that representation a given string identifies a second resource, then the concatenation of the URI, a hash mark and the string form a URI for that second resource.
[DanCon]
hmm... I wonder if we came up with any good text when we worked in the wiki http://esw.w3.org/topic/AsUsedIn
[Chris]
It needs to tie it back to the resource fetched. Lets avoid 'concatenation'
[Norm]
yes, please!
[DanCon]
Why avoid 'concatenation'? that's what one does with #, no?
[Chris]
Actually no, you split it off, stuff it in your back pocket, and then use it in isolation on what you got back
[DanCon]
hmm... ok, concat/split, same difference
[Chris]
No, pretty much opposites
[DanCon]
I.e., same situation, 2 different ways to describe it. if long=concat(short1, short2), then short1=split(short2 from long)
[Ian]
[TBL draws diagram on board showing splitting URI into frag id and URI-with-no-frag-id.]
IJ: It occurs to me we ought to re-use the initial diagram several times, successively elaborating it. E.g., when we talk about what a representation is, show the "Representation" piece as including metadata and data.
URI-with-hash IDENTIFIES Resource2
URI-with-no-hash IDENTIFIES Resource1
NW: I want to confirm that "#foo" means the same thing in all representations and if it doesn't it's a bug.
DC: Yes, I agree.
TBL: Not exactly. It can be reasonable to give back to types of things depending on the format returned (e.g., bank statement or HTML document that's kind of equivalent).
[DanCon]
(this is an issue on our list too...)
[Ian]
TBray: But they are functionally equivalent w.r.t. the user.
[DaveO]
Dan, you mean frag-id issue #28?
[Ian]
NW: Is it architecturally unsound to serve a format with content negotiation that does not define frag id semantics (e.g., serve HTML and PDF)?
TBL: Browsers should say "There's no frag id".
DC: This is a silent recovery from error today.
CL: Are we saying it's an error to serve foo#bar if one representation doesn't define frag id semantics?
TBray: Not a server problem, but an authoring problem.
[Chris]
conneg and fragments considered incompatible
[timbl]
When an information resource has a URI and has a representation; and in the language of that representation a given string identifies a second resource, then the concatenation of the URI, a hash mark and the string forms a URI for that second resource. The MIME type registration defines this syntax and semantics of such a string.
[Ian]
See 2.4.1 for this discussion...
TBray: TBL means that the format spec defines the semantics of what the frag id is used for.
DC: I think it's easier to talk about splitting a URI rather than concatenating two parts.
TBray: Superfluous to say "info resource" since that's the kind that has representations.
[TBray]
When a resource has a representation...
[timbl]
When a resource has a URI and has a representation; and in the language of that representation (using a syntax and semantics defined by the MIME type specification) a given string identifies a second resource, then the concatenation of the URI, a hash mark and the string forms a URI for that second resource.
[DanCon]
SIGH.
[Ian]
DC: I thought we were going to use the term information resource that we introduced earlier.
RF: I think that the existing text in RFC2396 is superior to TBL's proposal.
DC: I agree that the second para (i.e,. existing text in arch doc) is better.
RF: I think it's important to be able to define a resource with a URI that includes a frag id without having to get back a representation.
[Norm]
How is this: "The fragment identifier component of a URI allows indirect identification of a secondary resource by reference to a primary resource and additional identifying information. The identified secondary resource may be some portion or subset of the primary resource, some view on representations of the primary resource, or some other resource. The URI that identifies the secondary resource consists of the URI of the primary resource with the additional identifying information as a fragment identifier."
[Ian]
[Discussion of "selective with respect to that resource"]
RF: How about "that is defined by that resource" instead? The MIME type is not significant here.
DC: I think RF's current text is good, and we could also include TBL's paragraph
TBray: Can we lose the word "merely"?
DC: I am ok with Norm text, but on condition that it go into 2396bis.
TBray: I think NW's second .proposal is better than TBL's:
[Zakim]
Chris, you wanted to tak about delegated authority and fragments
[Ian]
CL: You don't get to fiddle around with URIs. You do, however, get to fiddle with the fragment.
[DanCon]
hmm... I hear a point that chris is making... but I'm not sure how to put it into an economical number of words
[DaveO]
Norm, I don't understand your earlier question about #foo meaning the same thing. If WSDL defines #foo to mean an abstract component *thing*, and SVG defines #foo to mean an xml element with name foo, then they don't have the same meaning.
[Ian]
I also think that xpointer lets you create anchors outside the original document. So person A can create anchor in person B's representation
[DanCon]
so DaveO, don't make SVG and WSDL representations that use 'foo' available for the same resources
[Zakim]
timbl, you wanted to bzzzzzzzzzzzzzzzt vague alarm
[Ian]
TBL: I find NW's alternative is still vague. If you include my paragraph after it, I will be happy.
[Roy]
This is what the URI spec also says:
[Chris]
dave - svg defines barename #foo to mean the xml thing because its a +xml media type
[Ian]
TBL: In particular, it's important to see how URIs are the same; and how to proceed with frag id.
[DanCon]
(stuart/ian, did we agree to include the figure from the whiteboard?)
[Ian]
Chris has action to do image revision. I'd like CL to do a version of what's on board, too
[Chris]
dan - I believe we did and i will draw that one, too
[Ian]
Action CL: Create an illustration of two resources, one designated by URI without fragment, and one designated by same URI with fragment.
Proposed: Include TBL para after existing para from 2396.
TBray: I prefer NW's text to that in 2396
TBray: I accept DC's caveat.
Resolved: Accept NW's second proposed text and TBL's text.
[timbl]
Wheas human communication tolerates such ambiguity, machine processing does not.
[Ian]
[Discussion of whether Director should say ok to advance of a spec to PR (or PER) if mime type not registered.]
IJ: See Guidebook resource "How to Register a Media Type with IANA (for the IETF tree)." Does this need updating?
DC: I'm likely to delete this since may not be maintained; better to have no info than incorrect info.
[Chris]
minimally yes as it speaks of the ietf tree, should be standards tree. DanC mentioned email, no ID required
[timbl]
Suggested text for 2.6: "Whereas human communication tolerates such ambiguity, machine processing does not. Strictly, the above URI as identifies the information resource, some hypertext document. RDF applications which use it for describing properties of that page are in order; those who use its URL to directly assert properties of the whale are using it inconsistently".
Discussion of "Although the generic URI syntax allows any URI to end with a fragment identifier, some URI schemes do not specify the use of fragment identifiers. For instance, fragment identifier usage is not specified for MAILTO URIs."
RF: This is orthogonal to the URI scheme.
TBray: It's not the scheme, it's the data formats.
Resolved: Delete "Although the generic URI syntax allows any URI to end with a fragment identifier, some URI schemes do not specify the use of fragment identifiers. For instance, fragment identifier usage is not specified for MAILTO URIs."
TBray: Please see if you can either delete 2.4.1 heading or find a second heading for 2.4
[Chris]
>>>>>>>>>> http://www.w3.org/2001/tag/webarch/#dereference-uri <<<<<<<<<<
[Ian]
NW: Change in 2.4.1 "Clients should not be expected to so something..." to "It is an error..."
TBray: "It is an error condition when you have a URI with a frag id and representations don't have consistent frag id semantics..."
RF: You need to be careful: The error is not creating the identifier. You may tolerate the error in some cases. Good practice note is wrong: "Authors SHOULD NOT use HTTP content negotiation for different media types that have incompatible fragment identifier semantics."
TBray: "In the case where you use conneg to serve multiple representations, and some of those representations have inconsistent frag id semantics, then you are creating an opportunity for this error to occur."
[DanCon]
yes, pls strike the good practice box and replace with words ala what Bray just said
[Chris]
or, clarify the good practice note ... but can live with tim brays text
[DanCon]
NW: yup
[Ian]
Proposed: Revise good practice note with spirit of what TB said.
TBL: I'm ok with TB's text.
Resolved: Revise good practice note with spirit of what TB said.
[DanCon]
misuse from 3.3: "The simplest way to achieve this is for the namespace name to be an HTTP URI which may be dereferenced to access this material."
[Ian]
[Discussion of "dereference" v. "retrieve"]
[DanCon]
I like 'access' and I can live with 'retrieve' and I'd like to avoid 'dereference' if we can.
[Ian]
DO: Please include examples in 2.5.
TBray: I like "access" as well.
[Chris]
dereference is used in 2.2. URI Schemes as well
Furthermore, the URI scheme specification specifies how an agent can dereference the URI.
+1 for access
[Ian]
TBray: I suggest deleting "Given a URI, a system may attempt to perform a variety of operations on the resource, as might be characterized by such words as "access", "update", "replace", or "find attributes". Available operations depend on the formats and protocols that make use of URIs. "
[timbl]
To dereference a URI is access the resource which it identifies.
[Chris]
dereference is not retrieval
[timbl]
(Not necessarily, that is)
[DanCon]
1. rename to accessing a resource
[Ian]
Proposed: Delete "Given a URI, a system may attempt to perform a variety of operations on the resource, as might be characterized by such words as "access", "update", "replace", or "find attributes". Available operations depend on the formats and protocols that make use of URIs. " and "Accessing a resource" and slightly rewriting third sentence
+1: DC, TB, CL, IJ
Resolved: Delete "Given a URI, a system may attempt to perform a variety of operations on the resource, as might be characterized by such words as "access", "update", "replace", or "find attributes". Available operations depend on the formats and protocols that make use of URIs. " and "Accessing a resource" and slightly rewriting third sentence
DC: In 2.8.4, I prefer "access' over "resolution"
TBL: I think we can delete "resolution" from the document. Use "access" instead.
NW: Delete "finite" from 2.5
[DanCon]
if you're gonna strike finite, you might as well strike 'set'.
[Ian]
"While accessing a resource..."
Resolved: Delete resolution from document (replace with access where necessary).
2.5.1. Retrieving a Representation
[Chris]
Some URI schemes (e.g., the URN scheme [RFC 2141]) do not define dereference mechanisms.
is it tru (yes apparently) and does it contribute anything useful
okay, chris lets it slide
[Ian]
2.5.1. Retrieving a Representation
TBray: Potentially misleading - " The representations communicate the state of the resource." Representation doesn't need to represent ENTIRE state of resource.
TBL: "Some or all of the state of the resource...."
[DanCon]
Ed note: "As stated above" as a consequence of decisions we made recently.
[Ian]
Resolved: "communicate some or all of the state of the resource."
[Chris]
"is used within an a element " is vague
[Ian]
SW: Change "which representations are used" to "which content types".
DC, TB: No.
TBray: A server can throw your PUT on the floor.l
[Chris]
suggest 'is the value of an href attribute in the xlink namespace on an a element
[Ian]
DO: This section is about retrieving a representation.
SW: Comment withdrawn.
[TBray]
note that the "As stated above" reference no longer works since we nuked that section
[Ian]
RF: This good practice note is out of place: "Owners of important resources SHOULD make available representations that describe those resources."
[timbl]
Note now dead link on "authority responsible for a URI"
s/that describe those/of those/
[Ian]
Change to "Resource representations: Owners of important resources SHOULD make available representations of those resource."?
RF: I think that moves away from original intent: I think it was that owners should provide metadata.
DC: No, it was about not filling the Web with 404s. Drill in this good practice Note by giving a 404 example. And show that that sucks.
[Zakim]
Chris, you wanted to say just that and to say that "the SVG specification suggests " is weak, too
[DanCon]
22:42:22 [Chris]
suggest 'is the value of an href attribute in the xlink namespace on an a element
[Ian]
IJ: Nowhere does the SVG spec say "GET".
[Chris]

From http://www.w3.org/TR/SVG11/linking.html#Links "SVG provides an 'a' element, analogous to HTML's 'a' element, to indicate links (also known as hyperlinks or Web links). SVG uses XLink ([XLink]) for all link definitions." It's the xlink href in the context of the a element and the other attributes on the a element that imply

[Zakim]
timbl, you wanted to say s/that describe those/of those/ and to
[Chris]
xlink:show = 'new | replace'
Indicates whether, upon activation of the link, traversing to the ending resource should load it in a new window, frame, pane, or other relevant presentation context or load it in the same window, frame, pane, or other relevant presentation context in which the starting resource was loaded.
[Zakim]
DaveO, you wanted to mention representations retrieved by other methods than GET
[Chris]
Action CL: Tighten this language for SVG 1.2
[Ian]
DO: What do we say about POST - result of POST operation is a representation (or some data).
TBL: That's not a representation of any resource.
DO: Yes, it is, I can give it a content location.
TBray: Question, e.g., of, after an update, getting a mere 200 or getting updated text (i.e., representation).
[Chris]
"By activating these links (by clicking with the mouse, through keyboard input, and voice commands), users may visit these resources." is vague and wooly
[Ian]
[Discussion of HTML forms]
DC: I disagree that what is POSTed is a representation of the resource.
[Chris]
prefer sections 1 and 2 bring in the other context (element name, attributes)
[Ian]
(yes)
[Chris]
I.e., it is not just the occurrence of a bare URI on some random element that makes it be a hyperlink
[Ian]
[Agreement on "form data"]
DO: I send form data to the server. Is what I get back a representation?
[Chris]
Action Ian, Chris: Discuss and propose improved wording of language regarding SVG spec in bulleted list in 2.5.1.
[Ian]
DC: No, it's not a representation.
RF: It is a representation. It's a representation of the response that you get back.
DC: It's not a representation of any thing the common specs give a name to.
[DaveO]
I want to make sure that we say that POST results are NOT retrieval operations.
[Chris]
post result is not a retrieval action
[Ian]
RF: An HTTP POST is not a retrieval action.
[Zakim]
Chris, you wanted to say I believe we already agreed to this - that access is not the same ars retrieval
[timbl]
An HTTP POST is not a retrieval action. Any resulting response is NOT a representation of the URI posted to.
[Stuart]
if the result includes a Location header, is the result a representation of the resource referenced by the location header?
[DanCon]
yes, let's use POST as an example to distinguish access from retrieval
[Ian]
Action IJ: Include POST (and other methods) as examples of deref methods at beginning of 2.5
[DaveO]
stuart, I don't think a POST that "happens" to contain a Location is a "retrieval". It's a deref, that could be followed by a retrieval on the Location URI.
[Chris]
in other words, make a positive statement that non-retrieval access is both possible and good if appropriate
some non-HTTP examples would be good, too
[Ian]
Delete editor's note in 2.5.1 since "on the web" handled earlier per today's discussion.
2.5.2. Safe Interaction
[Minor editorial only]
2.6. URI Persistence
Resolved: Delete "draft" before "TAG findings" globally.
DC: "Similarly, one should not use the same URI to refer to a person and to that person's mailbox." If you ask Mark Baker are you your mailbox, he'd say yes.
TBL: "Whereas human communication tolerates such ambiguity, machine processing does not. Strictly, the above URI as identifies the information resource, some hypertext document. RDF applications which use it for describing properties of that page are in order; those who use its URL to directly assert properties of the whale are using it inconsistently."
TBL: s/URI persistence also/It is an error for a URI to identify two different things.
DC: No.
TBray: What about retitleing section "Maximizing the usefulness of URIs"
[Chris]
2.6. URI Persistence > new title
subsections persistence, ambiguity, reliability
[Ian]
"URI Persistence and Ambiguity"
RF: Are all uses of URIs for the sake of identification?
TBL: Yes.
RF: Identification of what?
RF: What about using a URI in a sentence as an indirect identifier: "I wonder whose home page is http://www.example.com/"
TBL: The URI refers to the home page... I have a problem with sentence starting "For instance...."
[Stuart]
see http://lists.w3.org/Archives/Public/www-tag/2003Jul/0102.html
[Ian]
DC: "Whoever publishes the URI should be clear about whether it identifies the book, the whale, etc."
TBL: I don't like that in this case. I don't want them to say it's a whale.
[DanCon]
DC: whale? yeah... take out the whale.
[Ian]
TBray: In TBL's proposed paragraph, I disagree with a lot and don't understand some points.
[Chris]
proposed addition makes invalid assertions. Some machines tolerate ambiguity very well
[Ian]
TBray: I don't agree with a straight assertion that machines don't tolerate ambiguity.
NW: People will make conflicting assertions. The system will have to deal with this. I'm satisfied with existing text.
TBL: I think our concern is not the ambiguity of "Moby Dick" it's the inconsistent uses of the URI.
[DanCon]
I'm not too happy with the moby paragraph.
[Ian]
TBray: When you mint a URI you need to be clear about what it identifies. Remove the quotes...
DC: I'd like a positive statement about what to do.
[DanCon]
and strike whale
[Norm]
I don't see any reason to strike whale
[Zakim]
timbl, you wanted to say that anything which goes in this document should be consistent with HTTP resources being information resources
[Ian]
TBL: I don't want to say that the URI designates whatever the URI owner wants.
[DanCon]
tim's correct that this para, as written, takes a position on httpRange-14.
[Ian]
NW: Could I not write an RDF assertion that says that this URI identifies the while, then another assertion that conflicts with that?
TBL: Yes.
NW: Why is this special case so important?
TBL: Important axiom for version 2 of the arch doc - referent of an HTTP resource without a hash is an information resource.
NW: RF's the standards that we write for the sake of identification is orthogonal to the systems that make use of them.
[timbl]
Tim;'s comments was not about th doc, about dan's proposal
[Ian]
PC: May need, for forward compatibility, to ensure that something is an error in V1 though might be more meaningful in V2 of arch doc.
[Norm]
And it's too late already. The cat is out of the bag.
[Ian]
PC: Need to include a warning at least to users.
[DanCon]
hmm... a health-warning about httpRange-14 is an interesting idea.
[Ian]
PC: Do we put something in arch doc v1 that is warning that we say "Don't do this; we think that there are arch reasons to use this form for explicit meaning and we haven't yet defined that."
RF: You can replace the URI with a URN...
DC: Or put a hash and frag id in it. If you ask most people if something is a whale, and people can put it in their browser, they're likely to say "Nope, that's not a whale."
[Zakim]
DanCon, you wanted to note that timbl's axiom may be more widely accepted than norm suggested
[Ian]
NW: That argument suggests that if there's a hash mark at the end of a URI and it takes them to the middle of a document, then it's not a whale either.
TBL: If it's a hypertext document, it's never a whale.
NW: So I can't serve up with conneg a hypertext doc that describes an RDF vocab and the RDF vocab.
DC: Right.
DC: That seems problematic; and we discussed that earlier.
[DanCon]
... in the case of WSDL and HTML
[Ian]
TBray: I would be ok with taking "whale" out of the sentence. I'm still not convinced of TBL's axiom.
[DaveO]
Dan's right, same thing with namespacename#WSDLFrag-ID and the collision between RDDL vs WSDL representations at the namespace URI.
[Ian]
RF: Just change the scheme name...
[DanCon]
... too foo: ... something unregistered
[Ian]
TBray: What about "Melville#moby"
Action TBL: Propose a replacement to "URI persistence ...person's mailbox".
[TAG accepts risk that continuing walkthrough puts other agenda items at risk.]
2.7. Access Control
[Chris]
http://www.heise.de/newsticker/data/tig-18.07.03-000/
http://juris.bundesgerichtshof.de/cgi-bin/rechtsprechung/document.py?Gericht=bgh&Sort=3&Datum=2003&Art=pm&client=3&Blank=1&nr=26553&id=1058517255.04
[Ian]
[German govt ruling in favor of permissability of deep linking]
CL: TAG could update its finding to include a link to this.
[TBray]
Typo: two quotes before the word Deep ("')
[Ian]
Action IJ: Update Deep linking finding (new revision) with reference to this decision. No additional review required since just an external reference.
2.8. Future Directions for Identifiers
[DanCon]
ed: 2.8 has no text before 2.8.1
[Ian]
2.8.2. Determination that two URIs identify the same resource
TBray: Pay Hayes says we're wrong on this.
[Chris]
2.8.1 no-one had any objections to the text
[Ian]
DC: I disagree with him.
2.8.3. Consistency of fragment identifier semantics among different media types
[Chris]
2.8.3 first para on automagic fragment conversion is hazy and likely not possible in general
suggest dropping it
[Ian]
TBL: There was discussion in HTTP community about putting frag id in headers.
Resolved: Delete "There has been some discussion but no agreement that new access protocols should provide a means to convert fragment identifiers according to media type."
[Chris]
2.8.3 in entirety hits the dust
[Ian]
Delete 2.8.3, distributing refs to issues elsewhere.
Action DC: Include pointers in 2.8.5 to such systems (e.g., freenet).
[Chris]
2.8.5 needs more clarity and pointers
[Ian]
Action IJ: Add text to 2.8 before 2.8.1 giving context (e.g., work going on in community, no guarantee that TAG will do this work)
TBray: This is a survey of the landscape; not a commitment to actions.
PC: And do this in 2, 3, 4.

23 July (Architecture Document continued)

Start by looking at some rewritten text by TBL.

[IanYVR]

Section 2.6 of rewritten text by TBL
TBL: I think that we need to make "URI Ambiguity is the use of the same URI to refer to more than one distinct thing. It should be avoided." a point if it's to be included.
Action TBL: Continue to revise section 2.6 in http://www.w3.org/2001/tag/webarch/tim

Returning to section 3 of 16 July Editor's Draft

3. Representations
RF: Delete "(see the section on interactions for information about message protocols)" since not there yet...
DO: I would like us to clarify relationship between messages and representations and how agents use them.
TBray: Please write a story showing relationship between messages and representations.
[Discussion of messages and their relation to section 3]
[DanCon]
(Dave, did you say section 3 as written mixes up representations and messages? where?)
[Chris]
(message bodies and their relation to representations)
[DanCon]
that=??
[Chris]
(especially as we have representations = bits + metadata)
[Zakim]
Chris, you wanted to quibble slightly about point 5 in 3.0 and to worry about "3. The representation consists those bits that would not change regardless of the transfer protocol used to exchange them. and to note objection and to note a dissent on record to "User agents must not silently ignore authoritative server metadata. and to request clarification on "3.2 and semantics"
[timbl]
We need to be clear on the relationship between messages and representations now, even though we will do messages in section 4.
[DaveO]
Dan, I sent in email on describing the relationship between messages and representations a while ago..
[IanYVR]
TBray: I think it's a good idea to continue the story with a GET lookup (a msg), you get a response, you do a POST (with data that is not a representation of the URI you posted to).
[DanCon]
Does it say which text in section 3 mixes up the concepts, daveo?
[IanYVR]
TBray: I volunteer to write the story.
IJ: I think belongs in section 4 (too detailed if up front)
DO: In section 3, we want to talk about formats, but we use messages to do stuff. There is more in the message than just representations. Perhaps we have the order of 3 and 4 wrong.
RF: I agree.
[Zakim]
DanCon, you wanted to suggest removing discussion of messages from section 3 on Representations; if we need to elaborate the stub in section 4 to make things clear, so be it
[timbl]
TBL, CL: +1 to switching sections 3 and 4.
[IanYVR]
DC: I suggest moving stuff on msgs out of 3 to section 4.
[IanYVR]
Action TB: Continue Oaxaca story for beginning of section on messages, showing GET (with details) and POST (with details).
Resolved: Swap sections 3 and 4.
SW: "A representation is data that represents or describes the state of a resource."
[DanCon]
+1
[IanYVR]
SW: Are "represents" and "describes" synonymous? If not pick one.
[timbl]
No
[IanYVR]
IJ: "The representation of the state of a resource consists of ...."
[DanCon]
IJ: we already got rid of "describes a resource" earlier
[ndw]
introduces ambiguity and should be avoided. "For example, suppose one part of an enterprise collects information
about web pages including who created them and when. It is natural to identify the web pages with their URI. Suppose further that another
part of the enterprise collects information about companies, including who created them and when. If the same URIs are used to identify the
companies, ambiguity is introduced. A system that attempts to merge these two distinct data sets is likely to encounter problems distinguishing between the creators and creation times of the companies and the web pages. One way to compensate for this ambiguity is with indirect
identification. Rather than identifying companies, for example, by the URIs of their home pages, identify them indirectly. Example
Corporation is not http://www.example.com/, it is the company with the home page http://www.example.com/."
[Chris]
this is a multipart question.
[IanYVR]
[There is support for IJ's reproposed first sentence"]
[DaveO]
See my comments on 16 July draft.
[IanYVR]
CL: "The representation consists those bits that would not change regardless of the transfer protocol used to exchange them."
RF: The information doesn't change. On the wire is a message. The representation is within the message body.
[DanCon]
I don't see how past tense helps.
[IanYVR]
TBray: Representation data/metadata is independent of the protocol that was used to exchange it.
[Chris]
+1 for tbray wording
[IanYVR]
DO: Difference between abstract state of representation and actual bits needs to be clarified.
RF: You're mixing two different things. The representation IS the bits.
[TBray]
ach DaveO
[IanYVR]
TBray: The representation is a bag of bits. The bag of bits that gets sent is the same that gets sent whatever the protocol.
TBL: Please state this positively instead of negatively.
IJ: I don't think "past tense" helps.
[timbl]
Negative: The representation consists those bits that would not change regardless of the transfer protocol used to exchange them.
[Chris]
Action CL: Ensure that SVG is clear on CE vs CTE
[Zakim]
DanCon, you wanted to suggest removing stuff about messages from section 3 and to suggest spelling out the gzip case, but in section 4
[IanYVR]
"Representation data/metadata is independent of the protocol used to exchange it (e.g., of gzip)"
DC: Move "When agents....to exchange them."
TBray: Show point about representation bits being independent of messages using gzip example.
[DanCon]
+1 to what tbray said
[Zakim]
timbl, you wanted to The representation contains information about the content, and the interpretation of the concept. (Representations can be included in messages [see section 4] but in that case the representation is not considered to include the message).
[IanYVR]
TBL: Don't define representation in terms of subtracting from one particular use (namely messages).
SW: Change "bag of bits" to something else.
TBL: "Sequence of octets". In short, get rid of "The representation consists those bits that would not change regardless of the transfer protocol used to exchange them." since this defines in terms of subtraction.
[Discussion about layering]
TBray: At this level we make clear that representation is a sequence of octets.
CL: Please make clear when you change abstraction layer from sequence of octets to higher up.
[Chris]
ok, happy once we agree to clearly signal any layer changes in course of section 3
[TBray]
Say it now and say it loud, I'm a PEDANT and I'm proud!
[IanYVR]
TBL: What am I looking at when I do view source of an email message?
RF: You're looking at the message source.
[Chris]
timbl reads out a sequence of characters
[IanYVR]
RF: I think it's worth making distinction between msg metadata and representation data.
IJ: Three terms: msg metadata, representation metadata, representation data.
DO: I am bothered by definition of "representation" including metadata about the data.
TBL: Formally, the JPEG bits, you can't use unless you have metadata as well.
[DanCon]
RF: Does the meaning of a message change if you change just the media type? yes.
... hence media type is part of representation
[IanYVR]
CL: Point 5 of numbered list: "When Dan made the request. Since the weather in Oaxaca changes, Dan should expect that representations will change over time."
[DaveO]
We should give that same example/analogy in our document
[DanCon]
Bray: I'll try to make that point about why media type is part of representation in the story... jpeg of sky...
[IanYVR]
CL: Link back to section on consistency of representations from bullet 5.
[DaveO]
thanks tim..
[IanYVR]
3.1. Authoritative representation metadata
CL: Please also point out at end of 3.1 that servers should not make up metadata when they are not sure. I'd like to elevate "inconsistency". Say that IT IS BAD. There are interoperability (serious) issues.
[Zakim]
Chris, you wanted to request back ref from point 5 to consistency
[Chris]
maybe 'don't cause errors silently' as well ;-)
[IanYVR]
IJ: Where do we say "Don't recover from errors silently." ?
DC: When you are designing anything....
TBray: I think it's appropriate to say in detail in each section.
Tim Bray, could you include the point about not recovering from error silently in your story?
[DanCon]
Bray: say "silent recovery from errors considered harmful" as many times as it comes up in the document.
DC: ok.
[TBray]
no, probably not
[IanYVR]
TBL: In "there may be inconsistencies", don't use "may" since it seems to allow it.
RF: In 3.1, "As discussed above, the owner of a resource "... this is referring to authority, which we removed yesterday.
TBray: Just delete "As discussed above".
RF: In first bullet of 3.1, delete "Unicode" and "(XML Document)". Both bullet points in 3.1 should refer to representations, not message bodies.
[DanCon]
I wonder if "encoding" is sorta backwards; one encodes a sequence of characters into the sequence of bytes.
[IanYVR]
TBray: "The actual encoding of the representation data is inconsistent with the character encoding of the representation metadata."
[Chris]
no
[IanYVR]
TBray: "The actual character encoding of the representation data is inconsistent with the character encoding specified by the representation metadata."
[TBray]
The actual character encoding of the representation is inconsistent with the charset parameter in the message headers.
[Chris]
no 2
yes to tim bray
except for message
[IanYVR]
The actual character encoding of the representation is inconsistent with the charset parameter [in the representation metadata].
[Chris]
in the representation metadata
[DanCon]
hmm... "Representations and Formats" would be a better section title, for me.
[Zakim]
timbl, you wanted to point out "format" is used here in the sense of "MIME Type".
[IanYVR]
TBray: "Format" is used in the sense of MIME type.
[Chris]
ok so we need to edit this sentence in 3.0
"The Internet Media Type is the key to the correct interpretation of a resource representation, and governs the handling of fragment identifiers. "
timbl, that sentence is where your clarification should go, i believe
[DanCon]
RF: "Content-Type" is a header field. always. "media type" is the value inside the content type header. 'mime type' is passe. 'media type' is the modern thing
[timbl]
Chris, that sentence does not mention the word "format".
[Chris]
format is defined in the content type
[DanCon]
Bray: we should point that terminology out
[IanYVR]
TBray: Include a footnote with example, to clarify content type, media type
[DanCon]
IJ: yeah... a footnote or some such
[IanYVR]
(and mime type)
[Chris]
timbl, from the context, that is where you should add it
[DanCon]
Ian: should we use format in some meaning distinct from internet media type?
[IanYVR]
TBL: I'd like you to tie "format" and "media type" irrevocably together in the document.
[DanCon]
TimBL: no, please connect 'format' with 'internet media type' firmly
[IanYVR]
TBL: "Is the key to" is a fudge phrase.
IJ: I think "format specification" is useful.
[DanCon]
TimBL: let's keep 'format'
[Zakim]
Chris, you wanted to discuss in 3.2 "There SHOULD be a normative specification which is a stable and widely available Web resource. "
[DanCon]
Chris: let's either change to MAY or give some exceptions
[Zakim]
Roy, you wanted to make comments on section 3.2
[IanYVR]
RF: Last three bullets have nothing to do with interoperability. Put them somewhere else.
TBray: I think bullet 5 could stay there.
RF: I just think we have other places to say these last three things.
TBray: I suggest moving bullet 4 to linking. Move bullet 5 to section 2.
[Chris]
move to 3.2.1
[IanYVR]
TBray: Move 5 and 6 to linking section below, in 3.2.4. Maybe not bullet 6...
IJ: Should I make first three bullets good practice notes.
TBray: Move 4, 5 to 3.2.4. Make them good practice notes as well. Move bullet 6 to section on XML.
[Agreement]
[DanCon]
yes, pls
[Zakim]
DanCon, you wanted to ask what the editor expects to do with the 'format' term
[Chris]
ij: timbl would like format and media type to be wedded for eternity. Plan to talk about xml as a format representation
[timbl]
"format" must be introduced as being used in the sense of "Internet Media Type"
[IanYVR]
DC: Please bold "format" when connected to internet media type
[Zakim]
DaveO, you wanted to mention his comments on extensibility and versioning for shoulds of format specifications. and to ask that formats, languages, documents, representations be connected.
[timbl]
Resolved:"format" must be introduced as a <defn> as being used in the sense of "Internet Media Type"
[DanCon]
wow... extensibility is the main architectural issue about representations, for my money. +1 to DaveO
[Zakim]
timbl, you wanted to edit the qnames line
[IanYVR]
Resolved: Create new section 3.2.1 for first three bullets on the use of standards.
[Zakim]
TBray, you wanted to grumble about 3.2.1
[IanYVR]
3.2.1. Desirable Characteristics of Format Specifications
[DanCon]
-1 to bray; our customer base includes authors
[IanYVR]
TBray: Lose user/author points Add I18N
[Zakim]
Chris, you wanted to grumble about the level of nesting producing 3.2.2.1. Binary v. Textual and to disagree with timbray on wat he just said about usability and authoring
[IanYVR]
CL: Can we flatten the toc, please? I disagree about removing user, author needs.
[DanCon]
chris, which is the fundamental thing of the web per bos?
[Zakim]
DanCon, you wanted to endorse having a subsection on extensibility
[IanYVR]
DC: For my issue, extensibility is the main arch point.
[Chris]
please make them point to further reading eg on simplicity of authoring (see Bert Bos writings on subject) and user needs (see Steven pemberton essays)
[IanYVR]
TBL: "Further light reading"
[Zakim]
DaveO, you wanted to ask that formats, languages, vocabularies, media types, representations, messages, documents be clarified, related, diagramed.
[IanYVR]
IJ: My proposal was to delete author/programmer/user needs and point to other resources.
DO: Try to reduce number of terms, and diagram how they are related.
[DanCon]
the heading "3.2.1. Desirable Characteristics of Format Specifications" could go, for me. promote the things under it or something. (just a suggestion)
thx for the pointer, chris.
... but the pointer has gone 404
[IanYVR]
TBray: I think "vocabulary" is ok to refer to a set of tags.
TBL: It's used in RDF as well (set of props and classes).
[DanCon]
er.. no, not 404, but some weird javascript redirect to http://www.w3.org/2002/Talks/1104-usability-workshop/
[Chris]
right - why is 3.2.1. Desirable Characteristics third level but 3.3. XML-Based Representations is second level
[IanYVR]
There is agreement that we need to be careful when we use terms.
IJ: I think that a series of diagrams better than one to show all term relationships.
DO: I think that we have two types of diagrams.
[DanCon]
of course diagrams are high-cost, TBray; do you discount their value?
[Chris]
chris puts high value on diagrams
[DanCon]
(I don't think the layer cake is a particularly good success story in diagrams. it confuses as much as it clarifies)
[IanYVR]
TBL: Don't confuse what makes a good format and what makes a good spec. The message is "be aware of the different audiences of your specification"
[DaveO]
Ian, my comments are really: reduce the number of terms, rigorously define the terms AND the formal relationship between the terms, and show the appropriate relationships in diagram form.
[Stuart]
+1 to DaveO
[DanCon]
daveo, any particular cases where we have more terms than we need?
[IanYVR]
TBL: Section 3.2.1 talks about both formats and specs. Please just focus on properties of specs.
TBray: But error handling and info hiding is really about the format.: Maybe that's a useful rhetorical technique.
[DaveO]
Dan, I think the relationship between format/language/vocabulary is confusing. Is somebody a format author, an language author and/or a vocabulary author?
[DanCon]
got it, dave
[IanYVR]
RF: In section on error-handling, please delete first sentence.
d/Given that representations are generated by humans (either coded directly or mediated by an authoring tool) and then transmitted in a heterogeneous network, it is inevitable that errors will occur.
[DaveO]
And how does a "specification" relate to a format? Are they the same? When are they different? Are they different aspects?
Is a specification a schema? Or is a schema a type of a document that makes up a specification?
[IanYVR]
A format specification defines a format. A protocol specification defines a protocol
[Agreement to delete sentence per RF's suggestion]
</break>
3.2.2. Taxonomic Categorization of Data Formats
3.2.2.2. Final-form v. Reusable
SW: Is comment about XSL-FO in para three a swipe?
TBray: No.
[Paul returns to meeting]
Reviewing "In general XML-based data formats are more re-usable and repurposable than the alternatives, although the example of XSL-FO shows that this is not an absolute."
3.2.2.1. Binary v. Textual
RF: "All things being equal (a rare state of affairs) textual formats are generally preferable to binary ones in Web applications." Please say for what.
CL: What about audio streaming?
TBray: Clearly that's a specialized situation. I firmly believe that if you are evaluating a design for a new format, you should arrange to do it in a text format if that can be done.
CL: How about "if you're choosing between a binary format and a textual format, and they are about the same size, then pick textual since there are lots of advantages"
[timbl]
Text-based formats are recommended when the amount of data is small, and inspectable for
[IanYVR]
TBray: It is advantageous for formats to be textual rather than binary.
TBL: However, text based formats have a large overhead for large datasets.
Resolved: Delete "All things being equal (a rare state of affairs) textual formats are generally preferable to binary ones in Web applications."
Action CL and TB: Propose a replacement sentence regarding advantages of text formats.
[Chris]
+1 to cl text above ;-)
[IanYVR]
Action IJ: Add link from issues list binaryXML-30 to upcoming workshop
[DanCon]
I invite somebody (Chris?) to notify www-tag about the workshop.
[IanYVR]
3.2.2.2. Final-form v. Reusable
[Zakim]
timbl, you wanted to say 3.2.2.2 needs a pointer to presentation vs content
[IanYVR]
TBL: "Final-form v. Reusable" is close to content v. presentation. We should at least link them if not merge them. And include a link to contentPresentation link. We may be confusing people by using new terms for old concepts.
RF: +1 to TBL's comment. Delete third para.
Resolved: Delete "In general XML-based data formats are more re-usable and repurposable than the alternatives, although the example of XSL-FO shows that this is not an absolute."
[Chris]
delete 3.2.2.2. Final-form v. Reusable
discuss in 3.2.3. Presentation, Content, and Interaction
[IanYVR]
Proposed:
- Merge 3.2.2.2 with content presentation stuff
- Elevant 3.2.2.1 and 3.2.2.3 to higher level.
[Zakim]
Chris, you wanted to link final form to 'means nothing' in sonpres-26
[Chris]
chris has said that already by now
[IanYVR]
3.2.2 binary v. textual
3.2.3 composable v. standalone
3.2.4 content v. presentation AND final-form v. reusable
[Zakim]
Roy, you wanted to talk about confusion of representation and web page in 3.2.2.3
[IanYVR]
3.2.2.3. Composable v. Standalone
RF: "it is not typically embedded in representations encoded in other formats." I don't understand what 3.2.2.3 is about.
DO: Container v. something that fits inside a container.
RF: Does this include issues like including non-xml in xml? SOAP header designed to fit inside a SOAP header. SOAP envelope provides container. Then there's the notion of something that fits inside a container v. something that can be outside on its own.
[Zakim]
timbl, you wanted to criticize "Composable" para 1
[IanYVR]
TBL: 3.2.2.3 as written is confused. Is "composability" about things that enclose or things that are enclosed?
PC: DO is right. The major feature of SOAP that distinguishes it from other formats is its extensibililty points: headers, body (and intermediaries). Major arch design of SOAP is its extensibility.
[Chris]
however, I do like composability as a term
[IanYVR]
RF: You can put images inside a PDF document.
TBray: And XML as well. I think that 3.2.2.3 is hopelessly muddled. Candidate for termination... "Composability" here is trying to do too much...
[Chris]
No, but listening to tim bray and willing to be convinced
[IanYVR]
TBray: Perhaps move some stuff to protocols on payloads and envelopes.
[Chris]
however payloads does not entirely cut it
[IanYVR]
CL: I'd like to keep composability.
[Zakim]
Chris, you wanted to note that PDF can enclose svg which can point to JPEG, nowadays
[IanYVR]
CL: Composability we have said generally is a good thing.
[Zakim]
DaveO, you wanted to say there are 3 concepts: standalone, containers, and container extensions
[Chris]
in particular, xml formats that discuss where they can contain other stuff and what happens when they are not the rootmost element, are good
[IanYVR]
DO: Raison d'etre of container is to have extensions. Clearly a standalone language could be a container as well (e.g., PDF).
CL: SMIL talks about host language
[Zakim]
Stuart, you wanted to ask whether any of the language of HTML modularisation is relevant eg host language
[Chris]
smil also talks of a host language
[IanYVR]
PC: Host only works one level up. (Caution about recursive hosting)
TBray: I think this issue is mostly about XML today.
DC: What about MIME?
CL: Also MPEG
TBray: I accept container and standalone. Not sure about container extension.
[Chris]
clarification - bray asked if everyone doing containers used xml; i said no and gave an example
[IanYVR]
TBray: Brutal fact is that we haven't talked about this enough. One proposal is to take this out now and back later if clarified. I agree that there are issues here (e.g., what if I'm not the root of the document...)
[Zakim]
timbl, you wanted to agree with what Chris said in words, and ask him to write it up. That formats should be designed from the understanding that there will be bigger things of which they will form a part.
[IanYVR]
TBL: When you design a format, design it so that it can be part of a bigger system.
[Chris]
would like to see 'rootmost foo element' mentioned in this section as a specific example
[IanYVR]
TBL: This design requires both humility and cleanliness - don't assume you're the root.
TBray: E.g., use namespaces; put root element in namespace.
PC: Does IETF XML Guidelines refer to this?
DC: No.
[DanCon]
hmm... I have a pretty good cache of what timbl's has written and talked about in my head, but I don't recall a talk on designing a format to fit into a bigger world
[Zakim]
DaveO, you wanted to say that containers, container extensions, and standalone have potentially different models for extensibility.
[IanYVR]
RF: I think we should move on; we agree but don't have text.
[timbl]
No, I gave the talk at a distributed systems symposium at Cambridge university between 1984 and 1988. Dave clarke/MIT and Karen Solins was there and we went punting. I remember the slides but took no photos..
[IanYVR]
Action NW: Rewrite 3.2.2.3
3.2.2.4. Extensibility and Versioning
[DaveO]
I said that I feel uncomfortable going to Last Call without having material on language extensibility.
[IanYVR]
RF: Delete first sentence.
Resolved: Move first sentence to second, starting "For example..."
DO: We talk about extensibility and versioning.
NW: My biggest problem with this section is that the attempt to use M and N makes it harder to read.
[Zakim]
DanCon, you wanted to noodle on the extensibility box... I agree, but I don't see motivation
[IanYVR]
DC: I think that extensibility is the biggest arch issue in formats. I also agree with the good practice box. I don't see the argument behind it. Please tell a story.
[DanCon]
(I actually didn't say story this time ;-)
hmm... ignoring styles... I suppose it's come up in several specs... but I still wonder if we have enough experience to generalize
let alone formalize
[timbl]
http://www.w3.org/Talks/1998/0415-Evolvability/slide11-1.htm
[IanYVR]
DO: There are roughly three practices in 3.2.2.4. Something missing from IJ's text - when you are designing a container, define what contained content must do.
[Zakim]
Chris, you wanted to note PNG stuff on fwd and backward compat and to worry about 'as if it didn't exist'
[IanYVR]
CL: "Ignore unknown content" is not always desirable behavior.
[DaveO]
Actually, I meant when designing a container, provide a model that allows required extensions to be identified as required.
[Zakim]
Roy, you wanted to note that there are no principles in section 3
[IanYVR]
RF: No principles at all in section 3. We are going in circles because we don't have principles guiding us. If you use a self-descriptive syntax, it improves extensibility and evolvability.
[Chris]
well as usual, the principles are reverse engineered from the practice
[IanYVR]
RF: If you have a self-descriptive syntax that allows you to plan for evolvability (e.g., ignore data format when value = 0).
[Chris]
but in fact there are, strong, consistent principles that apply to section 3
[IanYVR]
RF: Once you lay down principle you are looking for, your self-descriptive syntax is better.
[DanCon]
indeed, I'm confident there are, chris. we're just not very far along in the document-level work on the reverse engineering
[timbl]
http://www.w3.org/Talks/1998/0415-Evolvability/slide23-1.htm Optional flags
[Zakim]
timbl, you wanted to say you like DaveO's analysys, and would add that the "ignoring" styles can be and should be formalized as transforms which transform a new document into an old one.
[IanYVR]
TBL: I agree that "optional flags" be in there. There are some valuable and distinct concepts that I'd like to put in here.... One language being sublanguage of another is a good example.
[Zakim]
I don't understand 'close the queue. If you don't grok, tell ralph we want a new feature', DanCon
[IanYVR]
TBL: We can describe the sorts of transforms DO is describing.
IJ: I remember TBL's discussion of "no changes outside this subtree" and wonder if that topic is related to what's being discussed here.
[Zakim]
DanCon, you wanted to ask if anybody's interested in writing in the finding genre on extensibility: distill experience with what works and what doesn't. what about HTML helped (ignore unknown tags) and what didn't (clean up messy punctuation) and to estimate that we're 20% of the way thru a 6 month discussion of extensibility and such in data formats
[IanYVR]
DC: Good to try to be crisp ("M and N") but only if we are far enough along. Would someone want to write a finding about extensibility experience in real formats (HTML, HTTP,..) We haven't finished the reverse engineerring.
[timbl]
We should formalize "ignore": and transforms, and formlaize "sublanguage" in term sof the expectations of publishers and reader.
[Chris]
ignore unknown tags did not help
[Zakim]
TBray, you wanted to make some remarks on the general status of this document and where we go from here
[Chris]
danc are you proposing a new issue on extensibility?
[DanCon]
ohh... good idea, Chris. yes, please.

Process: Moving forward with the document.

[IanYVR]
TBray: I agree with DO's analysis of extensibility and with DC that we have more work to do.
[DanCon]
or... hmm... when I asked for an issue on the dualism between message passing and shared state, the TAG didn't agree to add it, on the grounds that "duh... that's part of the architecture". so I wonder if the TAG would adopt an issue on extensibility
[DaveO]
oh, dan, that's an interesting idea....
[IanYVR]
TBray: I think that we may have to triage and cut some stuff that's not ripe in section 3. I'd be about 60/40 today to work until X Sep, and see where we are. We cut at that point.
[ndw]
Currently, November
[Chris]
November i believe
[IanYVR]
DO: We could just publish section 2 (as last call). We could do what TB says and work up to known date.
[Zakim]
DaveO, you wanted to talk about importance of section 3/4 and dates.
[IanYVR]
DO: Another option is to add a few more months to hammer away, and though costly, less costly than finishing now and then doing that work much later.
[Zakim]
DanCon, you wanted to lean toward another few months of work on section 3 and 4... the Sep date is as good a guess as any
[IanYVR]
DC: I think a few months more work on 3/4 is cost effective.
[Chris]
i agree on a couple more months work on 3/4 ... good progress this meeting
[IanYVR]
IJ: I think findings help immensely.
[TBray]
I agree with doing a finding on extensibility
[Zakim]
TBray, you wanted to note fairly massive editorial changes coming as consequence of last 3 days' discussions
[IanYVR]
IJ: They allow readers to focus on specific topics.
[DanCon]
IJ: I don't mean to lose focus on the arch doc, but findings actually help.
[IanYVR]
Action IJ: Produce Editor's Draft Weds or Thurs of next week.

Not discussed

Identifiers (URIEquivalence-15 , IRIEverywhere-27)

Objectives:

  1. Open discussion of issues surrounding URI/IRI comparisons and equivalences (relates to issues #15 and #27).

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

Objectives:

  1. Converge or refactor issues around common basis?
  2. Next steps and actions toward resolution.

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

Objectives

  1. Initiate discussion and actions on substantially undiscussed issues.
  2. Identify next steps and actions.

Existing Issues:

Possible New Issues (this list will be reviewed ahead of the F2F at the 14th July telcon)

Findings in Progress

[Expect contentTypeOverride-24 and whenToUseGet-7 to have made significant progress ahead of F2F. xmlIDSemantics-32 has a stable and mature draft finding and XML Core WG are working toward a resolution of this issue.]

Issues

Other actions

Ian Jacobs for Stuart Williams and TimBL
Last modified: $Date: 2006/12/14 18:47:25 $