These notes were generated during discussion by the W3C Technical
Architecture group during its F2F meeting of 3-5 March 2009.  These
are working notes, intended primarily for internal use by the TAG.
They do not necessarily represent the actual opinions of the TAG as to
success criteria, group priorities, etc.

What is success for the TAG?
============================

* Helping communities be more effective.  Help where perspective is
  missing, or might lack background to solve.

* Coordinating review of documents within W3C and outside, noticing
  mismatches between what groups need from each other and provide each
  other.

* See evidence of communities who have responsibility for parts of the
  Web that they recognize having that responsibility.

* Cause new activites, with good value, to spring pu in W3C

* Good coverage of the architecture without bits out. The Web works.

* Happy ending to XML/HTML.

* Necessary and sufficient: TAG to evidence leadership in topics of
  most concern to the Web community (especially the W3C).  Something
  recognized as causing people (especially W3C WG participants) to
  follow.  Can measure effectiveness using TPAC surveys as to whether
  TAG was more help this year than last.

* Win back technical credibility.

* Open, Web-standard technologies continnue to win for Web-content.

* Making the Web better -- be an advocate for the greater
  good. Effectively resolve tensions between working group short term
  interests and serving greater good.

* Javascript security less of a black art.

* XRI TC publishes drafts based on directions emerging from our
  discussions (I.e. no new URI scheme)

* We have an integrated architecture for Web and Semantic Web.

* Explain Web architecture in such a way that a random architect can
  discover which specs are pertinent and can succeed in using them
  effectively.  We need a natural language explanation of >why< things
  are the way they are.  (Integrating both in one WebArch document has
  proven confusing.)

* Demonstrate that the architecture we propose leads to good
  engineering long term.

* Lead in areas where Web is going: e.g. Web 2.0 and successors,
  video, mobile, new devices.

* Ensure that Web technologies provide near state of the art
  capabilities for animation and other modern UI.

* Dealing with services web as opposed to endpoint Web.  Internet
  scale services is a new phenomenon.

* Watch for and document cost/benefit changes in what have been core
  assumptions and technologies: e.g. # replacing ? for state
  management.

* Spec writers use vocabulary we define

What audiences should we address?
=================================

* Anyone who creates or uses Web technologies. Spec authors, web site
  admins, content creators, ....

* People who are building core technologies (e.g. object capability
  security, and semantic web semantics). Language, API and protocol
  designers.

* Spec writers

* W3C working groups, possibly OASIS TC's

* W3C, and peers (IETF, OASIS, etc.)

* Formal technical liaison with IETF & OASIS, etc. where
  possible. Should have new liaisons as necessary.

* 3 parts: whom you want to reach; the channel you use; community you
  survey to guage effectiveness

* anyone who writes or reads a Web spec.

What should we do next year? What should we produce?
====================================================

* Cluster of related issues to write about or delegate to some group
  (or actively decide not to deal with):
   - Metadata
   - Understand relation between HTTP and RDF
   - Scheme/protocols
   - Naming systems in relation to HTTP and other protocols

* Push information resource / resource debate to a conclusion

* Convert architecture document into foil set and notes.

* Harmominization of XHTML and HTML from DOM layer up.  (We don't
  necessarily produce it, but help the community to succeed.)

* Say something about versioning and/or error handing, if only to
  document history.

* Avoid doing things we can't complete

* Put as low priority things that have only short term value.  High
  priority to things that produce documents that have long term value.

* We should emphasize activities that produce "artifacts" of long term
  value (findings, etc.)

* Web app state

* Javascript

* Mobile

* xmlFunctions-34 and semantics of recursively structured documents

* Web security - details TBD

* Use semantic Web technologies such as ontologies to describe Web
  architecture.

* Use formal rules to document TAG conclusions

* Widget packaging

* Architectural issues that affect HTML 5
   - Versioning
   - Error handling
   - Extensibility
   - Tag soup
   - XML vs. XML 5
   - Technical specifications vs. applicability statements
   - HTML as universal Web content vs. extensibilty via plugins.

* Resource description access & redirections

Stuart preferences:
  uniform access to metadata
  webApplicationstate
  distributed extensibility vs. monolithic specs.

Member interests:
  - HTML
  - Web Services - (unclear whether this meant WS* or more broadly)
  - Semantic Web
  - Potholes: finishing things (e.g. file: URI scheme -- why is Web
              apps inventing whole new URI)



















What else should we talk about wrt/
TAG priorities?
===================================