- From: Henry S. Thompson <ht@cogsci.ed.ac.uk>
- Date: Fri, 21 Feb 97 15:21:36 GMT
- To: w3c-sgml-wg@w3.org
> 3.3.a Should we have a type of link that tries to be a nice clean superset of
> HTML's Anchor?
Yes, but that doesn't mean I go for reserved GIs, since (following
Paul's example)
<?ATTLIST a
xml-link CDATA #fixed "xml-link" ?>
would do the trick.
> 3.3.b If so, what should we call it?
As above, xml-link, with xml-mlink for non-inline-links.
> 3.3.c If 3.2.b goes the way of child elements for locators, should the "A"
> link have a single child element for consistency with that, or no such
> element for consistency with HTML?
See my comments on 3.2.b -- I like having the attributes on the
xml-link element itself, with similar names to the ones appearing on
each locator sub-element of xml-mlinks.
> 3.3.d Should we regard such an "A" link as involving one or two resources?
It must be two, surely, so applications can treat links and mlinks the
same for most purposes.
> 3.3.e If it involves two resources, is it a problem that there is no obvious
> place to put locator metadata for the "implied" resource?
My draft proposal had a solution for that. As far as I can see the
only such metadata is not locator metadata at all, but resource (aka
endpoint) metadata, of which the only two proposed so far are role and
caption. I'd vote for using 'role' and 'caption' for the explicitly
located reference (i.e. the one specified using 'href' and 'hrtype'),
and using 'irole' and 'icaption' for the implicit resource (which
doesn't need 'href' or 'hrtype').
> 3.3.f SHould we provide a content model for "A" links?
No. Just as I can explicitly locate any sub-tree of a document, I
should be able to contain and implicitly locate any sub-tree, if I
write my DTD to allow it.
> 3.3.g Should we allow "A" links to contain anything other than PCDATA?
Yes, see above.
ht
Received on Friday, 21 February 1997 10:21:44 UTC