Hi Shaun,<br><br><div class="gmail_quote">On Mon, Aug 2, 2010 at 8:37 AM, Shaun McCance <span dir="ltr"><<a href="mailto:shaunm@gnome.org">shaunm@gnome.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Hi folks,<br>
<br>
I've been mulling over an element to control the placement<br>
and display of dynamic links for a while. I was going to<br>
wait until Mallard 1.1, but Phil was pushing pretty hard.<br>
So here's the proposal for it:<br>
<br>
We'd have a links element, with a content model like this:<br>
<br>
mal_links = element links {<br>
attribute type { xsd:NMTOKEN },<br>
attribute style { xsd:NMTOKENS } ?,<br>
attribute groups { xsd:NMTOKENS } ?,<br>
mal_attr_external *,<br>
<br>
mal_block_title ?<br>
}<br>
<br>
The links element is an instruction to place a certain<br>
type of dynamic links at that location. The 1.0 spec<br>
would define the following types: topic, guide, seealso,<br>
series, and section.<br>
<br>
You would be able to mix links elements with the top-level<br>
block content in a page or section (not nested into block<br>
container elements like figure), or after any subsections.<br>
It's perfectly fine to use the same type of links element<br>
more than once.<br>
<br>
For topic links elements, you can use the groups attribute,<br>
just as you can use it on page or section elements right<br>
now. You can have multiple topic links elements, each with<br>
different groups, so you could do something like this:<br>
<br>
<p>Here's the first links:</p><br>
<links type="topic" groups="#first"/><br>
<p>Here's the rest of the links:</p><br>
<links type="topic"/><br>
<br>
* If there's no topic links element, there is implicitly<br>
one after the block content and before any subsections,<br>
and its groups attribute is "#first #default #last". [1]<br>
* If a topic links element does not have a groups attribute,<br>
its groups attribute is implicitly "#default".<br>
* If no topic links element contains "#first", "#first" is<br>
prepended to the groups of the first topic links.<br>
* If no topic links element contains "#default", "#default"<br>
is appended to the groups of the last topic links.<br>
* If no topic links element contains "#last", "#last" is<br>
appended to the groups of the last topic links.<br>
* If both "#default" and "#last" are added implicitly to<br>
the last topic links, "#last" is after "#default".<br>
[1] Caveat: to maintain compatibility, implementations can<br>
use the groups attribute on page and section, but since<br>
we're still pre-1.0, I don't want to mandate that in the<br>
spec.)<br>
<br>
This lets us mix block content between links, as well as<br>
provide lightweight titles for groups, without using full<br>
sections. Implementations can also recognize style hints<br>
for links elements.<br>
<br>
The seealso and guide links types are the "See Also" and<br>
"More About" link groups you see at the bottom of pages<br>
right now. Anything that goes after subsections (even if<br>
implicitly) may induce something like the "Further Reading"<br>
heading Yelp does now.<br>
<br>
The series links type shows a linear list of links to pages<br>
in a series, as defined by next links.<br>
<br>
The section links type shows a list of links to subsections<br>
of the current page or section. It might be worth adding a<br>
depth attribute.<br>
<br>
I have the links element for topic links working in a private<br>
branch of yelp-xsl right now. The others aren't done yet, but<br>
I think they're easier than topics.<br>
<br>
This is something I thought about when I was first putting<br>
Mallard together. I was hesitant to add it, because I didn't<br>
want to over-complicate the language, and I didn't have real<br>
use cases in front of me yet to make sure I got the design<br>
right. I'm pretty happy with this proposal though.<br>
<br>
Thoughts?<br>
<br>
--<br>
Shaun McCance<br>
<a href="http://syllogist.net/" target="_blank">http://syllogist.net/</a><br></blockquote></div><br>What use case would this solve? I.e., without this feature, we have little control how X is handled, but with this feature, we can easily do Y. Perhaps a couple of examples would help to illustrate what you're getting at . . . comparing the old approach (with associated problems) and the new approad (with associated advantages).<br>
<br>Jim<br>