Re: HTML friendly links to (browser-friendly reports of) metainformation

** summary:

The URI-reference from either an A in the footer or a LINK in the head leads
you to a service (a retail service colloquially know as 'a page') which
practices Device Independence per the DI Principles under development. 
This is
either a universal HTML page after the manner of WCAG 1.0 with a [possibly
un-mentioned, out-of-band] cross-index between legacy-compatible 'class' etc.
marks in the page and the EARL model, or a polymorphic page after the
manner of
the Reef technology and CC/PP, or some other solution.  But in any case the
idea that "EARL is RDF" does not mean that the link from the "every page"
context retrieves raw N3, for example.  There is a [portal] 'report' page that
consumerizes the information and gateways what is circulating in
machine-friendly syntax through the EARL backoffice network into
browser-friendly form for dispensing to generic and legacy [EARL unaware]
clients.  This is a server-side function by default [DI principle,
according to
PF, is any function can be done anywhere modulo bonafide dependencies being
satisfied].

We should recognize separate pieces of the solution strategy: 

  a) the "every page" technique for starting the path to metainformation and
accessibility evaluation information in particular, and 

  b) the "report page" techniques for representing reports of EARL information
in broadly usable ways.  This takes Device Independence techniques and client
population sensitivity.

  c) what reporting services what users will want.  This takes some market
segmentation analysis.  Some sites will only support canned reports, some will
accept queries from downstream.  This is a valuable application scenario for
the DI, PF, Web Services and Global Grid Forum deliberations, by the way.

[more details at foot] 

At 06:31 AM 2001-10-21 , Jim Ley wrote:
>Nick Kew:
>>Yes they do. <LINK> support is gradually hitting the mainstream (recent
>>Mozilla and MSIE variants have finally got around to doing something
>>sensible). You'll lose that by putting it in a <BODY>.
>
>MSIE??? If you mean my own suggestions of using various modifications to
>IE, or is there some other support? If it's my techniques, then it doesn't
>care about where they appear and serialises the DOM so it's still in
>source position (so it suggests not error correction)  I've not got the
>latest Mozilla to test it's support
>
>>OTOH nothing in your example will be rendered by any existing browser -
>>except the <LINK> if put in the <HEAD>.
>
>Or in the body? and I don't see how A can be used in any case as the EARL
>report isn't human readable (well there's meaning, but it's not
>accessible.)  if it's audience is a machine, it does have to be hidden
>from the user, but in a place where the user agents (of today, so we don't
>need to wait until future UA's to use it.) and LINK in head does this, the
>sub categorisation suggested by Al, also makes sense, as long as they
>fallback to <LINK>
>
>This makes sense, it will degrade so is still useful to current user
>agents: (I don't like DIV being in HEAD, and I don't see how having this
>outside the HEAD is helpful.)
>
><metadata>
> <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">
></metadata>
>
>(I need to see some justification of why we're breaking backwards
>compatibility on the ROLE/REL issue with that.)
>

AG::

Thank you, Jim.  This gives me a target I can shoot at.  

* Last point:  'role' vs. 'rel' --

I am treating them as synonymous, the particular token to be used to be
determined by HTML WG.  Anyone wants to write examples with 'rel' and I
probably won't notice.  What you are seeing here is just an artifact of my
"design it in XML and migrate back to legacy compatible form" problem attack. 
[Sean's issues concerning 'role' deferred.]  Mostly I am assuming that we
could
come up with some html:[link | a].rel or an xlink:role [or other property
asserting structure in the reference-indicating expression] that authors could
understand and new processors would recognize and old processors would safely
ignore.

* On the grouping in a 'metadata' element vs. a 'div' --
[again this is something where the details I am happy to defer to the HTML WG]
I claim you should be no more happy with a 'metadata' collector than with a
'div' collector in the HEAD section.  The 'div' is a pure structuring
convention without taint of the purpose of the structuring.  So it goes in the
HEAD just fine.  I am concerned that whatever internals we define to give
properties to the enclosing container are defined in terms of "the enclosing
container" and not "the 'metadata' element in which they are found."  These
functions are needed in multiple contexts.  

But in terms of designing the solution, all I meant was to suggest a collector
element which will allow one to declare multiple concurrently-applicable
properties in parallel syntactic substructures.  A dedicated 'metadata'
container would do the trick, but I was thinking DIV, as the generic scope
creator, would be sufficient.  This almost works except I realise that in
doing
so I have overloaded META which thus fails to communicate.  HTML processors
today think that META pertains to the whole document.  Changing that would
be a
wrench.  But the mission is there; the migration strategy is not clear
yet.  On
the mission...

* On why one wants meta decorations distributed through the body:

I guess one reasonably approachable example has to do with orientation to page
structure for navigation.  Having keywords per major section of the page, and
not just one title, would make it easier to write both a Table of Navigation
extractor for the blind visitor using speech and the reading-difficulty
visitor
[not totally non-reading] using graphics.  Doing differences on keywords is a
good analysis technique from which to build a 'discovered' model of
structure. 
It generates a machine-comprehensible statement of the logical flow of the
story, even when the logic is not linear.  You could generate a "The Brain"
visualization of the intra-page structure from the keywords map.  

For the words-are-a-problem visitor, one could border the sections and
decorate
the borders with icons for the keywords.  The terms that are selected as
keywords are more likely than are words in general to have recognizable cliche
images that work, and the tuples of icons would work to indicate differences
and connections between sections in a way titles don't.  Titles are ususally
written assuming you grokked the super-title and they are written with that
dependency so say what is different in this subsetion from the general
topic of
the supertitle.  So topic-key tuples are about what you need to communicate to
the hypo-lexic visitor.  As John [...] says, "LD students are perpetually in a
trial-and-error loop."  You cannot assume that they carry the context over
from
a supercontainer, etc.  Orientation which both distinguishes and connects is
the order of the day.

That is a motivational example.  The general idea is that the associations
should come from where they pertain, not indirectly through 'document'
overhead.  This is the argument about how the resource web is a) one connected
infoset across many pages-as-served and b) a continuing structure containing
sensible units at a finer grain than the page.  This is presented in the
attachments to my recent message dealing with "page scope not universal."  See
also the discussions from the HTML4 accessibility review under keyword REF.

HTML4/CSS2 Accessibility Recommendations
http://<http://www.w3.org/>www.w3.org/WAI/PF/report.html

* about the user of html:a elements in a footer to form the connection.

You have to understand that the question I am dealing with is "how does the
recovery path for evaluation information that flows through the EARL system
get
launched in an 'every page' context?"  Because I am in favor of something in
every page [every XML and or web document that is detached and moved around
separately] that starts a path to more information about the current instance
that what is implied by the [inital a.k.a. base a.k.a. super-] type
information
that is sent ahead of the content.  So I set aside the options that say "you
trim the prefix to contain only the DNS domain and no path beyond that point
and enquire of your 'information service' concerning how to get accessibility
metadata dealing with that domain."

So as soon as I am thinking about maximizing the legacy access to the
information, I am not only thinking about using a vanilla hyperlink out of the
page footer, but also how to serve the information from the URL that is in the
HREF of that link.  

You have to remember that EARL is a model, not a syntax, in the first
instance.  So I have lots of options.  I can do browser sniffing to set the
server's initial CC/PP expectations of the client and still process CC/PP for
CC/PP aware clients so the user has full control despite any assumptions that
the server might initially make.  This can be as simple as HTTP 1.1
transparent
content negotiation or whatever CC/PP comes up with as something smarter.  In
any case, the server serving the URI-reference that comes out of the "plain
vanilla hyperlink" may be serving a polymorphic resource which in certain
cases
is a plain HTML human-readable report of the evaluation results that are
known,
even down to formatting in an HTML emulation of the NCITS standard CIF format
for these memos that comes out of the IUSR program at NIST.

Where my heart is, on the other hand, is in interpretive-assistive overlays. 
This option has that link lead to a page which is _both_ legacy-friendly HTML
_and_ EARL because it is the EARL model in HTML syntax with the model-syntax
binding done in a way that is non-invasive with regard to the legacy
processing
of the HTML syntax.  [Even this doesn't inhibit it much from being a CIF
lookalike.]  This is in the tradition of "literate programming" where programs
are written in more or less "lab report" or "journal article" style and the
compiler knows how to scan the code exhibits in the article and compile from
the filtered output.  Sean has working examples of this "RDF from HTML" path,
from what I hear.  I just want the binding declared in metadata and not just
realised in an XSLT transformer.

[Sorry to keep you all so long.  Here is a picture that will make things a lot
clearer.]  What one gets to via the hyperlink from the footer is to some
portal
page that is a gateway to the EARL system.  For purposes of concreteness,
there
is a slightly over-busy version of a four tier model of the
distributed-computation universe at

ftp://<ftp://ftp.evl.uic.edu/>ftp.evl.uic.edu/pub/OUTgoing/ACE/GCE-Overview.
ppt

This gives some context for what I am saying here.

The problem of reporting the information in client-appropriate presentation
details is worked in accordance with the evolution of Device Independence
practices for the Web.  The portal page is adaptive to the delivery context. 
The portal page is a report from the EARL system.  On the server serving this
portal page there is the report formatting function that delivers a variety of
reports for downstream or legacy-client consumption.   Information circulation
within the EARL system is up to the EARL community to determine.  The
implementation of these portal pages is required to understand the schemas in
which the backoffice bus of the EARL system is implemented.  The EARL
system is
a [grid a.k.a. web] of interoperating services that log information, register
that information with other information, collect an retain data reflecting the
information, and query and report what information is available in the
space of
virtual data created.  See Reagan Moore's output touting the push toward
"virtual-data grids."  The 'backoffice bus' common mode is the EARL _model_
expressed in RDF _model_-interoperable form.  So what the portal page
processor
has to understand, and shields the client population from, is the polyglot
world of RDF and its various bindings to syntax.

And this last part, that the service serving the EARL information at the
end of
whatever link comes out of the "every page" context SHALL practice
bestCurrentPractice DeviceIndependence practices is_a 'server-side WCAG 2"
clause for any metadata required by WCAG.

The reference from the "every page" context can come from an A in the
footer or
a LINK in the HEAD -- it doesn't matter which -- the service serving the
HREFed
URI-reference is responsible for the legibility and device- [including
legacy-]
independence of how the information is served to the public.  That's the basic
division of labor, here.

Al

>Jim.
>

Received on Sunday, 21 October 2001 12:28:48 UTC