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
- Roll call: SW (Chair), TBL, TB, DC, NW, PC, RF, DO (partial), IJ
(Scribe). Regrets: CL.
- Accepted 6 Jan minutes (with
corrections suggested by CL and DC).
- Accepted this agenda
- 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".
- Upcoming meetings: 3 Feb (brief welcome to newcomers). No meeting 10
Jan.
1.1 Completed actions
- SW 2002/11/18: Organize a special-interest teleconf for discussion of
this issue on linking.
- 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
- 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
- Completed action NW 2003/01/06: Write up a second draft of the TAG
position based on original
proposal.
- See email from Chris on options
for ID
- See email from NW (TAG-only) on ID
attributes.
- 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.
- namespaceDocument-8
- Please read NW
summary of the following proposals:
- RDDL
Proposal from Tim Bray.
- RDDL
Proposal from Chris Wilper
- RDDL Proposal from
TBL
- RDDL
Proposal from Jonathan Borden
- RDDL
Proposal from Micah Dubinko
- 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.
- binaryXML-30
- 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
- IRIEverywhere-27
- Action MD and CL 2002/11/18: Write up text about IRIEverywhere-27
for spec writers to include in their spec.
- 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.
- Findings in progress:
- deepLinking-25
- Action TB 2002/09/09: Revise "Deep
Linking" in light of 9 Sep
minutes.
- URIEquivalence-15
- TB's "How to
Compare Uniform Resource Identifiers" draft finding.
Completed Action DC 2002/01/06: I expect to review this (done).
- 6 Dec 2002 Editor's Draft of
Arch Doc (new):
- Action CL 2002/09/25: Redraft section 3 based on resolutions of 18 Nov 2002 ftf
meeting.
- Complete review of TBs proposed
principles CP9, CP10 and CP11
Ian Jacobs for Stuart Williams and TimBL
Last modified: $Date: 2003/01/13 22:04:43 $