[
Lists Home |
Date Index |
Thread Index
]
- From: "Sebastian Schnitzenbaumer" <schnitz@overflow.de>
- To: Marc.McDonald@Design-Intelligence.com
- 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@ic.ac.uk
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@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)
|