Re: What are Semantics? (Was: Serving generic XML)

Yes, I wasn't suggesting that this mechanism could be used to convey the
meaning of tags in say an SVG document.

I was refering to (semi)linear text documents only.

And pointing out that the hard-coded knowledge in a UA which "tells it" that
an H1 is "a heading", so display it like this, or generate braille like
this, or produce this aural rendering... this hard-coded knowledge, which is
more than styling, could actually come from a seperate, downloadable file.
With this additional information, the UA could make XML just as accessible
as XHTML, if not more so.

Such a "more generic" UA could also be used in applications where XHTML is
not adequate, such as with legal, medical, patent, insurance and other XML
documents.  Such documents are (semi) linear text but semantically richer
than XHTML.

nik

----- Original Message -----
From: "Tantek Çelik" <tantek@cs.stanford.edu>
To: "Nicholas Atkinson" <nik@casawana.com>; <www-tag@w3.org>;
<www-style@w3.org>
Sent: 20 August 2002 02:57
Subject: Re: What are Semantics? (Was: Serving generic XML)


> Certainly XHTML is not one size that fits all.  It just so happens people
> produce a lot of (semi)linear text documents with hyperlinks which XHTML
is
> particularly well suited for.  However, there are also semantically richer
> languages like MathML, and languages like SVG more appropriate for
> information (e.g. maps) that is structured two dimensionally.  Or for
> information that is structured temporally there is SMIL.
>
> I don't think RDF does/cando what you think it can.  The only equivalent
of
> "TDF"s we have currently are the prose of the abovementioned
> language/vocabulary specifications.
>
> In the near future, Schemas could act as "micro-level" TDFs, and in fact,
> there is work to produce Schemas for the modules of XHTML
Modularization[1].
> Similar efforts to produce schemas for these other semantically rich
> languages would probably be helpful.  Perhaps over time Schemas can evolve
> to describe higher level data/content types (i.e. more than just
> hierarchies/aggregations of simple data/content types), eventually
reaching
> the point where you can describe that a <headline> tag means "a header" in
> an XSD.
>
> But until we reach that point (and perhaps even for some transitional
> period), we will need to continue to specify semantically rich
vocabularies
> one at a time, using prose definitions in W3C specs.
>
> Tantek
>
> [1]
>  http://www.w3.org/TR/2001/WD-xhtml-m12n-schema-20011219/
>
>
> On 8/19/02 5:44 PM, "Nicholas Atkinson" <nik@casawana.com> wrote:
>
> >
> > The "prescriptive" approach of saying that everyone should use XHTML is
one
> > approach.  However many people don't like being prescribed to!  And one
size
> > doesn't fit all.
> >
> > Another approach, perhaps more "enabling", would be to say that we
recognise
> > that XML + CSS style only gives a UA _part_ of what it needs (it is not
> > sufficient for
> > accessibility, for instance), and that authors need some
(machine-readable)
> > way of publishing what their XML tags mean.
> >
> > UAs would be able to retrieve/cache this "XML Tag Description file" in
the
> > background and would be able to determine definitively that in a
specific
> > document "<headline>" is "a header" (provided that "a header" is one of
an
> > agreed set of "meanings" managed by a central authority or organisation
such
> > as the w3c).  The UA would then be able to provide the appropriate
> > accessible rendering.  (and clearly there are other applications too.)
> >
> > All we would need is an agreed (presumably XML) syntax for this "Tag
> > Description File" and, crucially, an agreed set of standard "meanings".
> > This set of standard meanings could be far richer than the semantics
that
> > XHTML supports.
> >
> > Obviously, the more subtle the meaning, the less likely it is that it
could
> > possibly be agreed upon.  But for meanings such as visual conventions
like
> > "a heading", or non-visual meanings such as "a patient", "a dentist", "a
> > credit card number", "a longitude and latitude", "a temperature" or "a
> > flight number" it is pretty clear-cut and unequivocal what they mean.
> > Indeed we could have hierarchies of such meanings, or rather
"ontologies".
> >
> > But hang on, such a "Tag Description File" already exists!!!!  Isn't
this
> > the kind of thing that RDF can/could do.
> >
> > So, after that lengthy preamble, my point is that instead of going down
the
> > XHTML route (which doesn't lead anywhere) why don't we "cut to the
chase"
> > and go down the XML + CSS + RDF route.
> >
> > RDF (or something similar) could be used by UAs to determine the
"missing
> > knowledge" required to produce accessible renderings and in a whole host
of
> > other applications, because it would indicate to UAs what the tags
"mean".
> >
> > Isn't that the whole point?
> >
> > nik
> >
>

Received on Tuesday, 20 August 2002 07:15:09 UTC