,
After much thinking, reading, and reviewing, I've come to these three ideas:
1) Stylesheet languages need some sort of way to display links from
generic XML. This is so we can interact with them in user agents. By
"stylesheet languages," I am specifically referring to XSL-F and CSS.
2) Links need to be declared in generic XML, so no forced syntax
like XLink 1.0. This is so that all the various dialects people have
used to describe linking can get along without breaking (backwards
and forwards compatibility).
3) XLink is -conceptually- on the right side of the 80/20. Forget
the syntax, and focus on the actual ideas -- do they cover what needs
to be covered? Especially if it were possible to easily extend them
in the future.
Please shred my assumptions. Critical feedback would be helpful.
Thank you!

>Ben
XML-DEV is a publicly archived, unmoderated list hosted by ASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.
[Un]Subscribe/change address:
unsubscribe: xml-dev-unsubscribe (AT) lists (DOT) xml.org
subscribe: xml-dev-subscribe (AT) lists (DOT) xml.org
List archive:
List Guidelines:

Ben Trafford wrote:

After much thinking, reading, and reviewing, I've come to these
three ideas:

1) Stylesheet languages need some sort of way to display links from
generic XML. This is so we can interact with them in user agents. By
"stylesheet languages," I am specifically referring to XSL-F and CSS.

2) Links need to be declared in generic XML,

Given the point 1 which allows you to turn anything into link, why you
then need to declare it as link on XML level (point 2). I mean if you
have some generic XML, e.g.:

<hotel moreinfo="http://example.org/dream-hotel">

and you are able to say that this element should work as link on a
stylesheet level, e.g.:

hotel { link-type: simple;
link-target: attr(moreinfo);
}

what is then point of point 2?

Jirka

Jirka Kosek e-mail: jirka (AT) kosek (DOT) cz http://www.kosek.cz

P a v oblasti XML.
P se na spu web http://DocBook.cz
P pehled http://xmlguru.cz/skoleni/

Nejbli :
** XSLT 23.-26.10.2006 ** XML 13.-15.11.2006 **
** DocBook 11.-13.12.2006 ** XSL-F 11.-12.12.2006 **

http://xmlguru.cz Blog mostly about XML for English readers

9/28/06, Jirka Kosek <jirka (AT) kosek (DOT) czwrote:
Ben Trafford wrote:

After much thinking, reading, and reviewing, I've come to these
three ideas:

1) Stylesheet languages need some sort of way to display links from
generic XML. This is so we can interact with them in user agents. By
"stylesheet languages," I am specifically referring to XSL-F and CSS.

2) Links need to be declared in generic XML,

Given the point 1 which allows you to turn anything into link, why you
then need to declare it as link on XML level (point 2). I mean if you
have some generic XML, e.g.:

<hotel moreinfo="http://example.org/dream-hotel">

and you are able to say that this element should work as link on a
stylesheet level, e.g.:

hotel { link-type: simple;
link-target: attr(moreinfo);
}

what is then point of point 2?

+1

I think adding multi-arc linking to CSS is the answer here.

Given XML + XSLT =DHTML + Javascript I can create multi arc links in
the browser. If it was possible to do the same with XML + CSS then I
think most people would be happy - Less Javascript, more CSS.

XML-DEV is a publicly archived, unmoderated list hosted by ASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address:
unsubscribe: xml-dev-unsubscribe (AT) lists (DOT) xml.org
subscribe: xml-dev-subscribe (AT) lists (DOT) xml.org
List archive:
List Guidelines:

9/28/06, Peter Hunsberger <peter.hunsberger (AT) gmail (DOT) comwrote:
In your example, the relationship is hard coded in the CSS as

link-target: attr(moreinfo);

that's a pretty limited capability and doesn't easily allow for two
way linking, dynamic linking or many other things that people want to
do.

I think that would be a really useful addition to CSS, maybe it's a
separate issue.

Instead someone may want something more like:

<hotel name="Dream"/>

and in a separate document

<link select="/hotel[@name = 'Dream']"
href="http://example.org/dream-hotel"/>

and in the CSS:

link { link-type: simple }

Don't get hung up on my syntax here. The point is, the concepts of
presentation and relationship building need to be separated.

I implemented an "independent linking" solution for my last employer.
The link file identified the end points using xpaths, which left the
original documents untouched. The link file would be processed first,
creating a stylesheet with templates to handle the elements that
should be links. This stylesheet would import the standard stylesheet
and defer handling to those templates to ensure whatever element the
link was attached to it would be output in the normal way. It all
worked well, but it did rely heavily on javascript to create the popup
menus to display the multi-arc links.

The syntax was something like (it was a few years ago now):

<docid="doc1">
<endpoint id="ep1" element="/xpath/to/element"/>
<endpoint id="ep2" element="/xpath/to/element"/>
</doc>

<doc id="doc2">
<endpoint id="ep3" element="/xpath/to/element"/>
</doc>

<links>
<link id="l1">
<arc from="ep1" to="ep2"/>
<arc from="ep1" to="ep3"/>
<arc from="ep2" to="ep1"/>
<arc from="ep2" to="ep3"/>
<arc from="ep3" to="ep1"/>
<arc from="ep3" to="ep2"/>
</link>
</links>

When an element was processed that was in the link file a graphic
would be output, which when clicked presented the user with relevant
choice of links. Users could create these independent links either
from the right-click menu in the browser, or by editing the link file
using a standalone app.

I tend to think there are two disinct camps here - those that would
like simple links in CSS, and those that would like full blown
multi-arc independent linking in publishing.

cheers
andrew

XML-DEV is a publicly archived, unmoderated list hosted by ASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address:
unsubscribe: xml-dev-unsubscribe (AT) lists (DOT) xml.org
subscribe: xml-dev-subscribe (AT) lists (DOT) xml.org
List archive:
List Guidelines:

At 05:40 AM 9/28/2006, Jirka Kosek wrote:
>Given the point 1 which allows you to turn anything into link, why
>you then need to declare it as link on XML level (point 2). I mean
>if you have some generic XML, e.g.:
><snip example>
>what is then point of point 2?

When I say you need to be able to declare it in generic XML,
I mean to say that all three of the following may be the same link,
depending on the CSS:

<a href="http://www.example.com>An Example</a>

<link>An Example</link>

<anchor xlink:href="http://www.example.com" xlink:show="onRequest"
xlink:actuate="replace">An Example</anchor>

In other words, the type of XML used shouldn't require any
specific elements or attributes -- which XLink currently forces.

>Ben

XML-DEV is a publicly archived, unmoderated list hosted by ASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address:
unsubscribe: xml-dev-unsubscribe (AT) lists (DOT) xml.org
subscribe: xml-dev-subscribe (AT) lists (DOT) xml.org
List archive:
List Guidelines:

At 09:57 AM 9/28/2006, Melvin Chin wrote:
>Why would it necessarily be in generic XML? XPath isn't, though it
>inherits the "X" prefix.

Because there are dozens of different ways to declare a link
in different XML applications. DocBook does it differently than
XHTML, CML does it differently (and for different purposes) than DocBook, etc.

As soon as we specify links via a rigid vocabulary that must
exist in the markup, we lose interoperability between different XML
applications.

>I'd think links can be interpreted as a separate class of "data
>about relationships".
From this angle, its use and arguments about its importance and
non-importance
>(which defines the "right" in your 80/20) would be different from
>just considering
>links' contribution to styles.

I agreewhich leads me back to my previous question --
does XLink cover the necessary aspects of "data about relationships"
as it stands?

>Ben

XML-DEV is a publicly archived, unmoderated list hosted by ASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address:
unsubscribe: xml-dev-unsubscribe (AT) lists (DOT) xml.org
subscribe: xml-dev-subscribe (AT) lists (DOT) xml.org
List archive:
List Guidelines:

At 10:52 AM 9/28/2006, andrew welch wrote:
>I tend to think there are two disinct camps here - those that would
>like simple links in CSS, and those that would like full blown
>multi-arc independent linking in publishing.

Count me as camp three, then -- I want both.

>Ben

XML-DEV is a publicly archived, unmoderated list hosted by ASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address:
unsubscribe: xml-dev-unsubscribe (AT) lists (DOT) xml.org
subscribe: xml-dev-subscribe (AT) lists (DOT) xml.org
List archive:
List Guidelines:

At 08:49 28/09/2006, Ben Trafford wrote:

,

After much thinking, reading, and reviewing, I've come to
these three ideas:

First - many thanks Ben,
Even if the result of your deliberations is to show that the
problem is too complex or only part of it can be tackled it'll be
extremely valuable. if you show that it is already done. But I
believe there is a middle ground and that a clear simple approach to
80/20 will be valuable.

1) Stylesheet languages need some sort of way to display
links from generic XML. This is so we can interact with them in
user agents. By "stylesheet languages," I am specifically referring
to XSL-F and CSS.

Yes. I expect this to be moderately tractable. It it helps promote F
that will be specially valuable. (I am sick of dealing with broken PDFs)

2) Links need to be declared in generic XML, so no forced
syntax like XLink 1.0. This is so that all the various dialects
people have used to describe linking can get along without breaking
(backwards and forwards compatibility).

3) XLink is -conceptually- on the right side of the 80/20.
Forget the syntax, and focus on the actual ideas -- do they cover
what needs to be covered? Especially if it were possible to easily
extend them in the future.

I am not sure what the difference is between 2 and 3.

There is no doubt that a full treatment of linking is deep and
complex. I expect to find that HyTime solved most of it. I sat for
several hours at XML 1998 (I think) with Eliot Kimber explaining it
patiently to me. I think I understood it them - I don't now!.

So HyTime was ahead of its time, but the time is catching up. I don't
think we should use HyTime as the language is arcane by current
discourse. I think people can understand linking better than they did
10 years ago if they have a clear exposition.

Please shred my assumptions. Critical feedback would be helpful.

My guess i that you might come up with something that says "use Xlink
in the following way and it will do the following for you " and that
will cover everything I want.

Thank you!
>
>>Ben

P.


>
>
>XML-DEV is a publicly archived, unmoderated list hosted by ASIS
>to support XML implementation and development. To minimize
>spam in the archives, you must subscribe before posting.
>
>[Un]Subscribe/change address:
unsubscribe: xml-dev-unsubscribe (AT) lists (DOT) xml.org
>subscribe: xml-dev-subscribe (AT) lists (DOT) xml.org
>List archive:
>List Guidelines:

Peter Murray-Rust
Unilever Centre for Molecular Sciences Informatics
University of Cambridge,
Lensfield Road, Cambridge CB2 1EW, UK
+44-1223-763069

XML-DEV is a publicly archived, unmoderated list hosted by ASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address:
unsubscribe: xml-dev-unsubscribe (AT) lists (DOT) xml.org
subscribe: xml-dev-subscribe (AT) lists (DOT) xml.org
List archive:
List Guidelines: