- From: Ian B. Jacobs <ij@w3.org>
- Date: Wed, 22 Jan 2003 11:48:31 +0100
- To: www-tag@w3.org
Hello,
Minutes of the 16 Jan meeting on linking in XML (organized
by the TAG) are available at HTML [1] and as text below.
Many thanks to the participants.
_ Ian
[1] http://www.w3.org/2003/01/16-tag-xlink
===================================================================
Minutes of 16 Jan 2003 discussion on Linking in XML Documents
Participants: Stuart Williams (Chair), Liam Quin, Henry Thompson,
Steven Pemberton, Lloyd Rutledge, Paul Grosso, Tantek Çelik, Jonny
Axelsson, Brad Porter, Micah Dubinko, Tim Bray, Ian Jacobs, Tim
Berners-Lee, Norm Walsh, Ian Jacobs (Scribe)
This meeting was organized as part of discussion of TAG issue
[5]xlinkScope-23: What is the scope of using XLink?
[5] http://www.w3.org/2001/tag/ilist#xlinkScope-23
Minutes
[Ian]
PG: We should ask ourselves whether links are primitive things
or less primitive (like style). Depending on whether links are
"style-ish", then I think it makes sense to have a language
that applies link-ness. If not, then it makes more sense to
have links hardwired (i.e., in namespace)
TÇ: I think there's a little of both...both presentation and
fundamental semantics in linking. Some semantics may also
depend on the language instance.
[TB agrees with TÇ]
TB: I'd probably be uncomfortable with moving linking info to
external resources (i.e., not right inline)
HT: Linking semantics is attributed, not intrinsic. Linking is
low-level, but attributed and at user option. Close parallel to
"id-ness" and binding to the letters "I-D".
[TBray]
hmm... <img src= is by default on, although in principle at
user option
[Ian]
HT: I think that some form of explicit signal is required that
something is a link. A lightweight signal is important. I have
a serious allergy to yet-another-little-language. Whether
hidden in a process inst. or in another doc. Let's use existing
languages.
[Zakim]
Liam, you wanted to suggest 3 kinds of link, and we don't need
to solve all 3
[Ian]
LQ: definitions
1. Two or more resources are linked if there's a relationship
between (among) them.
2. A "displayed link" is a rendered link.
3. A "markup link" is a way of representing a link in markup
(whether explicit or deduced).
LQ: We don't have to solve all possible ways of deducing links.
Micah: XForms philosophy regarding author's intent; important
to capture intent in markup. Details like "has to happen on
load" is more related to presentation.
[Ian]
TÇ: If something is likely to require changes for different
devices, media, or users, that is likely to be presentational
and should be considered separate from "content".
[TBray]
what Tantek said
[Tantek]
Concept: if something is likely to require changes for
different devices, different media, or different users due to
disabilities, that something is very likely presentational, and
should remain separate and distinct from the markup of content.
[Zakim]
TimBL, you wanted to suggest a tire hanging from the branch
[Ian]
TBL: We need to have a simple solution for authors (e.g.,
authors used to HTML). There needs to be a very simple core. No
levels of indirection unless we need them.
BP: On content v. presentation - In the voice dialog, the
active linking is not exposed to the user at all from a
presentation standpoint. The fact that the user may link
between two locations is transparent to the user. There are
other ways to associate resources; does linking include all
mechanisms?
[ht]
browsing isn't the only application, and follow-me isn't the
only semantics
[Zakim]
TBray, you wanted to ask for briefing on state of discussion in
HTML WG and which direction they think HTML ought to go (after
this thread)
[Ian]
TB: HTML WG has a special status, IMO, since HTML so widely
deployed.
SP: XHTML 2.0 has basically two attributes: (1) href-style and
(2) embedding. The way the xhtml family is designed, another
module could come along and want to add its own linking
attributes.
TB: Do you see urgently needed addition to linking semantics
from xhtml 1.*?
SP: Fine for the present.
SW: Relaxed backwards compatibility constraints and impact on
this context?
SP: Our objections to using XLink were not related to backwards
compatibility.
LR: The backwards compatibility issue is multiple attributes
that relate to linking. Hard to deprecate due to current
deployment. We have deprecated esoteric features. Primary
structural challenge to bringing XLink into XHTML 2.0 is
multiple linking attributes.
[Zakim]
TimBL, you wanted to say that from my personal point of view,
this meeting needs to resolve linking from the user experience.
[Ian]
TBL: I consider this meeting to be focused on links that are in
and out of user experience. I'm less interested here in general
relationships between resources; out of scope.
NW: I agree with TBL on scope here: user experience.
[Zakim]
Ht, you wanted to say that making easy things easy is fine but
hard things have to be possible
[Ian]
HT: Outline of a partial solution: (a) Simple things should be
simple and should stay as simple as html:a. (b) I have no
problem with a design that grandfathers in a bare-minimum
syntax to allow old syntax. I think not simple if each WG
redefines attribs in local namespace with same name and
semantics. Some grandfathering is good. XLink should have
predefined a linking element. I don't want to see the
multi-ended solution, for links with more complexity, to be
completely divorced from that story. At the end of the day, we
may agree that new infoset properties are the right way to
merge the stories we need to accommodate.
TB: Another xlink change suggestion: infer xlink type attribute
to reduce verbosity.
[ht]
HT endorses TB's suggestion
[Ian]
TB: On the question of multiple attributes with linking
semantics - there are some strong motivators for using elements
instead when multiple links required.
MD: Some complex stuff may not need standardization.
See [6]Tim Bray email on inference of xlink:type.
[6] http://lists.w3.org/Archives/Public/www-tag/2002Oct/0073.html
[Tantek]
IMHO User experience aspect includes two things: ease or
authoring / usability, and presentation. Current generic
solutions are poor at both. In terms of ease of authoring, the
syntactic vinegar and markupJunk problem has already been
documented.
[ht]
I agree that committing to supporting multiple attribute-based
links on one element is a corner case that should not be
allowed to drive the solution
[Tantek]
In terms of presentation, taking in mind my above straw concept
about separation of presentation and markup, the current
generic solution fails very badly by mixing in linking
presentation and linking semantics. The show and actuate
attributes being the prime offenders.
[Zakim]
Steven, you wanted to address attribute/element question
[Ian]
SP regarding element approach to multiple links: We should have
solutions that suit various people's style of markup.
LR: Perhaps we can have a simple xlink attribute, or to provide
guidance on what to do when there are multiple attribs on same
element that have linking semantics. Not sure that always
having multiple link attribs always a problem.
[Zakim]
Ht, you wanted to disagree about multiple flowers
[Ian]
HT: Design should not try to be all things to all people.
[steven]
Not necessarily, but should attempt
[mdubinko]
<image src="some URI" href="some URI"/>
[Ian]
HT: Corner case of multiple attributes with link semantics on
same element should not drive design.
SP: I didn't suggest that it should.
HT: But it may.
[TBray]
Just for the record: I am prepared to argue that
multiple-attribute inevitably brings up serious design problems
[Ian]
NW: I think 1000-flowers approach not best here. I think there
are some simple linking semantics that are well-entrenched in
the Web. I'd rather see a simple core that will work for the
most common use cases.
[mdubinko]
Ian, Norm was referring to my earlier comments: 'simple core
applies horizontally, app-specific markup for vertical bits'
[steven]
Designing around half the world's needs will guarantee problems
[Ian]
SW: If we ask another group to do more work in this space, what
would we be asking them to address?
TB notes that XLink WG has closed.
[jax]
Adding to the multiple link scenario; HTML 4 example with
longdesc and src
[TBray]
jax, I think the src/longdesc design is a real problem,
starting with i18n issues
[Ian]
LR: The choice of group that you ask to do this work will
greatly affect the work.
[steven]
HTML WG is chartered to do it
[Ian]
TÇ: Value to pursuing more than one solution at the same time.
Each solution can benefit from improvements of other
approaches. Foolish to pursue just one solution that tries to
satisfy all constraints.
[Zakim]
TimBL, you wanted to suggest HTML and SVG and Math are all
relevant.
[Ian]
TBL: What ought to happen - solve the mixed namespaces problem.
The solution needs to target more than, say, just XHTML.
[steven]
HTML WG would be happy with [7]CLink/CSS-style solution
[7] http://people.opera.com/howcome/2000/css3/clink-nov-6.html
[Tantek]
IMHO a key portion of solving the mixed namespaces problem is
solving the syntactic vinegar / markupJunk problem that comes
along with namespaces. And I agree that the mixed namespaces
problem needs to be solved.
[Ian]
MD: Yes to multiple namespace docs (cf Xforms). The new wave of
modular XML vocabs will constrain the way that you can design a
linking language. Need to take into account unforeseen
combinations (including two linking attribs on same element).
[Zakim]
Liam, you wanted to agree with Tim, this is the way XML on the
web must go
[Ian]
LQ, TB: Yes to multiple namespace concern.
TB: That suggests that there's a good argument for the
existence of an xlink-like option.
[Tantek]
Straw proposal: Simple embed vs. hyperlink distinction as
schema datatypes.
[Ian]
TB: Sounds like an xlink approach that removes some
presentation things would be a big win.
[Zakim]
Ht, you wanted to say that XML Schema easily provides the
resource (type definitions) to allow a wide range of languages
to share a linking syntax and/or semantics
[steven]
No one has argued against a linking vocab to avoid having to
design your own, I think
[Ian]
HT: Mechanism of type definition provided by XML Schema gives a
way for many languages to share a resource without committing
to what the names of the elements or even attributes have to
be.
HT: People don't all have to schema-validate!
HT: Infoset is the place for shared linking semantics. Schema
is the place for shared linking syntax.
[Zakim]
TimBL, you wanted to probe a bit where this attribute-oriented
approach is driven by. Mixing attributes is inherently messy in
XML, while element nesting is not. Therefore a linking language
fro example should provide elements rather than attributes. Why
not?
[Ian]
TBL: Is the issue with element approach verbosity?
[ht]
infoset is a way of tying _recs_ together
[Zakim]
Liam, you wanted to speak on elements vs attributes
[Ian]
LQ on attributes: Philosophical difference depending on how one
perceives the link.
[TBray]
What I said: infoset is nice but syntax is essential
[ht]
I think Liam has misunderstood Tim's point -- not that you
shouldn't use attributes for links, but that to compose links
you have to nest their signalling elements, not merge them
[mdubinko]
Using 'href' or 'someprefix:href' for EVERY kind of link
particularly causes problems in combining languages
[Ian]
LQ: Verbosity is important, backwards compatibility important.
But philosophy is important. Neither xml nor namespaces clear
about mixing same attributes on element.
NW: Problem with infoset solution is that there's no common
markup idiom for users. Not a complete solution if each
language chooses different syntax.
[Tantek]
Sacrificing usability for syntactic universality is also bad.
[Ian]
LR: Simplicity for authors important. One attribute can be
simpler than nested elements. e.g., deployment of smil may have
been easier due to attribute focus.
[Zakim]
Steven, you wanted to talk about content models
[Ian]
SP on element v attribute approach: I understand motivation for
both approaches. W3C should not say "This is the only way to
design XML."
[PGrosso]
But "allowing different ways to design XML" depends on whether
you think this is a basic thing like xinclude or a variable
thing like style.
If linking is basic to the Web, then allowing alternate designs
may not be the best way to go.
[Ian]
SP: Consider P3P. You can't define a P3P policy for an XML
document today. If we design a language where an element is
only allowed to have one attribute that has a URI value, we
might cut off the possibility of extending XML to add P3P
policies. Summary - easier to add attributes than to add
elements.
TB: See CL and MW comments on problems in doing multiple end
links using attribute syntax. I've not seen responses to those
posting. View source metric important for hyperlinking
[Zakim]
TimBL, you wanted to point out that that adding that attribute
was not a link.
[Ian]
TBL: We are looking here for a way to include a user-accessible
link.
[TBray]
I said that I think you can do an element-based syntax for
multi-ended links that avoids the "longdesc" problems and is
still perfectly comprehensible by ordinary people
[Ian]
TBL: I think P3P/XML example out of scope; there are lots of
things that have URIs.
TÇ: Are attribute args discussed here more hypothetical than
practical?
TB: I think real problems.
[Tantek]
e.g. <img href="http://gohere.example.org/"
src="http://embedthis.example.org/" /> seems to work fine.
[Ian]
TB: At the end of the day we want to enrich hyperlinks. If you
have attribute-based hyperlinks, you have attribs about
attributes. That is hairy. Internationalization is another
example; when you want to have more than one instance of
something, you should do through elements. See [8]comments from
Misha Wolf and [9]comments from Chris Lilley.
[8] http://lists.w3.org/Archives/Public/www-tag/2002Sep/0288.html
[9] http://lists.w3.org/Archives/Public/www-tag/2002Oct/0141.html
[Zakim]
Ht, you wanted to say there's a difference between
this-is-an-URL and this-is-a-link
[Ian]
HT: At the heart of this issue is acknowledging distinction
between "this is a URI" and "this is a link". Being a URI is
not all there is to being a link. We'd probably agree that
xlink went too far by including presentation info. Can we reach
agreement that one needs to know more than a URI to know about
a hyperlink?
TÇ: Allow multiple solutions to proceed ("1000 flowers"). On
tech args against multiple attributes - most of these arguments
seem to depend on assumption of an ONLY-ATTRIBUTE solution.
[IJ reminds folks that parallel was drawn to style in HTML:
style attribute, STYLE element, and external style sheets.]
[TBray]
TBray:
[10]http://lists.w3.org/Archives/Public/www-tag/2002Sep/0121.ht
ml
[10] http://lists.w3.org/Archives/Public/www-tag/2002Sep/0121.html
[Ian]
HT: We could initiate an effort to design a subset that meets
needs of major players. Issue then of whether to recommend or
mandate those solutions.
[TBray]
TBray
[11]http://lists.w3.org/Archives/Public/www-tag/2002Sep/0284.ht
ml
[11] http://lists.w3.org/Archives/Public/www-tag/2002Sep/0284.html
[Tantek]
Using multiple attributes for linking does NOT preclude using
multiple elements for links.
Allow multiple attributes for simpler cases, and encourage
multiple elements for more complex cases, e.g. links to 20
different natural language versions of a document.
[Ian]
LR: Could allow authors to be attributionists and format
designers to be elementists.
[Tantek]
HTML does this today, with various linking attributes and with
the <link> element.
[Ian]
LR: I think a mapping between the two would meet the needs of
HTML WG. Add a layer that does mapping from elements to
attributes.
TB proposal:
1. Seems to be agreement that mixed namespace docs are a problem
we have to face. Common vocab a good goal.
2. Reduce XLink, with more derivation of attributes; radical
removal of presentation/behavior. Would that meet lots of
requirements?
TB: Who would do this work?
[Ian]
SP: I think that [12]HLink and [13]CLink would be good
solutions as well.
[12] http://www.w3.org/TR/hlink/
[13] http://people.opera.com/howcome/2000/css3/clink-nov-6.html
[ht]
ht agrees with Tim Bray's proposal
[Ian]
SP: TB's design not perfect since doesn't fulfill design goal
of not requiring changes to instances (see [14]XLink
Requirement B.2). You should be able to infer links without
having to put the links in the document.
BP: It's important to specify and evangelize importance of link
metadata .
[14] http://www.w3.org/TR/NOTE-xlink-req/#syntax
[ht]
there is an integrity issue wrt inline vs. offboard signalling
of linkness
[TBray]
problem with CLink is that it's external-only (right?) makes
life harder for spiders
[Zakim]
TimBL, you wanted to add another requirement - that you should
be able to infer links with only the document available. Also,
you wanted to note that there is a separate meeting to have
about embedded metatdata in HTML etc
[Ian]
TBL: Should be able to infer links with only the document
available. That complements SP's requirement.
[TBray]
TBL wants potential for 100% self-descriptive links with no
call-out to another resource
[ht]
this is the View Source argument again
[Ian]
[TBL recaps view source benefits]
TBL: I'm in favor of fewer indirections to find out something
is a link. Attempt to meet the requirement of multiple links
has been done through generalization. A new xlink should have a
(1) simple syntax that should be extensible; element-based (2)
backwards compatible to HTML stuff bolted on; don't need to do
for other content than HTML.
SP: You can't do view source easily for presentation stuff.
Shouldn't be a requirement for every piece of information you
do in XML. A layered solution will give you view source
possibility.
[Norm]
Presentation is not semantics.
[Tantek]
And semantics should not require a particular presentation.
[Norm]
Yep
[mdubinko]
the single main document should express intent, any related
resources ought to be supplemental
[TimBL]
To clarify - I was not ruling out style sheets..... for style
[Zakim]
Liam, you wanted to urge static semantics ala tim but point out
the style sheets can already impute linkness
[Ian]
LQ: I agree with TBL on view source value.
[Tantek]
I think it is important not only to tell whether "it is a
link", but whether it is a "hyperlink reference" or an "embed".
I'm not sure that other distinctions are necessary from the
view source perspective.
[steven]
But I was saying: the show source argument doesn't hold for
styling, so why is show source so important?
[ht]
steven: because style is less implicated in document function
than linking is, by a significant amount
[Tantek]
Another way to think of it is the "deep copy" example: when
performing a deep copy of a compound document, you need to know
which elements to copy with a document, and which not to. This
corresponds 1:1 to the embed/hyperlink distinction.
[Ian]
LQ: Multiple vocabs should be able to share static semantics.
We should not rule out style sheet-type mechanism to impute
linking semantics. There's a descriptive value of schemas here;
mapping into xlink. Need to make sure that xlink ends up being
power enough to be mapped into.
[TimBL]
re: "But I was saying: the show source argument doesn't hold
for styling, so why is show source so important?" I think that
the community has a fairly well defined concept of separation
of form and content.
[Liam]
agreed with separation, understanding of that is growing fast
[TBray]
there are no absolutes: separation of form/content brings
enough benefits so as to justify lossage on "view source" front
but i'm not sure that's true for linkage
[ht]
ht agrees
[Ian]
Scribe uncertain, but thinks he talked here about analogy with
style sheets in HTML: several mechanisms have proved useful for
different scenarios. Scribe (and HT) believe this point was
made by Michael Sperberg-McQueen.
[PGrosso]
Per what Ian is saying, but that depends on whether linking is
basic like xinclude or more like style.
[Ian]
IJ: What is drawback to allowing both element and attribute
approach? Do we have documented drawbacks for style flexibility
in HTML?
PG: Gets back to my point about whether linking more like
style.
TB: I like CLink (elegant) but nervous that will make life
harder for robots, spiders.
[mdubinko]
a trend towards fewer is better, but not an absolute 'MUST BE
ONLY ONE' requirement
[Ian]
LR clarifies use of CSS-like approach of external assignment of
semantics.
[Norm]
There's no way to make there only be one, but there could be
one that we agree to use for some kinds of linking.
[Ian]
TBL: What's the document for in the case where link semantics
applied externally?
[TBray]
the Web brought a new thing into the world: the notion that
content should contain embedded actionable pointers to other
content. You don't hae that it's not the web any more
[Norm]
What TBray said.
[jax]
It isn't to add the semantics link sheet is useful
[steven]
agree with Lloyd
[jax]
It is for the user to handle what links to interact with, and
how
[Ian]
LR: External sheets allow later application of link semantics
without changing content. I think there are situations where
people will want to be able to do external application of
semantics.
[ht]
Why isn't Schema already sufficient for that goal?
[jax]
There *is* a possible downside to link styling in that you
could use link styling in a way that is unobvious
[Ian]
LQ: I agree with LR's comments. We also have to bear in mind
that when we designed XML we had lots of experience with
documents, less with data. More research should be done on
linking...I'm uneasy with PG's proposal to have one way...we
may need more. Extended XML Schema better than link sheet.
[jax]
that is the same argument as with XML everyone will make their
own tags, and interoperability is out the door. Didn't happen,
won't happen.
[Lloyd]
Agree with Liam, but we do want one way to define underlying
*semantics*
[Ian]
IJ summarizing a proposal: allow element and attribute
approach, highlight caveats of each approach; forget link
sheets for now.
[Liam]
hearhear, Ian.
[ht]
HLink _is_ a link sheet proposal, you can't argue against link
sheets and for HLink
[PGrosso]
Right, what HT just said.
[Ian]
IJ: I think that the multiple ways of specifying style in HTML
show that multiple approaches can be valuable.
HT: I like TB's proposal better than IJ's - I don't think IJ's
analogy to style works.
[TBray]
Reminder of part (b) of earlier proposal: Reduce XLink, with
more derivation of attributes; radical removal of
presentation/behavior. Would that meet lots of requirements?
[ht]
add built-in element
[TimBL]
If you can do it with one method that is a lot better than
doing it with three.
[ht]
I don't accept that requirement (don't modify the instance)
[Ian]
IJ: The objection to TB's approach was you can't avoid
modifying the instance.
[Tantek]
I prefer Ian Jacob's proposal as a starting point. I think he
captured more of what is needed.
[Ian]
SP: Current de facto solutions (1) CLink-like [Opera], (2) XBL
[Mozilla], (3) Behaviors [IE]. Advantage to link sheet approach
is that you don't need to build more knowledge into browser.
TBL: I like TB's proposal. Please add "html:a" to xlink in TB's
proposal.
[steven]
I don't think that that helps
[Zakim]
TimBL, you wanted to ask - Does TB's solution allow one to make
a link:a anchor elements in the xlink namespace
[TimBL]
TB: I wouldn't want to define things at such a high level of
detail at this stage.
[Ian]
NW: My objection to the CLink/HLink approaches - I want links
to be first class things. As chair of Docbook TC, we've been
waiting for years to adopt an XLink solution. I'd like the
solution to not require an external mechanism for identifying
links.
[steven]
Sounds like a clear lack of consensus here
[Norm]
Lloyd: I don't care if the style is totally lost, I want the
link to persist.
[steven]
I don't see how they are different. If you have a clink style,
you can use it to define an xlink: style. End of story
[Lloyd]
Norm: Point is style is maintained and dependable. So can
links.
[Ian]
HT: Please poll folks to find out priority of internal v.
external link info.
[Norm]
No, style is not maintained and dependable. And I don't care if
style is lost. But I don't want links to be lost, or confused,
or changed.
[Ian]
TB: Summarizing - links self-describing in the instance or
preference for link sheets?
Internal: TBL, SW, PG, NW, TB, HT
[Tantek]
Allow Internal but NOT require.
[jax]
second that
[Ian]
IJ: Question is PREFERENCE for internal or external (I think)
[Poll killed]
TÇ: I think solution of internal link markup is fine, but don't
exclude other approaches.
[ht]
Strongly disagree
[Ian]
JAX: It's fine to have linking mechanism embedded. What HLink
will add is the ability to say later something that the format
didn't or couldn't say. The ability of styling linking doesn't
mean you shouldn't be able to specify things int he markup.
[Tantek]
Some authors (and language designers) wish to keep as much of
the "markupJunk" out of document content as possible. This is a
real need.
[Zakim]
Liam, you wanted to claim mixing namespaces is a higher issue
[ht]
That's not the way I read HLink -- without the link sheet there
is _no way_ to tell what elements are links
please can we talk about who does this?
[Norm]
Liam: I don't believe I was conflating the two issues
[Liam]
Norm, ok, sorry
[Tantek]
ht: that's why Steven has said in the past that HLink and XLink
are not different solutions, but part of one solution. (sorry
if I misquoted you Steven).
[Lloyd]
also thinks this has been useful.
[Ian]
TB: Let's figure out what work we can do to move forward.
LR: Let HLink go forward with certain requirements or
guidelines.
[PGrosso]
If we don't decide whether linkness is first class or more like
style, then I don't think we've moved forward.
[ht]
I am not happy with that proposal
[Norm]
Yeah, what PGrosso said, I think.
[TBray]
mark me -1 on that
[steven]
I had been told that XML2002 had moved the discussion forward
(I wasn't there)
[mdubinko]
links are first-class, link syntax is not (cf historical 'href'
attribute)
[Ian]
TBL: Is the HTML WG happy to use a link namespace on things
that are links.
[steven]
It is not just about HTML. Also SYMM, XForms. It is about a
general solution
[Norm]
steven: the XML2002 discussion was lively, but I don't feel at
the end of the day that we moved very far. Alas, I was chairing
and unable to take minutes.
[steven]
Others told me that there was a feeling of generating consensus
[Norm]
steven: I fear I failed to detect what that consensus was.
Perhaps I missed it
[steven]
OK Norm
[Ian]
[IJ: I think HTML WG has said that namespace prefix not a major
problem.]
[steven]
Not a problem per se. HTML WG is not against namespaces
[Ian]
TBL: Most important is to ensure that simple solution exists.
HT: The venue for taking this forward?
[TimBL]
It is always easier to take a simple thing and add complexity
than to do the reverse.
[TBray]
and isolating areas of disagreement is useful!
[steven]
And I think that those areas are the source of the problem
[Norm]
steven: on reflection, it was probably a failure on my part to
do a good wrap-up at xml 2002 and write down the consensus
opinions.
[Zakim]
Liam, you wanted to affirm tf
TBray, you wanted to say we have successfully isolated areas of
technical disagreement (1) linkage in-doc vs external, (2)
desirability of multi-attribute links
[Ian]
SW: Where should followup discussion take place?
Proposed www-tag: +1 from HT, TB, MD
Proposed BOF during week of technical plenary: TB, HT, TÇ, BP,
JAX, NW
HT: But during the Wednesday plenary is a bad idea.
[Zakim]
Tantek, you wanted to say why only one "venue"? Why not let
multiple solutions move forward for the moment at least?
--
Ian Jacobs (ij@w3.org) http://www.w3.org/People/Jacobs
Tel: +1 718 260-9447
Received on Wednesday, 22 January 2003 05:48:32 UTC