- From: Ian B. Jacobs <ij@w3.org>
- Date: Mon, 13 Jan 2003 17:01:46 -0500
- To: www-tag@w3.org
Hello,
Minutes from the 13 Jan 2003 TAG teleconf are
available as HTML [1] and as text below.
- Ian
[1] http://www.w3.org/2003/01/13-tag-summary
========================================================
W3C | TAG | Previous: 6 Jan teleconf | Next: 20 Jan
2003 teleconf
Minutes of 13 Jan 2003 TAG teleconference
Nearby: IRC log | Teleconference details ? issues
list ? www-tag archive
1. Administrative
1. Roll call: SW (Chair), TBL, TB, DC, NW, PC, RF,
DO (partial), IJ (Scribe). Regrets: CL.
2. Accepted 6 Jan minutes (with corrections
suggested by CL and DC).
3. Accepted this agenda
4. Next meeting: 20 Jan.
SW: I will move up on the agenda the question of
written contributions; arch doc and review of
"How to Compare Uniform Resource Identifiers".
5. Upcoming meetings: 3 Feb (brief welcome to
newcomers). No meeting 10 Jan.
1.1 Completed actions
1. SW 2002/11/18: Organize a special-interest
teleconf for discussion of this issue on linking.
2. IJ 2003/01/06: Create a ftf meeting page.
1.2 Meeting planning
1.2.1 XLink teleconference
16 Jan; see meeting details (TAG-only).
[DanConn]
MIT holiday calendar
[Ian]
Action SW: Invite Micah Dubinko as well.
[Review of agenda of XLink meeting]
IJ: What about starting discussion with a
proposal (e.g., TB's proposal).
NW: I think that concrete proposal based on
XLink will not encourage discussion.
TB: What about opening discussion on goals of
linking in XHTML 2.0?
TBL: Let's return to the original
requirements. I have the feeling the HTML WG
has tried to provide a generalized solution,
rather than providing a way for authors to
make links across vocabs.
SW: I'm not sure we have a clear articulation
of the problem.
IJ: Do we have anyone who will champion a
cause?
TB: I will champion (1) new functionality for
linking in XHTML 2.0 and (2) some principles
for linking for the syntax if it's considered
to be helpful in making progress.
[TimBL]
I am prepared to speak on behalf of xlink:a
[Ian]
TB: It's important to understand where the
HTML WG is coming from, and what they think is
important.
IJ: We did hear them say "external namespace
is not a huge hurdle."
[SW and TB will chat more about agenda]
IJ: On xlink:a, how do you handle content
model?
TBL: You export the content model of html:a.
Answer - you crosslink the schemas.
NW: That particular style solution does not
address a big part of the process space - some
vocabs don't have HTML elements at all.
[Norm]
I want an XLink solution for DocBook which
will *never* have HTML inlines in it.
1.2.2 Next TAG ftf
6-7 Feb; see ftf meeting page.
[Ian]
SW: I would like to talk about Tech Plenary.
DC: I hope we will chew over Arch Doc text.
IJ: Most expected text is from action items;
there's not much.
[DanConn]
Ian: I expect text from ChrisL on data
formats, and perhaps from Tim/Roy on http-14
[Ian]
TB: I'll look at latest editor's draft and
send comments.
[DanConn]
DanC: hmm... that's not a whole lot... hmm...
1.3 New issues? Architectural issues with XInclude
See email from M. Murata
1. fragmentInXML-28 : Use of fragment identifiers in
XML.
[Ian]
NW: Consensus of Core WG was that XInclude was
doing roughly the right thing. Unsure whether
this should be bumped to TAG or whether Core
WG should politely indicate that the WG has
considered the issue. Purpose of XInclude is
to combine infosets of two XML Docs. The only
thing it makes sense to include are bits of
plain text and bits of XML. XInclude willfully
disregards the MIME type. That's its purpose
in life.
TB: If this a symptom of a larger problem, we
should invest time in it. If this only appears
in XInclude, we can safely ignore.
TBL: I think there's need out there; just
hasn't been available.
DO: I don't think there's anything
architectural to look at here. I'd advise
against accepting this as an issue.
NW: I think there's a deep and ugly issue
lurking here (though we may choose to not take
it up). Frag identifier reliance on MIME type
is worrisome...
[DanConn]
Norm, is this different from "fragmentInXML-28
: Use of fragment identifiers in XML"?
[Ian]
TB: I think this intersects with recent flurry
about content negotiation.
[DanConn]
hmm... i thought "fragments and mime types"
was on our agenda; I thought I was obliged to
tell RDFCore what we decided about it...
[Norm]
Yes, fragmentInXML-28 is a good hanger for the
larger issue
[Ian]
TBL: What happens if there's a doc served as
plain text and you say "treat as plain text".
What about the inverse?
NW: With XInclude, you can point to a doc
served as text/plain and say "treat as XML".
If well-formed, all will go well. I have no
problem with that. Murata-san says that that's
not the right thing to do since that's
explicitly overriding the MIME type.
TB: We say in arch document not to override
MIME type.
IJ: Did we say that or did we say "There's one
authoritative way to do this; if you do
something else you're on your own?"
TB: I think that XInclude is doing the right
thing here. We are not talking about general
resource representation retrieval. This is a
clear special case.
NW: I agree.
DC: Does XInclude recommend Accept headers?
I'm inclined to accept this as a new issue (or
almost any disposition).
SW: Does anyone propose we take this on as a
new issue?
TBL: I haven't read the spec in enough detail.
TB: I agree with TBL that there may be an
issue lurking out there, but I don't think we
should accept until we have a better
crystalization. I would decline on the basis
that XInclude functionality is special and
wired into XML's view of the world; it is not
of particular arch import.
TBL: If it's fundamental to XML, I think we
can't say that it's not important to Web
architecture. My sense is that there are two
functions - they are accepting either xml or
taking a plain text doc and doing a rather
risky conversion. Fear of ending up specifying
same thing in 6 places, inconsistencies, fear
of having URI+media type pair.
NW: Nothing risk about conversion of XML ->
text/plain
TB: Suppose I ask for something to be included
as text that has entity refs?
NW: They are processed.
TBL: I'd like to raise as an issue. I don't
want to put it in the head of our queue.
TB: We don't want to get onto the slippery
slope of turning URIs into doubles. It does
strike me as architecturally question that
XInclude doesn't say anything about this
(e.g., what happens when content is not xml)?
NW: XInclude will fail.
[Zakim]
DanC, you wanted to propose that we don't find
material for a new issue, but we note the
requestors stay tuned to fragmentsInXML-28
[Ian]
NW: I'm uncomfortable with that proposal since
I'm not sure what the Core WG can do to get to
PR.
DC: I think that the Core WG should try to
satisfy the commenter.
TB: I'd be willing to second DC's proposal to
formally attach this input to issue 28. TBL
has convinced me that there's something here
we can't ignore.
TBL: That's fine by me.
Resolved: Include this question as part of
issue 28.
PC: I'd like minutes to say what, if anything,
we are saying to Core WG.
[DanConn]
... TAG isn't instructing the XML Core WG in
any particular way...other than to address the
comment in the usual way.
[Ian]
PC: Thank you, that's fine.
Action IJ: No new issue. Add this to issue 28 (with
reference to XInclude).
2. Technical
* xmlProfiles-29
* namespaceDocument-8
* binaryXML-30
2.1 xmlProfiles-29
1. xmlProfiles-29
1. Completed action NW 2003/01/06: Write up a
second draft of the TAG position based on
original proposal.
2. See email from Chris on options for ID
3. See email from NW (TAG-only) on ID
attributes.
4. See comments from Paul Grosso to treat
xml:id as separate spec.
[Ian]
TB: I'm still uncomfortable here since CL
claims there's a big issue here that needs
solving. Not in my experience. I think we need
more feedback from the community.
Proposal: Move NW proposal to www-tag
David O is leaving the meeting now.
DC: If NW's skunkworks proposal, please don't
send out in TAG name. Minimal effort for who?
not the readers of the XML specs. There are a
lot more readers than writers.
NW: I'm not suggesting this as the sum total;
this is "one extreme."
TBL observes that NW's proposal amounts to a
diff.
TB: I suggest proposing to www-tag, but with a
status section that we don't know whether it
represents TAG consensus, but well-enough
cooked to get feedback.
Resolved: Send NW proposal (0012) to www-tag
Action NW: Forward proposal to www-tag.
2.2 namespaceDocument-8
1. namespaceDocument-8
1. Please read NW summary of the following
proposals:
1. RDDL Proposal from Tim Bray.
2. RDDL Proposal from Chris Wilper
3. RDDL Proposal from TBL
4. RDDL Proposal from Jonathan Borden
5. RDDL Proposal from Micah Dubinko
6. RDDL Proposal from Sandro Hawke
SW: Any discussion of NW summary?
NW: I suggested one to pick.
TB: I am increasingly convinced that there
would be benefit to the community if W3C
published a Rec that was not mandatory, but
could be used when appropriate to improve
interoperability. I am favoring Sandro's
proposal. Like NW, I could live with "none".
IJ: Do you really want the full machinery of
the Rec track, or would Note suffice?
TB: Rec track. If we think this should go to
Rec, we can either write it or go back to the
Director/AC on which other group should
address.
TB Proposal: Suggest that W3C take one of
these proposals and publish as a W3C Rec.
PC: I think I prefer publishing as a WD with a
status section with the intention to take to
Rec. I would prefer WD over Note to get wider
review.
[No support to publish directly as Note.]
[Some discussion of splitting big pieces into
smaller documents to advance them according to
ripeness.]
TB Proposal: The TAG thinks W3C should proceed
with a recommendation for a data format for
namespace docs (not compulsory) and that such
a document should follow the Rec track
process. The content of the document should be
taken from the RDDL challenge proposals; they
are
isomorphic in technical content.
NW: Seconded.
[TBray]
TimBL: s/The content/The initial content/
+1
[TimBL]
in favor
[PaulC]
Paul is in favor.
[Ian]
In favor: TB, PC, TBL, NW
Objections: None.
[Roy]
+1
[Ian]
Abstentions: DC, SW
[We note that DO is no longer in the meeting]
Resolved: The TAG thinks W3C should proceed
with a recommendation for a data format for
namespace docs (not compulsory) and that such
a document should follow the Rec track
process. The initial content of the document
should be taken from the RDDL challenge
proposals; they are isomorphic in tecnical
content.
Action PC, TB: Write up a WD.
[Enlisting the help of the contributors]
DC: Please include drawbacks in the draft. For
example, using an HTML dialect (ala Sandro's
proposal) for the RDF namespace wouldn't work,
I don't think.
2.3 binaryXML-30
1. binaryXML-30
1. Action CL 2002/12/02: Write up problem
statement about binary XML; send to www-tag.
[Ian]
TB: There seem to be real requirements out
there to be able to send info around in a
manner that is either (1) more compact or (2)
more rapidly parsed. I am convinced by some
usage scenarios. I am, however, unconvinced
that there is a single format that will meet
the needs of the various applications. There
is work in this area in MPEG, but that's
loaded with IPR problems. I think this should
be a do-nothing unless somebody comes forward
with a plausible candidate. I'd be reluctant
to pour energy into this without a candidate
that solves a broad range of problems and is
Royalty-Free.
TBL: The discussion has been about
decompression on the fly on small devices. The
only time it's interesting - send message to
someone with whom you share a knowledge of
namespaces. [Scribe thinks TBL talked about
partial evaluation as approach to problem in
some cases.]This is not generic magic you can
sprinkle over XML documents generally.
IJ thinks TB was referring to this email from
Robin Berton.
[DanConn]
TBL's comments seem quite similar to my
comments on trust boundaries and binary XML...
[Ian]
SW: Is this an arch issue or an engineering
document?
DC: Engineering, but applies to a number of
WGs.
TB: I think we should defend XML as a
generalized information format; prevent people
from retreating to specialized formats.
[TimBL]
The idea is that you can't compact general
things without some header info which explains
what the short things will mean. Compression
is available for desktop-sized machines in the
general case, so one does not need binary XML
in that case. The need is when you have a
small device which cannot hold the
decomression tree. Then, a prior knowledge of
the XML namespaces it uses would allow one to
make a faster encoding.
[Ian]
PC: A number of people in Microsoft are
interested in this problem; I am looking
forward to CL action is completed.
[TBray]
what TimBL said... but compression
effectiveness depends on msg size, with big
enough msgs you could compress effectively &
self-descriptively
2.4 Postponed
1. IRIEverywhere-27
1. Action MD and CL 2002/11/18: Write up text
about IRIEverywhere-27 for spec writers to
include in their spec.
2. Action CL 2002/11/18: Write up finding for
IRIEverywhere-27 (from TB and TBL, a/b/c),
to include MD's text.
2.5 Findings in progress, architecture document
See also: findings.
1. Findings in progress:
1. deepLinking-25
1. Action TB 2002/09/09: Revise "Deep
Linking" in light of 9 Sep minutes.
2. URIEquivalence-15
1. TB's "How to Compare Uniform Resource
Identifiers" draft finding.
Completed Action DC 2002/01/06: I
expect to review this (done).
2. 6 Dec 2002 Editor's Draft of Arch Doc (new):
1. Action CL 2002/09/25: Redraft section 3
based on resolutions of 18 Nov 2002 ftf
meeting.
2. Complete review of TBs proposed principles
CP9, CP10 and CP11
________________________________________________
Ian Jacobs for Stuart Williams and TimBL
Last modified: $Date: 2003/01/13 22:01:53 $
--
Ian Jacobs (ij@w3.org) http://www.w3.org/People/Jacobs
Tel: +1 718 260-9447
Received on Monday, 13 January 2003 17:05:02 UTC