Re: Initial draft of XML-Link spec now available
I've written some moderately detailed comments below (I hope not too much)!
I think it's an excellent first draft.
I think my first comment is that I have a real problem with the
terminlogy. I know it's very HyTimesque to talk about a link end as
being something that's not actually in a document, and also to talk
about link ends as having anchor roles. But only anchors can have
anchor roles -- obviously :-) -- and link ends ought to be what
you find at the end of links, when you follow them.
I think (from the definition) that a locator could be called an address.
What is the difference between an explainer and an anchor role, except
that one is a name and the other can have more that one word in it?
Why isn't an explainer called a caption or a title??
7] If bi-directional isn't apt, use multi-directional.
8] an in-link link is not inherently one-directional (that term is not
defined, by the way) -- if two ends are in the same document, it is
clearly traversable in two directions. HTML inline links are not
generally considered multi-directional, if that's what you mean, although
if you had a link database (ala HyperG) they would be.
9] out-of-line links
SoftQuad Panorama uses ilinks in web files, and yet does not have
what most people would think of as a link database, so I claim that
"does not make sense" is incorrect.
It is also incorrect to say that out-of-line links are required to support
multidirectional traversal (although they may make it easier to manage!)
An XHL Link is too hard to say. XLL (X Link Language) would be better,
although I still like MultiLink or PowerLink :-) [but that is a separate
thread. I just wanted to point out that it's hard to say]
2.1] The example needs to be
<A -XML-XHL-="ALINK" -XML-XHL-URI-="http://...../">link</A>
if you follow the no-resered-names rule.
For my own point I think the prepended hyphen is silly and adds nothing,
but it's there now.
2.2] "If the document is an XML document" -- wouldn't any other kind of
document be out of scope??
3] It might be interesting to think about multiway in-line links at
least a little.
<link to="xxx" from="yyy zzz">
You probably need tools to manage this in practice...
We'll sell them :-)
Can you give an example showing how the HTML REL and REV functionality
(implemented in e.g. Lynx and NCSA Mosaic 3) is grandfathered in?
That would help me a lot.
I would be much happier wiith parameter entities or arch forms than some
of these element names. I think element names starting with a hyphen
are really odd.
<!Entity % -XML-THESE-ELEMENTS-ARE-LINKS "HHREF LINK">
3. "compatibility with existing practice"
The only XML documents existing in the world were written by Jon Bosak as
examples. There _is_ no current practice. If you mean to make it easier
for HTML people to use it, say "for simplicity" or "for convenience"...
Why does -XML-LINK lack REL and REV?
4.5 If the TEI patterns are not included, why are they given in the appendix?
Actually I think they are good, but only if they use either standard Posix
or Unix regexp syntax, so that C and Java libraries are readily available.
The proposed TEI addition to point to attributes sounds interesting.
Could you (Steve?) expand on it?
Overall this is an interesting draft.