W3C | TAG | www-tag | Agenda (Member)

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, Chris Lilley, Ian Jacobs (Scribe)

This meeting was organized as part of discussion of TAG issue xlinkScope-23: What is the scope of using XLink?

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 Tim Bray email on inference of xlink:type.

[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 CLink/CSS-style solution

[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 comments from Misha Wolf and comments from Chris Lilley.

[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: 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 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 HLink and CLink would be good solutions as well.

[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 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 .

[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?