Re: HTML friendly links to metainformation

[Nick- my bad on last send that only went to you.  - Al]

At 02:30 PM 2001-10-20 , you wrote:
>
>On Sat, 20 Oct 2001, Al Gilman wrote:
>
>> Note that HTML WG are struggling with what they feel are needs that are not
>> met by X-Link.
>
>Are you on HTML-WG?
>

No, but they listen to us [WAI-PF] more than we talk to them.  And in
principle
WAI-PF listens to all the rest of the WAI.  There is every intention on the
part of HTML-WG to listen to the WAI.  Where the communication breaks down, it
is not usually on account of lack of good will from their side.

There are any number of toothaches languishing un-worked-on so any we can
rough
into a plausible proposal here are all to the good.

See the wai-tech-comments archive at lists.w3.org/Archives/Public for more. 
Any functional gaps in HTML you can back up with a disability-impact scenario
should be filed there in addition to whatever else you do to advertise them.

>> We need to learn what those unmet needs are.  But at least in the present
>> case, the structure that seems to be friendliest both to HTML tradition and
>> to X-Link decisions is to use a construction something like:
>
>Unmet needs?  Yes indeed.
>
>We installed Site Valet for a company whose intranet standards required
>certain metadata to be visible within every page - so it had to go in
>the <BODY>.  We incorporated a custom DTD to enforce the metadata,
>and wrapped the whole thing in a <div class="metadata"> which was CSS'd
>to appear as a footer.

If you don't need it to parse the contents, I am inclined to wonder if it
couldn't just be at the foot from the outset.  And the 'role' be on an html:a
and not an html:link anyway.  But then bundle in metadata or diversity options
using wrappers for the legacy constructs.

We should be trying to make the order in the wire format the order used in
"just play it to me" speech output, as much as possible.

Or else we really do need to require the script -- by which I include XSLT --
to order it that way.

>
>> <div> <!-- or any other container -->
>> <meta keywords="accessibility, report">
>> <meta scheme="EARL 1.3.7">
>> <link role="meta" href="URI-reference_returning_EARL_doc"
>> type="cturi:text/rdf;version=1.2">
>> </div>
>
>Ugh!  If anything is going to break back-compatibility, trying to
>reuse HEAD elements in a BODY must be a prime candidate.
>

_Empty_ HEAD elements???  I just want to understand why it breaks something.

Element types are for what they do, not where they go.

The basic problem is that in order to provide a content model for The Web
which
give equal justice independent of the concurrency-horizon of viewports or
interaction modes, we need to view web pages not as atomic 'resources' but as
extended samples of a finer infoset 'web.'  Or at least this view is presented
in the attached "page scope not universal" argument and figure.

It is feasible for backward compatibility to lift all object metadata into the
'head of the current document' as a part of the packaging for delivery of the
extended infoset sample.  But this is extra work.

There is not legacy practice for metadata, or is there?  You seem to have a
customer that does use it.  What is the current usage of metadata with HTML?

The example I offered was meant to span

  a) using DIV in HEAD to bundle META properties with LINK references
  b) permitting this inline in the BODY

One can lose b) without striking the example, only the comment.

>No, if a document is going to point to its own EARL report, then a
>LINK element (or META as second choice) in the HEAD is the right
>mechanism for it.

The argument against this is that there should be plain HTML information
disclosing the path to more information.  No machine secrets; nothing up the
sleeve.  People use hyperlinks in footers.  They don't use invisible LINKs in
HEADs.  We should prefer solutions that are compatible extensions of things
people do use over reclaimers of things people don't use.

>> Of course, HTML WG are saying that XHTML 2.0 doesn't have to be
>> legacy-safe,
>
>Erm ..... no comment.
>
>Or on second thoughts: yes, here's one printable comment.  It would
>be entirely wrong for them to introduce constructs that break back-
>compatibility gratuitously.  If they do break it, they should be
>prepared to demonstrate both a genuine need and a genuine lack of
>any back-compatible alternative.
>
>-- 
>Nick Kew
>
>Site Valet - the essential service for anyone with a website.
><URL:<http://valet.webthing.com/>http://valet.webthing.com/>
>

Attachments

Received on Saturday, 20 October 2001 20:30:58 UTC