W3C | TAG | Previous: 28 Jul teleconf | Next: 18 August 2003 teleconf

Minutes of 4 August 2003 TAG teleconference

Nearby: IRC | Teleconference details issues list www-tag archive

1. Administrative

  1. Roll call: SW (Chair), TB, CL, RF, NW, IJ (Scribe), TBL (end of call). Regrets: DO, DC, PC
  2. Accepted the 21 Jul face-to-face meeting minutes.
  3. The TAG did not accept the 28 Jul teleconf minutes (nobody had read them).
  4. Accepted this agenda, but agreed to continue where Vancouver walkthrough of Arch Doc left off.
  5. Next meeting: 18 August teleconf. Regrets: IJ, TBL. Possible regrets: DO, PC.
  6. SW will be organizing a ftf meeting in Bristol 6-8 Oct, with teleconf link.

2. Technical

The primary focus of this call was on the 1 August 2003 Editor's Draft of the Arch Doc, including a walkthrough of those section of the Arch Doc that the TAG had not covered at the Vancouver ftf meeting.

Actions related to Architecture Document

Note that section numbers of these action items are with respect to the draft.

Completed actions:

Open action items:

Action items related to SVG spec that have been transferred to the SVG issues list:


Review of effect of completed actions
2.1 http://www.w3.org/2001/tag/2003/webarch-20030801#identifiers-comparison
"Applications may apply rules beyond basic string comparison (e.g., for "http" URIs, the authority component is case-insensitive) to reduce the risk of false negatives and positives. Please refer to section 6.3 of [URI] for more information about reducing the risk of false positives and negatives.".
Completed action IJ 2003/07/21: Reword the good practice note with new term for "spelling" based on "character string".
"URI characters: If a URI has been assigned to a resource, Web components SHOULD refer to the resource using the same URI, character for character."
IJ: What about using "Web component" instead of "agent" change?
CL: Seems ok to me.
TB: I think that's probably worth doing as well. I won't stand for the term human component! These are people!
Completed action IJ 2003/07/21: Prune instances of "scheme name" except when referring to string component before ":"; RF calls this "scheme component".
Completed action IJ 2003/07/21: Include POST (and other methods) as examples of deref methods at beginning of 2.5.
NW's new 4.6
CL: Recall that I have an objection to the phrase "final form"
Continuing where we left off: 4.6
IJ: We last were talking about extensibility at ftf meeting.
TB: I am more and more nervous about 4.6 since topic of composition is new.
CL: I agree, but we need something to work with. We already have some (positive and negative) experience.
RF: What about putting this in the "future work" section?
TB: I think that it's fine to point out some of the known issues. The issues in XML are not yet worked out. Don't be too sanguine about expanding this much more than is already there.
unless its to enumerate more known problems
4.7 extensibility and versioning.
CL: Swap 4.6 and 4.7
TB: I agree.
NW: Yep
TB: I disagree with definition "A format is extensible if instances of the format can include terms from other vocabularies. " There is a lot more than than adding elements.
CL: There is ambiguity about word "Vocabulary."
by that definition xml is not extensible
NW: DO and I have a finding in the work on this. I propose that we leave this until the finding has moved along.
(which could be fine - xml is a user restrictable vocabulary)
TB: However, I think the second and third called out principles are excellent and I wouldn't want to lose them.
TB, SW: Delete first principles; it's subsumed.
IJ: How is your finding going in terms of defn of compatibility?
NW: More prose than algorithm.
instead of M and N, perhaps n, n+1, n-1 ?
IJ: But versions aren't required to be sequential to be compatible (or not).

4.8. Presentation, Content, and Interaction

CL: I am still working on text for this section. It will be a summary of long essay I previously sent.
4.9. Hyperlinks
NW: I'd like to change editorially "Allow Web-wide linking, not just internal document linking."
CL: Split in two.
TB: Yes, split. Does last good practice note belong here or in XML section?
NW: N3 uses qnames as well.
SW: Do we need to distinguish hyperlinking from other kinds of linking?
CL: Yes.
IJ: Do we have a defn of hyperlink v. link that is not a horrible rat hole?
TB, CL: No.
TB: We should ack the fact that much of this section that much of the text applies to hyperlinks in XML.
IJ: +1 to creating a generic hyperlink section and an xml-specific hyperlink section.
NW, TB, CL: Yes.
IJ: How does hyperlinking connect to "on the Web"?
are embedded links (images etc) hyperlinks
TB: I don't think we need to have a firm defn of hyperlink in this document.
CL: Are embedded images hyperlink? Are all hyper links user-activated?
are all hyperlinks user actuated?
NW: I share SW's concern. I'm happy to break 4.9 in two and take a stab at defining hyperlink as well.
TB: I think we can get away with "When you go and implement something you think is a hyperlink, do this..." and we'll be fine.
4.10. XML-Based Data Formats
CL: I don't like "XML-based".
TB: I have found no better term than XML-based. I suggest leaving title as is and define what we mean in the first paragraph.
CL: That's fine by me.
Action TB: Write a definition of "XML-based".
IJ: Does "XML Application" connote something different?
TB: Actually, more commonly it's an XML vocabularly.
I mainly want to exclude 'similar to' xml, like using * instead of " for delimiting attributes and saying the syntax is 'based on' xml
TB: In formal terms in the XML spec, "XML application" means anything that talks to an XML processor. So, SVG is an XML vocabulary not an XML application.
4.10.1. When to Use an XML-Based Format
TB: Delete that note; this is not crucial to the arch of the web: "Which XML Specifications make up the XML Family?"
Resolved: Delete the note.
4.10.2. XML Namespaces
TB: We need a consistent formatting when we drop into story mode. Cite "title" element specifically.
IJ: I also deleted a lot of prose I found confusing. Any good practice notes belong here?
TB: We need a good practice note in 4.10.2: When designing a new XML vocabularly, put in its own namespace.
CL: Much more important for elements than attributes.
TB: Given that everyone is wrapping content in SOAP, not having a namespace is a problem.
CL: Formatting attribs in xsl:fo should have been given a namespace.
Action NW: Redraft 4.10.2 to include some good practice notes (e.g., use namespaces!)
4.10.3. Namespace Documents
fot attribute values, especially ones that are inherited
IJ: I added "machine-readable" to good practice note.
Dan googles on the namespace URI and gets back .....
RF: I think "machine-readable" is a meaningless statement.
IJ: In UAAG we talked about "content primarily intended for people" v. "primarily intended for processors"
RF: Say "optimized for machines."
CL: I think the "unattended" part is the key bit. A DTD is suitable for unattended processing.
IJ: What about "Optimized for processors"? I'd like to find a short phrase AND include "unattended" in a definition.
Action IJ: s/machine-readable/something like: optimized for processors, w/ defn that includes notion that it can be processed unattended (by a person).
4.10.4. Fragment identifiers and ID semantics
NW: Third para goes to some length to saqy that there is no semantics for +xml media types. We should note that that may change if RFC3023 changes. Allude to the fact that we may someday get there. In para starting "It is common practice...."; s/DTD validation/validation/
see finding on xmlid-32
RRSAgent, pointer?
See http://www.w3.org/2003/08/04-tagmem-irc#T20-14-10
s/DTD// and fix the grammar
type ID
Action NW: Rewrite para 4 of 4.10.4.
4.10.5. Media Types for XML
norm, see the canonical example
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [
<!ATTLIST foo partnum ID #IMPLIED> ]>
<foo partnum="i54321" bar="toto"/>
4.11. Future Directions for Representations and Formats
Editorially in 4.10.5, check markup for "text/*" in the good practice note
CL: Put 4.10.5 good practice note at the END of the section.
NW: Yes, much better.
CL: Also be more precise that intermediaries can only transcode in case of text/xml.
They can transcode text/*, technically, yes?
CL: Furthermore, append "and will cause the document to not be well-formed."
3. Interaction
There are several more places where I think <code> markup would improve things
CL: Please shorten 3.0.
IJ: It's all story.
CL: But it collects things and these need to be brough tout.
brought out. There's a diagram here: browser gets octets and media type; can interpret octets given media type. Talk about layers here.
IJ: Would these layer be important to the arch?
CL: Yes.
RF: "Some of the headers (for example, 'Transfer-encoding: identity', which indicates that no compression has been applied)" There is no "identity" encoding. You would simply not see any transfer-encoding header. That header field is not just for compression
IJ: What about "(e.g., Transfer-encoding)"?
RF: Yes, that's fine.
IJ: Other examples you'd like to see in the parens?
RF: No.
CL: I'm fine with only 'Transfer-encoding'.
SW: I am wondering whether we need more intro before the story.
IJ: What about putting 3.1 before the story?
CL: Yes, that lets you use the terms in the story.
RF: Para 3 of Interaction doesn't talk about resource header fields. E.g., "vary" is about the response, not the representation.
TBL: Yes, I think we should make that distinction.
Message, Representation, and Resource
3 things
RF: There are always three things: rep metadata, res metadata, and message metadata.
IJ: Where should we talk about resource metadata?
RF: Etag is representation. Alternates is resource metadata
Examples of Resource: Alternates, Vary
Examples of Representation; Etag
SW: Message contains data and metadata. There are three types of metadata (resource, msg, representation)
1. Data 2. Metadata
IJ: Before we said that representation includes some of the representation metadata.
2.1 message metadata 2.2. represtentaion metadat 2.3 resourcemetadata
message metadata is transitory
message metadata is clearly part of the interaction (only)
resource metadata is not about the representation, so its in the interaction section also
thus, only representation metadata is in the formats section
RF: I'm going to rewrite the whole section anyway...
TBL: There are more meanings than "about"; metadata describes relationships.
IJ: I'd prefer slightly longer terms than just "data" since that leads to "Which data? Message data or representation data?"

3. Bin

Findings in Progress

Identifiers (URIEquivalence-15 , IRIEverywhere-27)

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

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

Existing Issues:

Possible New Issues

Other issues

Other actions

Ian Jacobs for Stuart Williams and TimBL
Last modified: $Date: 2003/08/04 22:59:02 $