Re: Experimentation with extensions, LINK and META

to follow up on what Ralph R. Swick said:

> I think I still only have part of the picture, but I hope this
> answer will help fill in more of the details.  

Thank you very much for giving this priority attention.  You have
reduced my ignorance a lot.
 
> 
> 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.
> 

Yes, we realize we have those dictionaries to manage, and we are very
interested in developing RDF-based solutions for those dictionaries.

> 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.
> 

Both the default TARGET for inline LINK and META elements, and the
TGTCLASS attribute are, so far as I can tell, conveniences.  They
improve the usability of the language feature but do not change
the envelope of feasible link/attribute graphs.  In other words,
I don't see this particular difference as a make/break difference.

> 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.
> 

There are two principal sub-questions to the root question "Does
the imminent availability of RDF mean we don't need this
capability in HTML?"

  a) What is the respective timeframe in which we could expect to
     have working tool implementations based on putting these
     extension in HTML, vs. when we could expect tools which
     implement RDF?  

  b) Does the HTML user need/have the capability to use a
     data dictionary which understands the CLASS and REL names
     we are using, even though it is not RDF and does not
     particularly understand HTML and it is not implemented
     in XML or RDF?  This is a likely case where the external
     data dictionary understands well the information types in the
     cells and semantic relationships among them, but not so well 
     the HTML syntax in which this specific report has been written.

There are lots of candidate schema-publishing frameworks coming
forth on the Internet.  It might be better for the disability
interest if HTML were not bound by an exclusive commitment to use
RDF for data dictionaries.

On the other hand, if the commercial software houses interested
in RDF were to commit to work accessibility scenarios defined by
the WAI IPO among their early RDF feasibility demonstrations, that
could be a very good deal for the WAI.

> 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.
> 

The independence of schedule we need is accomplished by the fact
that the dictionary of CLASS and REL values is defined outside
the HTML spec.  This applies whether we then develop the
dictionaries in RDF or otherwise.  We have the dictionary
development schedule decoupling from HTML so we can proceed with
our work in either case.

I'm afraid that I think a "guaranteed separate" attribute
namespace is just what we least need.  The trick to making the
Web universal is getting the accesibility needs for information
reflected in schemas that everybody is using for their own
purposes without regard for disability access.  We need to be
sharing in the publishing of useful information models which are
recombinant and people use them together.  What we need from RDF
is the medium of exchange for a class reconciliation process by
which the peculiar terminology is broken down and common
semantics extracted.

The projected capability is the right kind of stuff.

So the key question outstanding is timeframe.  It's not always
wise to build prototype applications out of prototype resources.
Bite off one risk at a time.

-- Al Gilman

Received on Friday, 24 October 1997 22:53:42 UTC