OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

docbook message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [docbook] Linking to an Unknown Amount of Targets (1:n relationships)?

Hi Simon,

thanks for your ideas!

On Tue, 23 Jul 2013 05:45:42 -0400
"Dew, Simon" <Simon.Dew@sbdinc.com> wrote:

> [...]
> > Ok, this looks good, but where do I put my category description?
> >
> > For example, if I want to say, "this topic belong to the group X
> > and Y" then the labels(?) "X" and "Y" doesn't have to be the
> > description.
> >
> > There is a xlink:title attribute for a <locator/>, which seems to be
> > made for this purpose. However, adding this to *each* locator
> > elements for every topic in this group wouldn't be very useful. You
> > have a lot of duplicate code (which raises the risk of inserting a
> > typo).
> I that case I would put the xl:title attribute on the extendedlink.
> It looks like you can have multiple extendedlink elements in each
> info section. So you could group locators with similar xl:titles in
> separate extendedlink elements.

Ok, this could be a solution...

> (It's not quite clear from The Complete Guide, but looking at 
> docbook.rng, you can see that the extendedlink element supports the 
> xl:title attribute.)

Right, my XML editor told me that too. :)

> [...]
> > Based on your example above, would that fit into your idea, too?
> Your scheme seems fine to me! Personally I would omit the section 
> role="seealso". I would include an extendedlink element with the
> xl:role "seealso" (or whatever) in the topic's info section. I would
> write a transformation to generate the seealso section at the end of
> the topic automatically. I'm afraid that's the way my mind works.

That's perfectly ok. :) I had this method also in my mind, makes sense.

It could probably work too, when you want to add an additional link
which doesn't belong to any group (I'm thinking of a <link> inside
<extendedlink>). The stylesheet could merge both and create a nice list
from both.

> This would create a bit of a gap between the semantics of the markup
> and the way that you want it presented; you would probably need to
> explain it to other authors maintaining your documents.

At the moment, explaining to other authors is the least problem. :-]
I would prefer to have an "intuitive" solution, but I fear this word
unknow for XLink. ;-)

I guess, what I'm missing is just the connecting piece between "do this
to get that". 

> > Hmn... it seems, using XLinks to markup a 1:n relationship is a
> > daunting task. ;)
> I guess that's why it's been slow to catch on :-)

Yes, it feels a bit strange if you use it for the first time. You need
to twist your brain before you can use it. :)

> As I understand it, the xl:role URIs don't have to point to a real 
> resource on the net. They just have to be agreed within your
> system... e.g. "http://my.org/xlinkroles/seealso"; or whatever. 

So xl:role is just an identifier, right?

> There
> might be existing URI schemes which you could use; I haven't got time
> to look. Dublin Core might be a good place to start.

Yes, thanks for reminding me on Dublin Core.

> Sorry for mixing up top-quoting and bottom-quoting.

It works fine here.

Thanks for this interesting discussion!

    Thomas Schraitle

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]