W3C home > Mailing lists > Public > www-html@w3.org > August 2000

Re: XHTML Invalidity / WML2 / New XHTML 1.1 Attribute

From: Dan Connolly <connolly@w3.org>
Date: Sat, 12 Aug 2000 11:50:04 -0500
Message-ID: <3995803C.EB5209FD@w3.org>
To: cavre@mindspring.com
CC: www-html@w3.org
Cavre wrote:
> ***********Bertilo Wennergren ***********
> On 8/12/00 at 1:15 PM Bertilo Wennergren wrote:
> <snip>
> </snip>
> > Having a util:comment attribute, however, is not the
> > same as having a comment attribute, unless the Schema
> > was universally recognised. Maybe the W3C should come
> > up with a library of Schema for people to use? (Such
> > as the one you kindly prepared for us).
> >All we need is a validator that allows for mixing of vocabularies.
> I hope I am not reading more into this than what your truly saying.
> Mixing vocabularies is a very BAD idea.

Always? You would disagree that mixing, say, XHTML with
MathML is a good idea?

>  If you send me a document
> with SMGL, XHTML, XML, HTML, and your own markup even given a
> DTD it would be nearly (but not impossible) to validate all this markup
> correctly.

I agree that using DTDs to deal with mixed vocabularies
is awkward, at best.

But XML Schemas are designed to handle it cleanly, and
in my experience, they do.

> No we need to agree upon a common vocabulary

Ubiquitously deployed vocabularies are critical indeed;
we need at least a few of those: XHTML, and soon I hope
MathML, RDF, XML Schema, XSLT, SVG, SMIL, and a few others.

But surely our technology should support a marketplace
of vocabularies, from internationally standardized
vocabularies to one-off agreements between me and
you for the week, and everthing in between, no?

This is what namespaces, RDF, and XML Schemas support.

> and if we need
> additional markup then we need to agree to use XML or XHTML
> with modules with a modified DTD that does validate only those
> documents that meet our needs.

I recommend namespaces and schemas, rather than DTDs.
DTDs have the same limitation that, say, C or emacs-lisp
programs have: one big namespace, and fragile mechanisms
for maintaining it.

> I do however agree that I need the option to include include several
> different markups within one document to be used by various agents.

Or sometimes, the same agent, no?

> For example -
> <SMGL>
>           <comment>This would only be displayed on my intranet.</comment>

If that's sensitive data, you'd better not count on
clients to keep it hidden. You'd better filter that

> </SMGL>
>            <icomment>This would only be displayed by agents with a approved
>              DTD. In other words validating correctly and ignored by all others
>            </icomment>
> </XHTML>

I don't think I understand what you meant by that.

Hmm... perhaps I do... perhaps it's analagous to writing:

	<i:comment xmlns:i="...your-URI-here...">

> <HTML>
>            <p>This would be displayed upon all devices able to handle HTML</p>
> </HTML>
> <WML>
>            <p>This would only be seen upon wireless devices.</p>
> </WML>
> etc........
> In this manner all additional markup would be ignored by any validator and
> parser if the parser or validator does not understand the vocabulary in question.

That's easier said than done... the rules for "ignoring"
tend to be quite tricky to deploy in an interoperable fashion.

I recommend you look at
	XSLT for explicit means of filtering and otherwise
		transforming data
	XML Schema <any> declarations, equivalence classes,
		refinement, and other extensibility mechanisms,
		for designing markup vocabularies that
		*explicitly allow* markup from other vocabularies
		in designated places.

> Also what if I am talking about Washington.  Am I talking about a person, a state,
> a city, a football team?

Then use
and bind myns: to a URI using XML namespaces, to make
it clear which Washington you're talking about.
Then make some sort of documentation available at
that URI; if you choose XML Schemas as your documentation
format, you can even validate it.


Dan Connolly, W3C http://www.w3.org/People/Connolly/
Received on Saturday, 12 August 2000 12:50:44 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:05:54 UTC