W3C home > Mailing lists > Public > www-tag@w3.org > February 2004

[Minutes] 9 Feb 2004 TAG teleconf (Arch Doc LC comments, RDFinXHTML-35, Qnames)

From: Ian B. Jacobs <ij@w3.org>
Date: Wed, 11 Feb 2004 17:59:45 -0500
To: www-tag@w3.org
Message-Id: <1076540385.1247.100.camel@seabright>

Minutes of the TAG's 9 February video conference are
available as HTML [1] and as text below.

 _ Ian

[1] http://www.w3.org/2004/02/09-tag-summary

               Minutes of 9 February 2004 TAG Videoconference

1. Administrative

    1. Roll call: SW in Bristol; TBL, DC, IJ in Cambridge; DC, PC, RF in
       Redmond. NW and MJ by phone. CL arrived at the end of the meeting
       in Bristol. Regrets: TB
       The TAG thanks Microsoft for hosting this videoconference!.
    2. Resolved to accept minutes of the [8]2 Feb teleconf
    3. Accepted this [9]agenda
    4. Proposed next meeting: 23 Feb 2004. IJ at risk.
    5. Reminder: No meeting 16 Feb.

      [8] http://www.w3.org/2004/02/02-tag-summary.html
      [9] http://www.w3.org/2001/tag/2004/02/09-tag.html

  1.1 Technical Plenary

    1. TAG Participation at Tech Plenary ([10]agenda)
          + Session 2: Architecture of the World Wide Web and Hot TAG
              1. Action DC: Motivate discussion for namespaceDocument-8
              2. Action SW: Find a volunteer to discuss identifiers at
                 Tech Plenary
              3. The TAG also discussed how to handle extensibility and
                 versioning at the Tech Plenary
          + Session 4: Adventures with Mixed Markup Language Documents
            [Some TAG participants]
    2. [11]TAG 2 Mar 2004 ftf meetingl
          + [12]Liaison scheduling plan. The TAG discussed how best to
            liaise on the topic of RDF in HTML.
          + Handling LC comments

     [10] http://www.w3.org/2004/03/TechPlenAgenda.html
     [11] http://www.w3.org/2004/03/02-tag-mtg.html
     [12] http://www.w3.org/2001/tag/2004/02/TAG-Liasons.html

  1.2 TAG meeting schedule in 2004

    1. Resolved: The TAG will meet face-to-face in Boston 12-14 May.
    2. Action PC 2004/02/09: Propose August ftf meeting dates.

2. Technical

   See also [13]open actions by owner and [14]open issues.

     [13] http://www.w3.org/2001/tag/actions_owner.html
     [14] http://www.w3.org/2001/tag/issues.html?view=normal&closed=1

  2.1 Review of issues to close by end of LC

    2.1.1 qnameAsId-18 andrdfmsQnameURIMapping-6

   Issues [15]qnameAsId-18 and [16]rdfmsQnameUriMapping-6. Jan 2004 draft
   finding "[17]Using Qualified Names (QNames) as Identifiers in Content"

     [15] http://www.w3.org/2001/tag/issues.html#qnameAsId-18
     [16] http://www.w3.org/2001/tag/issues.html#rdfmsQnameUriMapping-6
     [17] http://www.w3.org/2001/tag/doc/qnameids-2004-01-14

   Action DO: Point WSDL WG to resolution of issue 6.


          DC: Best thing is for WSDL WG to send in an LC comment.
          DO: There are three people who are reviewing it.

          yeah, DO's action is done to my satisfaction

          Resolved: DO's action is completed.

          No objection to the withdrawal.

   This closes issue 6.

   Action DC, TB, TBL: Review[18]14 Jan draft of Qname Finding

     [18] http://www.w3.org/2001/tag/doc/qnameids-2004-01-14.html

          DC: Apologies, not done.
          TBL: I read it. The gist is right; could be written in a less
          confusing fashion. Starts off saying there's no std way of
          defining what prefix the ns maps to. But then goes on to talk
          about the "normal way" of doing it. So there is really one way
          of doing it (for elements, attributes).
          NW: XPointer uses a completely different mechanism.
          TBL: There is an original way; xpointer has deviated from that
          way. Please mark my action item as completed.

          Yes, xpointer has deviated, so there is no longer one way.

          Unclear to me if TBL wants changes.

          My conclusion is that really that is a mess. The finding does
          explain that. The fact that there is a finding doesn't mean the
          architecture is clean.

          IJ: It is my understanding that to close this issue, we need to
          approve the finding.
          DC: Schema WG seems relevant here. I wouldn't consider our LC
          successful if we haven't heard from the Schema WG. I want to
          approve the finding AND hear from the other groups.

          Put another way, Norm, my suggestion is that the document
          should treat the way the elements and attribute prefixes are
          bound as being special, as it was the original one defined in
          the NS spec which introduced the colon in the first place. It
          isn't true to say that there is not one algorithm. It is true
          to say that various specs have defined their own. The subtlety
          is that folks want to throw away namespace bindings that they
          don't "know" they need.

   The TAG returned to this topic later in the meeting; those minutes
   appended here for readability.

          On Qname finding: I think NW should make more of the algorithm
          that one uses to determine the binding when looking at elems
          and attributes.

          NW: Can TBL say more of what he's looking for?

          I find "Specifications that use QNames to represent {URI,
          local-name} pairs MUST describe the algorithm that is used to
          map between them." which is responsive to my comments.

          Section 4.2 says: "Using a QName as a shortcut for a {URI,
          local-name} pair is often convenient, but it carries a price.
          There is no single, accepted way to convert QNames into {URI,
          local-name} pairs or vice versa. Different specifications have
          chosen different algorithms."

          (IJ: XML 1.1 and XML NS 1.1 are now W3C Recs)
          TBL: There *is* a single, special way. It's just not accepted.
          I propose to change the spin: there is one way, but not always
          taken for a variety of reasons (some good, some bad). The word
          "context" is vague. It's rather: they've used them for other
          things than elem and attrib names. Two points (1) seems
          reasonable to use them to refer to other things, but issues
          such as QName v. URI arise. (2) they could have used the ns 1.0
          algo and didn't.
          NW: First of all, I think the word context is used to mean
          "environment" here.

          TBL: Ok, I see.

          NW: I *do* think the context is the important issue here. Note
          that when XPointer tried to use the same mechanism, they were
          told not to use the same mechanism (by the Director).
          TBL: XPointers have their own special set of problems.
          NW: XML Query uses a different mechanism as well - it's not in

          Does this finding apply to N3? I thought we had resplevd to
          make the title ".... XML content"

          I don't recall that we agreed to that, though I do recall the
          discussion. In any event, I think this findning has to cover
          XML Query, and other non-XML specs, because they're clearly
          inseperable from XML

          I am now confused as to the scope of this document. I had a
          relatively small change in mind, but in the discussion now I am
          confused about the scope

          SW: I'd like reviewers of the finding to send proposed changes
          by email.

          NOT DEFINED.
          I now have no idea what the scope of the document is. If it was
          XML I had a small comment. If includes non-xml things, then I
          would have to add a contratsing para about N3.

          timbl, I now believe the scope is "wherever qnames are used"

          Thanks norm. I'll go with that. Stuart, please consider my
          action item w.r.t. the Qnames finding ongoing.

    2.1.2 whenToUseGet-7

   Issue [19]whenToUseGet-7

     [19] http://www.w3.org/2001/tag/issues.html#whenToUseGet-7

   Action DC: Provide TAG with pointers into WS specs where issue of safe
   operations is manifest.

          DC: The more relevant bit is that someone asked for
          clarification about what the finding says about WebServices.
          Please continue

   Action DO: Ask WSDL WG to look at finding; ask them if marking
   operations as safe in WSDL is one of their requirements.

          DO: I have not heard back after my [20]email; I was at the WSDL
          ftf meeting and the issue did not come up while I was there. I
          don't recall it being on the agenda. I will either prompt the
          WG again or report the results.
          SW: Ok; we can clean this up when we meet with them, if not

     [20] http://lists.w3.org/Archives/Public/www-ws-desc/2003Dec/0006.html

    2.1.3 contentTypeOverride-24

   Issue [21]contentTypeOverride-24

     [21] http://www.w3.org/2001/tag/issues.html?view=normal&closed=1#contentTypeOverride-24

          IJ: Revising the finding is on my to do list in light of
          comments from SW and RF on [22]27 Jan 2004 draft.

     [22] http://www.w3.org/2001/tag/doc/mime-respect-20040127

  2.2 Web Architecture Document Last Call

   RF joins the meeting.
     * Review and acknowledge comments sent to
          + See [24]thoughts on tracking LC comments from IJ
          + Comment threads from [25]public-webarch-comments@w3.org
               o M

     [23] http://lists.w3.org/Archives/Public/public-webarch-comments/
     [24] http://lists.w3.org/Archives/Member/tag/2004Feb/0022.html
     [25] http://lists.w3.org/Archives/Public/public-webarch-comments/

          ction IJ: Take into account pure editorial comments from

    2.2.1 Tony Hammond "[26]Initial Feedback on Web Arch W-D"

     [26] http://lists.w3.org/Archives/Public/public-webarch-comments/2003Dec/0006.html

          DC: I don't seem to be able to convince people to use term
          "representation" OR "data format"
          On whether to use other schemes than HTTP in stories.
          DC, TBL: Not worth using other uri schemes in stories.
          Sect 5 - Term Index. Maybe missing some terms?
          TBL: In future version.
          IJ: +1 to WWW, World Wide Web, URI (as cross-refs)

          We need in the next version (after 1.0) a glossary with a model
          - an ontology

          Sect 6 - References. Still minded to have a division between
          normative and informative refs.
          [No proposal; no movement to change]
          IJ: I will double check that all refs appear in the body.

          a goal of mine, for each comment, is to recruit somebody from
          this meeting to respond in substance. any volunteers to respond
          to Hammond?

          Action NW: Send TAG a draft of a response to Hammond review in
          light of TAG's discussion.

          "Sect 2.4, last para, last sentence - 'When an agent does not
          handle a new URI scheme, it cannot retrieve a representation.'
          This seems prejudicial"


     [27] http://xml.coverpages.org/ni2004-01-15-a.html

          RF: Only time a URI scheme wouldn't be handled is during
          TBL: I'd like to flag the fact that he has brought up the
          "info" URI scheme. I think reviewer is asking whether the arch
          doc is wrong or whether the info scheme is not that useful.
          Please put that question on our stack.

          agenda1 = Info URI scheme

     [28] http://xml.coverpages.org/ni2004-01-15-a.html

    2.2.2 Bob DuCharme "[29]comments"

     [29] http://lists.w3.org/Archives/Public/public-webarch-comments/2003Dec/0019.html

          1.1 "at least" : editorial
          1.1.3 "elements" : editorial

          Bob writes well, I concur

          [TAG concludes that these comments are largely editorial; IJ to
          attend to.]
          DO: I concur as well.
          Action IJ: Handle Bob's comments as editorial.

    2.2.3 Tom Worthington "[30]Simplify the text and separate the W3C politics"

     [30] http://lists.w3.org/Archives/Public/public-webarch-comments/2003Dec/0020.html

          PC: I disagree with this one. I think the document has right
          level of examples.
          RF: We are presenting more of an architectural justification
          than a mere description.
          Action PC: Respond to Tom Worthington, talking about arch doc /
          findings balance, and pointing out that we are not creating a
          point-form architectural thesis.

    2.2.4 David Booth "[31]Definition of "Web agents", "URI ownership" and

     [31] http://lists.w3.org/Archives/Public/public-webarch-comments/2004Jan/0000.html

          The document currently uses "agent" to include both "software"
          and "people".

          DC: I'm inclined to change Web agent to "party".

          SW: Reluctant to introduce new terms.

          new term?

          PC: I did not find DB's survey very compelling.

          (Paul I wonder whether you could also try to answer the callers
          question about iMode HTML in the previous one)

          SW: I'm ok with another term, I just want consistency.

          prefer which, DaveO?

          DC: I need a term that includes "software and people"

          I'm ok with "agent" or "party"

          TBL: An agent is "something that does things"

          I am happy with agent being inclusive of people.

          From Collaborative International Dictionary of English: "One
          who exerts power, or has the power to act; an actor."
          DC: I need these things to agree to things, initiate
          communications, ....

          I am equally happy with agent being exclusive of people and
          that we say "people and software" or "people and agents".

          DC: I can live with "party" including software and people.

          I think the word 'party" is obscure

          DO: I agree with David's position on this one.

          "agent or human" doesn't work, it would have to be "agent or
          social entity"
          plus a convention that one look at the tv ;-)

          Support for changing usage of agent?
          Yes: DO
          Norm: RF
          RF: "Agent" has too many loaded meanings. I had proposed
          "components" [things in the system that are doing things] and
          "connectors" [things that assist communication; pass-throughs]
          I'd just remove the parentheticals that appear in the Arch Doc.

          RF+1. I also don't like the term "agent" very much. Due to it's
          overloaded meaning. Agent also sounds some kind overloaded
          within the AI enviroment.

          DO: Do we have a summary of our reasoning and alternatives to
          offer to readers?

          mario, any alternatives to suggest?

          3 options: (1) accept somebody's offer to defend the status quo
          [timbl?] (2) accept an action to change webarch to say
          something else.
          (3) [now I forget]

          DO: I'm ok with current language; I support complementary
          materials to explain our choice.

          What about "actor"? [32]Bartleby definition says:"A being,
          body, creature, homo, human, human being, individual, life,
          man, mortal, person, personage, soul. See BEINGS. 5. One who
          participates: actor, participant, player."

     [32] http://www.bartleby.com/62/61/P1096100.html
     [33] http://www.bartleby.com/62/61/P1096100.html

          Action TBL: Respond to DB on TAG's choice of agent - the status

          How about "mortal" as it sums up what people have in common
          with software?

          Proposed: Defend the status qou.
          Abstain: DO, RF
          No objections.
          Resolved: Defend the status quo usage of "agent".
          On 2.2 URI Ownership: Following the lessons of the "deep
          linking" debacle, it might be good to say explicitly what
          rights "URI ownership" does or does ot confer. This is somewhat
          addressed later, but it might be good to say something in this

          wrt to agent I also think it would be useful to the defnintion
          that Dan found in November.

          TBL: I have tried to eliminate this concept and failed.
          DC: I like the text that's in here currently. I can live
          without "The social implications of URI ownership are not
          discussed here."
          PC : Propose we forward link from 2.2 to 3.6.3.
          RF: "Authority responsible for" is redundant.: Change to "The
          authority for"
          IJ: Hmm.

          Are 'authority' and 'ownership' synonymous?

          SW: Maybe eliminate one term.

          stuart, you're not happy with [[ The phrase "authority
          responsible for a URI" is synonymous with "URI owner" in this
          document. ]] ?

          No Dan I think I'd be happy with that.

          why "would", stuart? are you or are you not?
          I'm quoting from webarch 9Dec

          Action IJ: Include forward link from 2.2 to 3.6.3.
          DC: We are treating "URI ownership" as editorlal as well.

    2.2.5 Tim Goodwin "[34]Comments on 9 December 2003 draft"

     [34] http://lists.w3.org/Archives/Public/public-webarch-comments/2004Jan/0001.html

          Editorial, as the reviewer indicates.
          Action IJ: Take these comments into account.

    2.2.6 Patrick Stickler "[35]Comments on "Architecture of the World Wide
    Web, First Edition"

     [35] http://lists.w3.org/Archives/Public/public-webarch-comments/2004Feb/0000.html

          DC: I support his first example.
          IJ: There was, in a previous draft of the arch doc, a statement
          a long the lines of "URIs without frag ids are more useful";
          e.g., frag ids don't make it through proxies. (Section 3.3.1,
          para 2:)
          "Question: are the methods PUT, POST or DELETE meaningful for
          URI references with fragment identifiers, in terms of
          interacting with the state of the secondary resources denoted?"
          TBL: The answer is "no". Nor is "GET" I read this as "Can I
          delete an anchor in an HTML file?"
          DO: I do, too.
          DC: I don't
          RF: I think the reviewer wants us to point out this observation
          about the Web.
          DC: DO is right, we don't address this point currently in the
          arch doc.
          TBL: Web of conceptual objects build on a layer of another Web
          of conceptual objects.
          DO: Is there a hole in the architecture that a client can't
          talk to the server about secondary resources?
          TBL, DC: I don't regard that as a hole.
          RF: I hear the proposal that we should include this discussion
          in the document.
          DC: I don't see any line between this discussion and
          httpRange-14. I think we can respond "We agree that this is not
          treated well in this version of the arch doc."
          PC: What about "The use of URIs with frag identifiers for

     [36] http://www.w3.org/TR/webarch/#dereference-uri

          Issue14-complete. We hope to address this more fully in the
          next edition

          RF: In RFC2616, frag id not allowed in request. This is
          intentional; it must be handled at the client.


     [37] http://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html#sec5.1.2

          RF: So it's an error to try to use DELETE with a URI with a
          frag id.

          Roy: A frgament is not allowed in teh URI in an HTTP request.

          RF: This is described in the URI spec.

          I think the commentator is complaining that the first step in
          deferenncing a U#F is to actually deference a different URI, ie
          U. I think here he is *just* asking us to be clearer about what
          it means to deference U#F (operationally).

          PC: RFC 2616 says "MUST NOT" incliude a fragment.

          The paragraph he's complaining about starts "Per [URI], in
          order to know the authoritative interpretation of a fragment
          identifier, one must dereference the URI containing the
          fragment identifier."

          RF: The Web library won't allow this either. The frag ids are
          only used for comparison and for assertion.

          timbl, you wanted to suggest we discuss teh info URI scheme and
          to note that DAWG may address this in the distant future when
          the secondary resurce is an RDF node.

          DAWG: Data Access Working Group

          (I heard RDF)

     [38] http://www.w3.org/2003/12/swa/dawg-charter

          DO: The specs talk about how a client deals with a secondary
          resource on the client side. But I can't do any server-side
          operations on secondary resources. I can't put info in a URI, I
          have to put info (about secondary resource) in the message.
          TBL: You do have that today: You can do a GET, do operations on
          the client side, and PUT data back to the server.

          (this discussion shows to me that the terms "primary resource"
          and "secondary resource" are handy to have; I have had doubts
          about whether they were worth having)

          DO: People are talking about doing operations on secondary
          SW: I volunteer to think about it some more.
          Action SW: Propose to the TAG a reponse to P. Stickler's
          "Parties that draw conclusions about the interpretation of a
          fragment identifier without retrieving a representation do so
          at their own risk; such interpretations are not authoritative."
          TBL: I disagree with Patrick.
          RF: You cannot infer the properties of the frag id by
          retrieving the representation. Things change over time.
          DC: We address persistence elsewhere. I disagree with RF's
          "Per [URI], in order to know the authoritative interpretation
          of a fragment identifier, one must dereference the URI
          containing the fragment identifier."

          No... I think that the TAG was saying it was ok. to construct
          identifiers in frag-id space... I don't think that the TAG said
          anything about running it backward - interpreting the frag id.
          I volunteer to enlarge my action item and propose responses to
          more of Patrick's message.

    2.2.7 Martin Dürst "[39]Schedule for RFC2396bis" (and an LC Comment)

     [39] http://lists.w3.org/Archives/Public/public-webarch-comments/2004Feb/0001.html

          RF: I've made a majority of the changes he's suggested (in the
          past few days).
          PC: I think our response is that we understand our dependency
          on this spec. We don't see what we can do to help the
          dependency. Question is whether we can move out of LC with
          normative dependence on RFC2396.
          Action PC: Respond to MD, acknowledging the dependency.

  2.3 RDFinXHTML-35 and GRDDL

   See email from DanC: [40]Presenting GRDDL and [41]slides from DC,
   which DC presented.

     [40] http://lists.w3.org/Archives/Public/www-tag/2004Feb/0023.html
     [41] http://www.w3.org/2003/g/talk/all.htm

   CL joined the meeting during this item.

          "anyone can say anything about anything"
          DC: some RDDL designs have not met this requirement.

          (They did not allow one to state the subject of an assertion,
          it was always implicitly the current document)
          <link rel="metadata" href="aboutfoo.rdf"/>

          "HotComments": RDF in XHTML comments.
          * Semantic Web CG, Hypertext CG start public-rdf-in-xhtml-tf
          DC: Pattern is to use a specialized dialect of XHTML, write a
          program to extract data, link to that program from your
          document. Use the "profile" hook to ground the term

          Step 3 means "You should interpret a rel=transformation link
          along the lines of step 2".

          Does this use of <head> ie adding the profile attribute 'eat'
          the whole of <head>
          ie you couldn't have another <head> section with a different
          profile to extract different data?

          IJ: Any reason not to use URI in META/name?
          DC: GRDDL says it's the user's choice.

          Step 2 means "You can interprest this document in RDF using
          this using this XSLT script"

          SW: Can you use multiple profiles?
          DC: Yes.
          GRDDL XSLT service demo, example
          DC: Different xslt scripts; one profile
          DO: Given that there's no std processing model for knowing when
          you are at intermediate or end processing, how do you know
          which kind of infoset you're supposed to reverse transform on?
          DC: GRDDL works on the xhtml it gets back from the HTTP server.
          TBL: I'm the heretic about XML processing model: I think it's
          good to have only one. Expand XInclude first.

          I think this hsould happen *after* xinclude. I think it should
          work on the result of XML-level stuff.

          DO: My question is "on what thing do you start doing the
          reverse transform from."
          DC: I had not considered that; I was just answering from the
          code we have written.
          IJ: Heads up - 404 for
          DC: copy paste bug

     [42] http://www.w3.org/2003/data-view.html#transformation

          local link to further on

          DC: GRDDL drawback: turing completeness. Consumer may have to
          run untrusted code. But digital sig might be an approach.
          Well-known transformations might be another approach -
          recognition of well-known stuff.
          PC: I thought of Schema. Aren't you describing semantic
          processing that belongs in the schema?
          DC to PC: Wait two slides...
          DC: Principle of Least Power. hmm... belongs in webarch
          somewhere? GRDDL Semantics: explicit, grounded in the Web.
          Whatever syntax is used, you can trace it back to URIs. We
          didn't finish our discussion of URI-based flexibility points
          before webarch last call. Let's resume, please! Grounding terms
          in the Web.

          only if the q empties before the end of the meeting.

          DC: I agree with PC - doing this on a per-document basis is
          suboptimal; would be better, e.g., at namespace level.

          CL, you wanted to ask about reusability

          CL: How re-usable are these transformations?
          DC: I intend to make 7-8 html dialects in the next few months.
          DO: Some transformations are lossy. It would be interesting if
          you had some material on what kind of transformations are
          lossy. A simple example is a name - if you go from
          FirstName/FamilyName/Suffice/Etc., you have lost information.

          timbl, you wanted to discuss this one about post-transformed
          stuff and to say that this puts ont the shopping list a safe
          subset of XSLT, and it might be worth mentioning in the arch
          doc next version.

          (in short, GRDDL is not nearly as useful in anything

          TBL: I think this is good stuff. It highlights the issue with
          the processing model. Having a default processing model for XML
          would be nice. That XInclude doesn't define that explicitly is
          a problem.

          (Chris, I'm still thinking thru your comments; I could think
          out loud here, but I see 3 minutes left in the meeting, unless
          we extend)

          TBL: If you're going to use this mechanism "live" it'd be nice
          to have a safe subset of XSLT. By safe here I mean that
          strictly a function of input data, doesn't let you write, limit
          processor memory usage, doesn't let you access info server is
          privy to, etc.

          dc, thats fine. it can be done in email

          PC: Regarding this proposal - people will not want to pull a
          URI out of a document and execute code that's at the end of the
          DC: We run an online service. It's not too bad so far. But I
          agree that this is the #1 drawback with this approach.
          TBL: I note that MS products already run style sheets on the
          client that are specified by the author. This is "for humans".
          The above proposal is the same, but for machines.
          SW: Where should this discussion take place?
          DC: I expect that HTML Task Force to be rolled into the Sem Web
          BP WG. The Task Force is just a mailing list.
          SW: Please let the HTML WG know that this topic is on the
          agenda of the Sem Web BP WG meeting. Anyone with a stake, for
          that matter, should know.

          DaveO, we have this coded up; I'm happy to discuss it any time.
          Feel awkward discussing at T+4min, where T is the scheduled
          adjournment time.

          [IJ goes to another meeting]

          oh well.


   The TAG did not discuss the topics below this line.

   IETF/W3C joint meeting update from DC.
     * [43]namespaceDocument-8
         1. [44]RDDL2 Background from Tim Bray.
         2. [45]grokRDDL.xsl mapping to RDF from Dan Connolly.

     [43] http://www.w3.org/2001/tag/issues.html#namespaceDocument-8
     [44] http://lists.w3.org/Archives/Public/www-tag/2004Jan/0045.html
     [45] http://lists.w3.org/Archives/Public/www-tag/2004Jan/0026.html

3. Planning for 2004

     * Future versions of WebArch
     * Webarch Diagrams and Companion Documents
     * Goals/Milestones for 2004
     * Priority Issues.

4. Follow-up on Internationalization Issues

     * [46]charmodReview-17
         1. [47]actions
         2. TAG finding related to adoption of Charmod? See [48]mail from
     * [49]URIEquivalence-15
     * [50]IRIEverywhere-27

     [46] http://www.w3.org/2001/tag/issues.html#charmodReview-17
     [47] http://www.w3.org/2001/tag/actions.html#charmodReview-17
     [48] http://www.w3.org/mid/361483C6-96E6-11D7-9C47-000393914268@w3.org
     [49] http://www.w3.org/2001/tag/issues.html?view=normal&closed=1#URIEquivalence-15
     [50] http://www.w3.org/2001/tag/issues.html#IRIEverwhere-27

5. Status report on these findings

   See also [51]TAG findings
     * [52]contentTypeOverride-24:
          + 27 Jan 2004 draft finding "[53]Client handling of MIME

     [51] http://www.w3.org/2001/tag/findings
     [52] http://www.w3.org/2001/tag/open-summary.html#contentTypeOverride-24
     [53] http://www.w3.org/2001/tag/doc/mime-respect-20040127.html

     * [54]abstractComponentRefs-37:
          + 30 Oct 2003 draft finding "[55]Abstract Component References"
     * [56]contentPresentation-26:
          + 30 June 2003 draft finding "[57]Separation of semantic and
            presentational markup, to the extent possible, is
            architecturally sound"
     * [58]metadataInURI-31
     * [59]siteData-36
          + "[60]There is no such thing as a Web site"

     [54] http://www.w3.org/2001/tag/issues.html#abstractComponentRefs-37
     [55] http://www.w3.org/2001/tag/doc/abstractComponentRefs-20031030
     [56] http://www.w3.org/2001/tag/open-summary.html#contentPresentation-26
     [57] http://www.w3.org/2001/tag/doc/contentPresentation-26-20030630.html
     [58] http://www.w3.org/2001/tag/open-summary.html#metadataInURI-31
     [59] http://www.w3.org/2001/tag/issues.html#siteData-36
     [60] http://www.tbray.org/ongoing/When/200x/2004/01/08/WebSite36

6. Other action items

     * Action RF 2003/10/08: Explain "identifies" in RFC 2396.
     * Action DC 2003/11/15: Follow up on KeepPOSTRecords with Janet Daly
       on how to raise awareness of this point (which is in CUAP).
     * Action CL 2003/10/27: Draft XML mime type thingy with Murata-san


    Ian Jacobs for Stuart Williams and TimBL
    Last modified: $Date: 2004/02/11 22:56:51 $

Ian Jacobs (ij@w3.org)   http://www.w3.org/People/Jacobs
Tel:                     +1 718 260-9447

Received on Wednesday, 11 February 2004 17:59:55 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:03 UTC