[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: RFP: Namespace URI for HTML

• From: "Sebastian Schnitzenbaumer" <schnitz@o...>
• To: Marc.McDonald@D...
• Date: Fri, 10 Sep 1999 01:24:01 +0200

> But an HTML processor is supposed to accept a well-formed document and
> gracefully ignore unknown elements (actually treat them as text). So, what
> happens when your cellphone microbrowser gets a frameset document instead of
> a strict document? Does it just put up an error box and show nothing? How
> does a non-validating parser ensure a document is frameset or strict?

In this specific scenario, there will be transformation on a proxy 
server, trying to make the best out of it. But the microbrowser itself 
might just render documents of a specific type.

> Namespaces do not define the set of valid names, they only allow
> differentiation. Without validation there is no enforcement that a document
> is strict, frameset or transitional. Since the namespace declaration has no
> enforced meaning, why bother with it? 

Differentiation is the point. Strict, frameset and transitional are only 
the base family members. It is likely that there will be a larger 
XHTML family, where family members will be even more different 
than just those three. As I said in my first mail, there is more to it 
and I'll continue here.

HTML is a damn useful vocabulary after all. Designing a completely 
new XML language is often the only way. But sometimes, a new 
application is rather a mixture of the features that HTML (or a 
subset of HTML) already provides together with entirely new 
features. In this case, one would re-use a subset of HTML in a new 
XML language, forming a new XHTML family member. 

If my new language wants to allow the use of images, instead of 
inventing my own tags, why not take the image module from 
XHTML, authors will be happy since they don't have to learn 
something new.

Lets go a bit further. You have written a new XML language for 
Forms. In the end you realize that the part dealing with form 
controls and forms logic is fine, but the visual representation of 
forms, ie. the definition of the page, the text formatting and layout 
is actually better done by HTML. You take a subset of XHTML for 
that part.

Your language is bound together with a subset of XHTML, but is 
still a new, unique XML grammar. If all XHTML variants were one 
namespace, then that XHTML subset being used in this new XML 
grammar would also belong to the XHTML namespace. The new 
language would need the change the default namespace from 
XHTML to the rest of the language all the time or use colons. But 
logically, this is a different kind of animal, and should have its own, 
unique namespace so applications can identify it as such.

> The only reason I've seen presented is fragments. BUT, there is a fragments
> working group, why not let them find a general solution to the problem? Why
> are you usurping their authority?

I just wanted to point out that it is sometimes handy to exactly 
know what kind of XHTML this is, especially when we have many 
different XHTMLs. Fragments were just an example, I'm not 
usurping anyones authority.

Regards,

Sebastian
---
Stack Overflow AG
Phone: +49-89-767363-70

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i...
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo@i... the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@i... the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@i...)

• References:
  • RE: RFP: Namespace URI for HTML
    • From: Marc.McDonald@D...

• Prev by Date: Re: RFP: Namespace URI for HTML
• Next by Date: RE: RFP: Namespace URI for HTML
• Previous by thread: RE: RFP: Namespace URI for HTML
• Next by thread: RE: RFP: Namespace URI for HTML
• Index(es):
  • Date
  • Thread