Re: Experimentation with extensions, LINK and META

I have finally had the time to review parts of your mail archive so
as to better understand the rationale behind your proposals.  I also
have read the 22-October version of the "Report" document
( and its associated linked
documents.  I think I still only have part of the picture, but I hope
this answer will help fill in more of the details.

At 12:57 PM 10/13/97 -0400, Al Gilman wrote:
>  Content models
>         ADD:
>          + LINK and META may appear anywhere (in any container in HEAD
>            or BODY).
>  Semantics
>       If a LINK or META element contains a TARGET then the relationship
>       or attribute defined in the LINK or META element applies only
>       within the scope of the TARGET element.
>       If a LINK or META element appears within the HEAD element and it
>       does not contain an explicit TARGET indication, then the target
>       scope is the HTML element (document) in which the HEAD is found.
>       If a LINK or META element appears outside the HEAD element and it
>       does not contain an explicit TARGET indication, then the target
>       scope is the non-void element immediately enclosing the LINK or
>       META element. The immediately enclosing element shall be
>       determined to be the non-void HTML element whose start tag most
>       immediately precedes the LINK or META tag in the textual order of
>       the HTML text.
>       Furthermore, if the LINK or META contains a TGTCLASS attribute,
>       then the relationship or attribute defined by the current LINK or
>       META element applies only within elements in the TARGET scope
>       which have at least one match between the set of identifiers in
>       the value of the TGTCLASS attribute and the set of identifiers
>       coprising the element type name of the candidate element together
>       with the set of strings which are list elements in the value of a
>       CLASS attribute present in the candidate element. This matching
>       shall accept element type names without regard for case and CLASS
>       values in a case-sensitive fashion.
>Application to known WAI needs
>            Associate table with a data dictionary or schema.
>            Associate a dictionary with a quote or code block.
>            Associate a dictionary with a particular use
>            e.g.
>            <LINK REL="dictionary" CLASS="abbreviation">

and at 09:13 AM 10/13/97 -0400, Dave Raggett also wrote:
>Al Gilman and I are interested in the possibilities for using RDF
>for binding the table to the data model or script. An alternative
>would be to add an attribute to the TABLE element to provide a URL
>referencing the table's data model etc. I would be most grateful if
>you could enlighten me as to current thinking of how RDF can be used
>to annotate HTML markup. 

RDF will do two things that are of particular use here.  The first will
accomplish what the proposed TARGET attribute on LINK/META is intended
to do and the second will address a need that will become apparent as
the accessibility work continues, namely how to manage the LINK REL
namespace and the META NAME namespace.

An RDF 'assertions' element includes an HREF to specify the target
resource to which the metadata applies.  The value can be a URL
fragment, thereby assuming the proposed role of LINK TARGET.  At
present there is no shorthand syntax for indicating that the
target is the immediately enclosing element, nor is there currently
anything directly corresponding to the proposed TGTCLASS.

The TARGET/HREF idea relies on the use of ID to label the element
being described.  In the future, XLL (XML-link) should allow RDF
statements to be scoped even to portions of a read-only document
that were not given IDs by the document author.  The RDF annotations
in this case would be carried in a separate document.

The second important aspect of RDF in this context will allow
the WAI metadata specification to evolve independently of the
schedule for other specifications.  RDF allows you to declare,
for example, a "WAI metadata property namespace" wherein you
might start with a set of properties that associate data
dictionaries and pronunciation dictionaries and then later add
language variants of pronunciation dictionaries, abbreviation
dictionaries, and alternate descriptions without fear of
colliding with property names being used elsewhere.

Received on Friday, 24 October 1997 20:26:47 UTC