[xml-h] picking up the thread

[Dave Pawson]

At 13:49 18/01/2003 -0500, Simon St.Laurent wrote:

> >Lets assume its a page on my website. You ask me, I agree.
> >So some third party reads my webpage......
> >   Do they need an agreement with you that they will 'see' this links?
> >  (I'm presuming you haven't modified my pages directly).
> >  This is getting complex Simon.
> >Why do you see added value in this n party agreement to modify what the
> >reader see's?
>
>I'm not concerned about the parties, to be honest.  I suspect my views
>on intellectual property would likely go over poorly with people who
>insist on absolute control over their pages, but the kind of project I
>have in mind is a lot simpler.

Then I can't see why end users should be interested. There's nothing
there to make it a bonus? Why should we change what works already
without any perceived benefit?





>My background is history, and I've never been comfortable with the
>historian's control over source citation.  I'm slowly collecting
>materials and building a framework for a hypertext exploring the
>downtown of the small city where I grew up from about 1820-1920.  The
>materials will all have their own structural markup, but I want to be
>able to present those materials - and let other people present those
>materials - from different perspectives by making different connections.
>Putting all the linking markup into the documents is a huge nuisance in
>that case to say the least.


Intuiting from that, you've resolved my issues for this case, by identifying
a group with a common cause, variant views of the same data collection,
linked in different ways. So you have the consent aspect.

For you to put a link from my data so that a third party can view and
follow that link is a very different use case IMO.





>(In fact, putting linking markup into documents generally creates a huge
>mess as the link density increases, even without control issues.)

Good point. Nice high end constraint, what's the maximum link density
before it becomes a nuisance to the end user.





>For a higher-level perspective on this, see _Why History for
>Hypertext?_, a piece I wrote back in 1992 while I was playing with
>HyperCard:
>http://simonstl.com/articles/hypehist.htm

Aaahhh. Hypercard :-)





> >>I'd like to be able to create links that have scope over more than a
> >>single page.
> >
> >I don't understand that in terms of what a customer is going to get out
> >of such a facility?
>
>It depends largely on who the customer is.  You seem to focus pretty
>exclusively on the author and the reader.

Surely anyone else is the provider? My view is that if the customer wants
it that's the motivation for the provider to give it?

>   I worry about the customers
>who have to maintain these documents.

OK, we differ. I buy a car. I'm the customer. Person A (Ford) is my supplier /
provider, meeting my need. Person B (the garage down the road) is making money
interfacing between the two. The garage is a secondary consideration when
Mr Ford designs his cars for me. Nothing to repair if I don't buy the car?

>   Managing the links for a site can
>be a lot easier if you can control those links in a single space with a
>larger scope instead of having to manipulate multipe documents
>repeatedly.

IMO people don't design products for their maintainability.
Hence I think that's a weak perspective from which to initiate a design.



>Right now, nearly all hypertext beyond HTML is unsaleable hypothesizing.
>My concerns about maintenance come directly from my experiences in HTML,
>not from random guesses about what hypertext might or might not be good
>for.

With HTML as yesterdays product, what's the new whizz bang version that's
going to sell like hot cakes tomorrow.
Marketing is all about random guesses about what a product might or might
not be good for. The ones that get it right have the saleable product.



> > Only if it can't be programmed, maintained should we come back to the
> >customer and say sorry, we can't give you what you wanted.
> >
> >Sound reasonable?
>
>No.  I'm happy to have programmers considered only for the sake of
>establishing limits to what a given technology should do, but
>maintainers need features, not just limits.

Maintenance issues are  generally a constraint, not a selling feature
in my experience.

regards DaveP