- From: Ian B. Jacobs <ij@w3.org>
- Date: Tue, 15 Jan 2002 15:00:47 -0800
- To: www-tag@w3.org
TAG teleconference
14 Jan 2002
Present: Tim Berners-Lee (TBL, Chair), Tim Bray (TB), Paul Cotton
(PC), Roy Fielding (RF), Chris Lilley (CL), David Orchard (DO), Norm
Walsh (NW), Stuart Williams (SW), Ian Jacobs (IJ)
On IRC: Dan Connolly (DC)
Regrets: Chris Lilley
Previous meeting 7 Jan:
http://lists.w3.org/Archives/Public/www-tag/2002Jan/0056
No comments from participants on minutes of previous meeting.
Next meeting: 21 Jan 2002.
See also IRC log:
http://lists.w3.org/Archives/Public/www-archive/2002Jan/0065
A summary of open action items may be found at the end of this
message.
---------------------
Agenda:
1) Administration
a) IPR requirements
b) Meeting planning
2) Addressing issues brought to TAG
3) Media types and XML processing
4) Architecture document and glossary
---------------------
------------------------
1) Administration
------------------------
a) IPR requirements for invited experts
W3C Process requires that invited experts (in this case, RF and
TB) agree to the following:
http://www.w3.org/Consortium/Legal/collaborators-agreement
Action IJ: Follow up with TB and RF about W3C Process
requirements regarding collaborator contributions.
b) Meeting planning.
Resolved: The TAG will hold its first face-to-face meeting on 12
Feb 2002 in the Boston area. Some participants may attend
remotely by video link.
Proposed: The TAG will meet face-to-face on 5 May 2002 in
Hawaii, in conjunction with WWW 2002 and other W3C meetings at
that time.
------------------------
2) Addressing issues brought to TAG
------------------------
One of the chartered [1] roles of the TAG is to address questions
about Web Architecture brought to it by other W3C Working Groups.
The TAG has already received a request from the XML Protocols
Working Group (see agenda 3).
The TAG intends to adopt the following process:
1) The TAG decides whether it will add an issue to its
long-term agenda, whether it will resolve the issue
"on the spot", or whether it will refuse to consider
the issue.
2) If the TAG accepts the issue for its long-term agenda, the
issue receives a unique identifier is logged on the TAG's public
(archived) mailing list (e.g., with the identifier in the
Subject line).
3) One or more TAG participants will prepare for each issue
and will present to the rest of the group.
4) When an issue is resolved, the TAG should explain how the
resolution will be manifest (e.g., a document update, an
Architecture Recommendation, etc.).
5) The TAG will have a page that will explain what the
TAG would like when an issue is brought to it. For
example:
* Are there a set of apparent alternative solutions
to this architectural issue? If not, could you write
some up?
* What are the use cases?
The TAG discussed some mechanisms for email-based issue
tracking and indexing.
Action IJ: Write up a summary of an initial issue-tracking
mechanism.
[1] http://www.w3.org/2001/07/19-tag
---------------------------------
3) Media types and XML processing
---------------------------------
The TAG received a request [2] from the XML Protocols Working
Group to answer three questions:
Q. 1: What are the general guidelines or policies (if any) for
W3C working groups in defining their own media types? Should
they be defining them at all?
Q. 2: If custom media types are required, should there be any
commonality between them?
Q. 3: What is, or what should be, the relationship between a
media type and an XML namespace?
[2] http://lists.w3.org/Archives/Public/www-tag/2002Jan/0063
/* On Q3. */
TBL: Q3 first came up with MathML WG - mixing math with xhtml.
If you serve mixed document as xml to Netscape, Netscape will
recognize math through the namespace and will display the math.
If you send to IE, IE will feed it only to generic HTML machine,
which will display it as raw source.
TBL: Should you be able to select your application based on
outermost namespace in a document? My opinion is "yes", otherwise
you can't create XML applications.
TB: If we say it's good for software to dispatch on namespaces
(seems not to controversial), I don't think media types will help
you much for highly mixed documents.
DO: I don't think we should duplicate namespace information
outside the content. We should say that the media type should
indicate the presence of an XML document. Processors will have to
handle at least the first namespace in the document. But there's
no point in munging the manifest into the MIME declaration.
TB: It's more complicated than that - to deal with things
properly, you have to dispatch as you work through the
document. I'm not sure much can be usefully said in the media
type.
RF: The media type has more to do with visibility (and selection
of handlers) than about the structure of bits in the content. If
you send a generic XML, you are expecting a generic engine to
process the namespaces. In practice, that's never the case.
TB: The rules of game are that a specification must define
namespace(s) and media type(s). But below top level media type,
doesn't help.
TBL: You can create an RDF document that has an HTML document
inside it, and the HTML is not meant to be displayed as the RDF
is talking about it. The outermost content determines the meaning
of the innermost content. The top-level semantics is important
(e.g., "This is an HTML document first and foremost" or "This is
an SVG document first and foremost"). Having some visibility at
the toplevel is useful, even if it doesn't give you all the
information you need.
/* On Q2. */
DO: My organization doesn't believe in RFC 3023. For instance,
the plus sign ("+") plus sign doesn't help that much (e.g., it
doesn't convey version information).
Resolved: Add all three questions from the XML Protocols WG to
the TAG issues list.
Action IJ: Register three issues raised by XML Protocols WG.
------------------------
2) Architecture document and glossary
------------------------
TBL: Ideally, we should have an outline view of the Web
architecture available. Appended to it would be descriptions in
detail (that link to TAG replies). I think that a glossary is
important.
DO: How will tag deal with multiple uses of same term, or N terms
for same idea (e.g., namespace name and namespace URI both used)?
TBL: Perhaps IJ's primary job (with the TAG) will be to create a
tree (Table of Contents) for the architecture of the Web. This
would be a reference for us; the TAG would write documents to fit
into the spaces.
TB: Are we going to be more reactive or pro-active?
TBL: Charter is that we do both. When I find that I'm answering
the same architecture question three times, I write down my
thoughts (clear or not). So I've created a tree first, and
filling it in non-linearly (referring to Design Issues).
DO: We're going to have to think about the typical taxonomy
problem - what's the toplevel decider?
TBL: We have to realize that it's arbitrary, but we have to do it
for our own work. We can design it as a Web (document
dependences). That's what we've done for Semantic Web Advanced
Development (SWAD).
The TAG discussed whether to use annotation tools (e.g., W3C's
Annotea), a Wiki, or some other mechanism for this type of
glossary project. The TAG agreed for the time being to stick to
email and CVS.
Some resources:
Dan Connolly list of terms:
http://www.w3.org/Architecture/Terms
Web Accessibility Initiative draft glossary
http://www.w3.org/WAI/GL/Glossary/
Web Characterization Glossary:
http://www.w3.org/1999/05/WCA-terms/
Annotea:
http://www.w3.org/2001/Annotea/
Design Issues:
http://www.w3.org/DesignIssues/
Semantic Web Advanced Development:
http://www.w3.org/2000/01/sw/
=============================
Summary of open action items
=============================
IJ: Follow up on W3C Process requirements regarding
collaborator contributions with TB and RF.
Assigned: 14 Jan 2002.
IJ: Write up a summary of an initial issue-tracking
mechanism.
Assigned: 14 Jan 2002.
IJ: Register three issues raised by XML Protocols WG.
Assigned: 14 Jan 2002.
TBL: Find out what kind of editing access to the Web site
will be available to TAG participants.
Status: TBL Reports that CVS should be available.
Assigned: 7 Jan 2002.
PC/IJ: Summarize input on www-tag (including
technical comments, liaison request). An initial
categorization of input may be found in the IRC log.
Assigned: 7 Jan 2002.
DO: As part of preparation for TAG panel at W3C's Technical
Plenary 2002, solicit input from chairs on what issues the
TAG should address, and which documents the TAG should
produce.
Assigned: 7 Jan 2002.
--
Ian Jacobs (ij@w3.org) http://www.w3.org/People/Jacobs
Tel: +1 718 260-9447
Received on Tuesday, 15 January 2002 18:00:45 UTC