RE: XHTML & hyperlinking opinions (long, sorry)

Yes, shorter is better, and Tim is among the best at keeping it short (I'm 
obviously not, unfortunately).  In this case, I made the point because my 
feeling is that a lot of this discussion has run on too long because of 
statements like "there's clearly a benefit to XXX", as opposed to "the 
benefits of XXX are ,..., the drawbacks are ... YYYY, and here's why I 
think the benefits outweigh the downsides."  I never doubted that Tim or 
most others would agree in principle that we need cost benefit tradeoffs.  
I was trying to point out that we need a bit more dispassionate analysis 
in this particular discussion (just my opinion.)

------------------------------------------------------------------
Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------







"David Orchard" <dorchard@bea.com>
10/05/02 03:26 AM

 
        To:     <noah_mendelsohn@us.ibm.com>, "'Tim Bray'" <tbray@textuality.com>
        cc:     <Mike.Champion@SoftwareAG-USA.com>, <www-tag@w3.org>
        Subject:        RE: XHTML & hyperlinking opinions (long, sorry)
Categories: 
 




Noah,

I think Tim's shorter version is more appropriate.  Value is always 
relative
to the cost/benefits associated with a given action or non-action, and 
it's
impact to the overall state of affairs in any given area.  I tend to 
prefer
shorter and more concise statements in these kinds of areas.  Personally, 
I
think that's one of the things that TimB does very well, creating succinct
and direct statements.  The 80/20 rule applied to statements if you will.

Having said that I certainly and heartily agree with analyzing and 
weighing
the costs and benefits of each style of linking.  I think there ought to 
be
a running list of different "features" and how they might be expressed in
various linking syntaxes.  I kind of imagine about 20 different features,
and about  5 different schemes with a matrix of syntaxes.

But then I've always been "lists" kind of guy.

Cheers,
Dave

> -----Original Message-----
> From: www-tag-request@w3.org
> [mailto:www-tag-request@w3.org]On Behalf Of
> noah_mendelsohn@us.ibm.com
> Sent: Friday, October 04, 2002 8:11 PM
> To: Tim Bray
> Cc: Mike.Champion@SoftwareAG-USA.com; www-tag@w3.org
> Subject: Re: XHTML & hyperlinking opinions (long, sorry)
>
>
>
> Tim Bray writes:
>
> >> I think reasonable disagreements are of the
> >> form "no, that's not a valuable thing to add"
>
> I agree that's the key issue, but suggest a reformulation:
>
>         "I think reasonable disagreements
>         are of the form 'no, trading off the
>         value gained against whatever
>         drawbacks, it's not on balance a
>         good thing to add.'"
>
> Xlink presumably has value in at least some situations.  I think the
> question is:  how often, how much, and how does that value compare to
> whatever downsides it might have?  We need those answers in
> general and
> for XLink-for-XHTML in particular.
>
> We also have to be clear on what we're advertising as the
> value gained
> from any particular proposal.  What I think I've heard argued
> for as the
> benefit of XLink includes at least the following 3 points
> (I've thrown in
> personal opinions on a few, but they're not central to my
> main suggestion
> which is: list the proposed benefits& drawbacks, and do a
> dispassionate
> pro/con analysis):
>
> ----Possible benefits of XLink for XML ---------
> ------in general and XHTML in particular--------
>
> 1. A linking mechanism that is common across all (or most)
> vocabularies
> and applicable to all uses in those vocabularies, so that it can be
> recognized independent of context.
>
> This is just as all attributes are represented uniformly, and we can
> therefore build tools that work on any attribute in any
> vocabulary. The
> claim would be that  we need the same uniformity for links,
> presumably so
> we can build things like generalized, vocabulary-independent link
> manipulation tools.
>
> (I happen not to be convinced that this is in general
> practical, because I
> think links have a semantic that's not in general trustworthy without
> knowing the application context.  For example, see my earlier
> posting on
> undo lists containing deleted data in compound document
> structures [1].
> You don't really understand a link, I claim, if it's in a
> structure that
> the application uses to represent deleted data.  Or conversely, a
> construction like XLink might be restricted to use in
> situations where
> context doesn't matter, implying that when I move deleted
> text to the undo
> list, I have to change from XLink to something else (so that
> generalized
> tools won't think this document is still making a link.)  So,
> I remain
> suspicious of the need for or practicality of a common way to
> encode all
> links.)
>
> 2. A richer linking mechanism with multi-way links, third
> party links etc.
>  This seems to have value, at least in principle, and
> figuring out how to
> do it once and reusing that insight where appropriate seems
> to make sense.
>  Whether the value of trying to actually get to the level of common
> serializations of these constructs in application-specific
> vocabularies
> outweighs the complexity and inconvenience, I'm not sure.
>
> 3.  A generalized means of providing presentation hints, what
> I believe
> XLink calls behavior attributes.  (I have some nervousness
> about these
> too, in that I see much (not all) XML as being on the model side of a
> model/view architecture.  Insofar as these attributes
> encourage embedding
> of presentation hints in the model, I get a bit nervous.
> That said, XLink
> layers them quite well, and makes them optional, and they
> certainly are
> potentially applicable to presentation-oriented vocabularies such as
> XHTML.  Still, I'm not sure how much value there is in
> generalizing them
> across vocabularies: probably some, but I don't see it as broadly
> applicable to all XML, which is what I thought was advertised
> for XLink.)
>
> -------------------------------------------------
>
> So:  for Xlink, I think we have to answer Tim's question (as
> reformulated)
> with respect to the three purported benefits above.  I
> personally don't
> have a strong opinion pro or con on XLink, but am interested
> in seeing the
> questions stated clearly so we can get to an answer.  Maybe this is a
> piece of the formulation?
>
> Noah
>
> [1] http://lists.w3.org/Archives/Public/www-tag/2002Sep/0178.html
> ------------------------------------------------------------------
> Noah Mendelsohn                              Voice: 1-617-693-4036
> IBM Corporation                                Fax: 1-617-693-8676
> One Rogers Street
> Cambridge, MA 02142
> ------------------------------------------------------------------
>
>
>

Received on Saturday, 5 October 2002 09:30:56 UTC