Re: XHTML 2.0 - no interest in RDF/XML?

Masayasu Ishikawa <mimasa@w3.org> writes:

> Art.Barstow@nokia.com wrote:

> > I was thinking that XHTML 2.0 could do something like SMIL and SVG
> > have done with RDF/XML:
. . .
> >  [2] http://www.w3.org/TR/SVG/metadata.html
> 
> effort to accommodate RDF/XML.  DTD is just plainly incapable of
> handling it appropriately.

Probably, yes, in this context, but I think slightly overstated as a
general proposition in that either the attribute suite of an element
or the pcdata content model of an element can be re-modeled using new
element names.  While this is not likely to provide the full measure
of validation checking typically wanted in EDI contexts, it can
provide more mileage -- particularly when the content is being created
directly by error prone humans.

> . . .

> Validation is no longer a simple process,

(Has it ever been simple?  I didn't think it was simple back in 1994
when I was learning how to set up an early HTML validator.)

>                                           and we don't think we should
> require our user community to do such a complex process.

The user community has several segments including (1) server-side tool
writers, (2) content providers, (3) client-side tool writers, and
(4) client-side users.

We place no required burden on client-side users.

But now just what is the "complex process" in the context of future
XHTML?

For a given content format there is a specification, however it is
defined, and client-side tool writers need to know that specification.
But in the world of client-side XML, don't processors reject content
at the first sign of error?  I don't think that implies that XHTML
user agents must be capable of content validation.  In fact, won't
they still be able to operate more or less as they do now?

Indeed the design of XML as feature-stripped SGML was motivated by the
need to make things as simple as possible for XHTML user agent
writers.

So the burden of validation rests on content providers with a derived
burden on server-side tool writers, more specifically, content generation
tool writers.

In this context a rather complex process can take place reliably as
long as it is broken down into manageable tasks handled by cooperating
open standard (and I would also say open source) tools.

                                    -- Bill

Received on Friday, 16 August 2002 10:38:38 UTC