[Minutes] 16 Jan 2003 Linking in XML documents


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


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

           hmm... <img src= is by default on, although in principle at
           user option

           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

           Liam, you wanted to suggest 3 kinds of link, and we don't need
           to solve all 3

           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.

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

           what Tantek said

           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.

           TimBL, you wanted to suggest a tire hanging from the branch

           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

           browsing isn't the only application, and follow-me isn't the
           only semantics

           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)

           TB: HTML WG has a special status, IMO, since HTML so widely
           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
           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
           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.

           TimBL, you wanted to say that from my personal point of view,
           this meeting needs to resolve linking from the user experience.

           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.

           Ht, you wanted to say that making easy things easy is fine but
           hard things have to be possible

           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 endorses TB's suggestion

           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

           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

           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

           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.

           Steven, you wanted to address attribute/element question

           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.

           Ht, you wanted to disagree about multiple flowers

           HT: Design should not try to be all things to all people.

           Not necessarily, but should attempt

           <image src="some URI" href="some URI"/>

           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.

           Just for the record: I am prepared to argue that
           multiple-attribute inevitably brings up serious design problems

           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.

           Ian, Norm was referring to my earlier comments: 'simple core
           applies horizontally, app-specific markup for vertical bits'

           Designing around half the world's needs will guarantee problems

           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.

           Adding to the multiple link scenario; HTML 4 example with
           longdesc and src

           jax, I think the src/longdesc design is a real problem,
           starting with i18n issues

           LR: The choice of group that you ask to do this work will
           greatly affect the work.

           HTML WG is chartered to do it

           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.

           TimBL, you wanted to suggest HTML and SVG and Math are all

           TBL: What ought to happen - solve the mixed namespaces problem.
           The solution needs to target more than, say, just XHTML.

           HTML WG would be happy with [7]CLink/CSS-style solution

       [7] http://people.opera.com/howcome/2000/css3/clink-nov-6.html

           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.

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

           Liam, you wanted to agree with Tim, this is the way XML on the
           web must go

           LQ, TB: Yes to multiple namespace concern.
           TB: That suggests that there's a good argument for the
           existence of an xlink-like option.

           Straw proposal: Simple embed vs. hyperlink distinction as
           schema datatypes.

           TB: Sounds like an xlink approach that removes some
           presentation things would be a big win.

           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

           No one has argued against a linking vocab to avoid having to
           design your own, I think

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

           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

           TBL: Is the issue with element approach verbosity?

           infoset is a way of tying _recs_ together

           Liam, you wanted to speak on elements vs attributes

           LQ on attributes: Philosophical difference depending on how one
           perceives the link.

           What I said: infoset is nice but syntax is essential

           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

           Using 'href' or 'someprefix:href' for EVERY kind of link
           particularly causes problems in combining languages

           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.

           Sacrificing usability for syntactic universality is also bad.

           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.

           Steven, you wanted to talk about content models

           SP on element v attribute approach: I understand motivation for
           both approaches. W3C should not say "This is the only way to
           design XML."

           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.

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

           TimBL, you wanted to point out that that adding that attribute
           was not a link.

           TBL: We are looking here for a way to include a user-accessible

           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

           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
           TB: I think real problems.

           e.g. <img href="http://gohere.example.org/"
           src="http://embedthis.example.org/" /> seems to work fine.

           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

           Ht, you wanted to say there's a difference between
           this-is-an-URL and this-is-a-link

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


      [10] http://lists.w3.org/Archives/Public/www-tag/2002Sep/0121.html

           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.


      [11] http://lists.w3.org/Archives/Public/www-tag/2002Sep/0284.html

           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.

           LR: Could allow authors to be attributionists and format
           designers to be elementists.

           HTML does this today, with various linking attributes and with
           the <link> element.

           LR: I think a mapping between the two would meet the needs of
           HTML WG. Add a layer that does mapping from elements to
           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

           TB: Who would do this work?

           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 agrees with Tim Bray's proposal

           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

           there is an integrity issue wrt inline vs. offboard signalling
           of linkness

           problem with CLink is that it's external-only (right?) makes
           life harder for spiders

           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

           TBL: Should be able to infer links with only the document
           available. That complements SP's requirement.

           TBL wants potential for 100% self-descriptive links with no
           call-out to another resource

           this is the View Source argument again

           [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

           Presentation is not semantics.

           And semantics should not require a particular presentation.


           the single main document should express intent, any related
           resources ought to be supplemental

           To clarify - I was not ruling out style sheets..... for style

           Liam, you wanted to urge static semantics ala tim but point out
           the style sheets can already impute linkness

           LQ: I agree with TBL on view source value.

           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.

           But I was saying: the show source argument doesn't hold for
           styling, so why is show source so important?

           steven: because style is less implicated in document function
           than linking is, by a significant amount

           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.

           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.

           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.

           agreed with separation, understanding of that is growing fast

           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 agrees

           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.

           Per what Ian is saying, but that depends on whether linking is
           basic like xinclude or more like style.

           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
           TB: I like CLink (elegant) but nervous that will make life
           harder for robots, spiders.

           a trend towards fewer is better, but not an absolute 'MUST BE
           ONLY ONE' requirement

           LR clarifies use of CSS-like approach of external assignment of

           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.

           TBL: What's the document for in the case where link semantics
           applied externally?

           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

           What TBray said.

           It isn't to add the semantics link sheet is useful

           agree with Lloyd

           It is for the user to handle what links to interact with, and

           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

           Why isn't Schema already sufficient for that goal?

           There *is* a possible downside to link styling in that you
           could use link styling in a way that is unobvious

           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.

           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.

           Agree with Liam, but we do want one way to define underlying

           IJ summarizing a proposal: allow element and attribute
           approach, highlight caveats of each approach; forget link
           sheets for now.

           hearhear, Ian.

           HLink _is_ a link sheet proposal, you can't argue against link
           sheets and for HLink

           Right, what HT just said.

           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.

           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?

           add built-in element

           If you can do it with one method that is a lot better than
           doing it with three.

           I don't accept that requirement (don't modify the instance)

           IJ: The objection to TB's approach was you can't avoid
           modifying the instance.

           I prefer Ian Jacob's proposal as a starting point. I think he
           captured more of what is needed.

           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

           I don't think that that helps

           TimBL, you wanted to ask - Does TB's solution allow one to make
           a link:a anchor elements in the xlink namespace

           TB: I wouldn't want to define things at such a high level of
           detail at this stage.

           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

           Sounds like a clear lack of consensus here

           Lloyd: I don't care if the style is totally lost, I want the
           link to persist.

           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

           Norm: Point is style is maintained and dependable. So can

           HT: Please poll folks to find out priority of internal v.
           external link info.

           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.

           TB: Summarizing - links self-describing in the instance or
           preference for link sheets?
           Internal: TBL, SW, PG, NW, TB, HT

           Allow Internal but NOT require.

           second that

           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.

           Strongly disagree

           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.

           Some authors (and language designers) wish to keep as much of
           the "markupJunk" out of document content as possible. This is a
           real need.

           Liam, you wanted to claim mixing namespaces is a higher issue

           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?

           Liam: I don't believe I was conflating the two issues

           Norm, ok, sorry

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

           also thinks this has been useful.

           TB: Let's figure out what work we can do to move forward.
           LR: Let HLink go forward with certain requirements or

           If we don't decide whether linkness is first class or more like
           style, then I don't think we've moved forward.

           I am not happy with that proposal

           Yeah, what PGrosso said, I think.

           mark me -1 on that

           I had been told that XML2002 had moved the discussion forward
           (I wasn't there)

           links are first-class, link syntax is not (cf historical 'href'

           TBL: Is the HTML WG happy to use a link namespace on things
           that are links.

           It is not just about HTML. Also SYMM, XForms. It is about a
           general solution

           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.

           Others told me that there was a feeling of generating consensus

           steven: I fear I failed to detect what that consensus was.
           Perhaps I missed it

           OK Norm

           [IJ: I think HTML WG has said that namespace prefix not a major

           Not a problem per se. HTML WG is not against namespaces

           TBL: Most important is to ensure that simple solution exists.
           HT: The venue for taking this forward?

           It is always easier to take a simple thing and add complexity
           than to do the reverse.

           and isolating areas of disagreement is useful!

           And I think that those areas are the source of the problem

           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

           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

           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.

           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