The Namespaces Recommendation is at
http://www.w3.org/TR/1999/REC-xml-names-19990114/
The best explanation of namespaces was written by James Clark and can be found at http://www.jclark.com/xml/xmlns.htm James's paper should be required reading for anyone involved in a discussion of namespaces.
Namespaces were discussed exhaustively at least twice on the WG/SIG. Avaliable to the public is the discussion of Microsoft's "Structured Data" proposal in May '97: SD5 was about namespaces. <URL:http://lists.w3.org/Archive/Public/w3c-sgml-wg/1997May/>
------------------------------
What are namespaces all about?
Namespaces are about unique identification; they are not about meaning. Identification is necessary to the establishment of meaning, but it does not constitute meaning in itself.
-----------------------------
What are namespaces good for?
It might be thought that mere identification is not worth much, but the designers of the namespace recommendation thought otherwise. Namespace declarations give us a way to confer upon element types and attribute names a unique identity. This does not tell us anything about what such names mean, but it does provide a way to unambiguously associate an unlimited number of different kinds of processes with objects having the names so distinguished. It allows us to say, "this thing here has a certain quality (its type or name) that is identical to the corresponding quality of the thing in that place over there," regardless of where, when, and in what context these things are actually discovered, together or separately. On the basis of that ability, we trust that we can apply processes to elements having a particular type, or to attributes having a particular name, and be reasonably sure that such processes will not be applied to other elements or attributes that seem to have the same type or name but really belong to some other category. This is considered to be a Good Thing.
My favorite description of the function of namespaces comes from one of the editors of the Namespaces Recommendation, Tim Bray: namespaces are a device "for allowing programmers to write programs that will reliably find the items of information that they are designed to process even in a distributed and heterogeneous environment."
Another, I think equally valid, view of the function of namespaces as they are defined in the Recommendation was given to me by another one of the editors, Dave Hollander: allowing us to avoid name collisions is an essential step toward being able to form new documents consisting of pieces from other documents without forcing us to change the element types or attribute names.
----------------------------------
What kind of thing is a namespace?
A namespace is a collection of names. Each name in this collection is a pair consisting of the namespace name and a colon-free XML 1.0 name. The namespace name has the form of a URI reference. URIs were chosen for this purpose primarily because they (or at least their URL subset) are under the control of a naming authority. A URL in this role is really performing the function that URNs are intended to perform; URLs were allowed to serve in this place because it's possible to administer URLs so that they work as URNs, and because URNs were an unproven technology.
A namespace is an abstract object. Namespaces live in the same place as other abstract objects such as the set of letters of the alphabet, the set of words in the English language, and the set of integers. The namespace itself is distinct from anything that might be associated with it and belongs to a level of reality different from the kinds of things that we typically would want to associate with it.
(Whether names have real existence is an interesting question. Persons wishing to pursue this matter can start with the article in any large encyclopedia under the heading "Realism" or "Nominalism," where they will discover that this issue, while not completely resolved, has already received some attention.)
--------------------------------------
What kind of thing is not a namespace?
Anything that is not a name is not a part of a namespace; a namespace can have nothing but names in it. Here are some important examples of things that are not namespaces:
- A list of the names in a namespace
- A sequence of characters that can be interpreted as a list of the names in a namespace
- A description of the things named by the names in a namespace
- A set of constraints on the things named by the names in a namespace
- A set of procedures associated with the things named by the names in a namespace
-----------------------------------
What does a namespace URI refer to?
The URI in a namespace declaration may or may not refer to an actual resource that can be retrieved by a computer; if it does, the resource so identified may or may not have useful things to tell us about things labeled with the names associated with the URI. The statement in the Namespaces Recommendation that "It is not a goal that it [the namespace URI] be directly usable for retrieval of a schema (if any exists)" is not mere rhetorical fluff but rather represents a concrete position taken by the XML Working Group after months of debate and in direct opposition to an equally concrete point of view to the contrary. In the word's of James Clark's paper (cited above):
The role of the URI in a universal name is purely to allow applications to recognize the name. There are no guarantees about the resource identified by the URI.
Some future Namespaces Recommendation _could_ say that namespace URIs are expected to resolve to a resource or are required to resolve to a resource. However, the Namespaces Recommendation that we actually have chose, very deliberately, to say that the utility of Namespaces in XML does not depend on what (if any) resource is at the other end of a URI.
As James notes in the same paper:
It would of course be very useful to have namespace-aware validation: to be able to associate each URI used in a universal name with some sort of schema (similar to a DTD) and be able to validate a document using multiple such URIs with respect to the schemas for all of the URIs. The XML Namespaces Recommendation does _not_ provide this.
A good reason for not providing an explicit association between namespaces and schemas is to allow namespaces to be associated with things other than schemas and to allow them to be associated with multiple expressions of the same schema, as for example a schema expressed as a DTD and the same schema expressed using the eventual W3C XML Schema language.
--------------------------------------------------------
What kinds of things can be associated with a namespace? Just about anything can be associated with a namespace. Some of the more useful kinds of things that can be associated with namespaces are stylesheets, Java classes, DTDs, Active-X objects, extended linking groups, schemas, and prose descriptions.
----------------------------------------------------------------------
Is a there a one-to-one correspondence between namespaces and schemas? With the understanding that this question has meaning only in the relatively small class of all possible uses of namespaces in which they are being used in conjunction with schemas, the answer is no, there is not a one-to-one correspondence between namespaces and schemas. One namespace may be associated with multiple schemas; it has been common practice for years to apply multiple schemas (DTDs) to documents in order to check them against different sets of constraints. Conversely, it is easy to imagine cases where multiple namespaces might be used within documents that conform to a single schema. David Megginson has provided a simple example:
a geographical markup language...might use separate Namespaces for land elevation, coastline information, and land use to help avoid naming conflicts...
And, of course, a DTD can be generated for any arbitrary well-formed document that happens to include names from multiple namespaces. This scenario is admittedly artificial, but it proves that the association of multiple namespaces with a single schema is always possible.
Since there is no necessary association between a namespace and anything in particular, there is no necessary association between a namespace and a schema, and it follows from this that all arguments based on the assumption of a necessary mapping from a single namespace to a single schema are invalid on their face. This includes in particular the argument that XHTML should use more than one namespace because it specifies more than one DTD. This is not to say that the conclusion that XHTML should have multiple namespaces is false, it's just to say that you can't adduce a one-to-one mapping between namespaces and schemas as a premise for that argument.
-------------------------------------
Should XHTML use multiple namespaces?
I agree with David Megginson that "the HTML WG [should] maintain a single HTML Namespace as long as practical and find another mechanism to indicate flavours and versioning." Among the reasons that can be brought for this view, I find the following most convincing:
- The main argument for specifying three namespaces for XHTML rests on the assumption that there is a one-to-one association between namespaces and schemas. This is not true.
- A second argument for specifying three namespaces is that it's intended to indicate that XHTML actually specifies three different tag languages and that <h2> in one of these languages means something basically different from <h2> in the other two. In my opinion, <h2> means basically the same thing in all three versions. This is why we call all three of them "XHTML." HTML 4 has three DTDs, too, but no one has suggested that HTML 4 is actually three different languages. Lauren Wood has pointed out to me that SoftQuad's HTML authoring tool has used something like 15 different HTML DTDs in the lifetime of the product. It would seem strange to say that the people using the product were actually working in 15 different languages, all of them called HTML. This is not what we usually mean by the word "language." I think that the HTML WG should reconsider whether it's really defining three different languages, being careful to distinguish between a machine-readable structural description such as that provided by a DTD and a complete human-readable statement of its meaning such as that provided by a complete and accurate prose description. If the HTML WG decides to maintain the position that XHTML is defining three different languages, then it should be ready to explain how an <h2> in one would materially differ in meaning from an <h2> in another, "meaning" here being expressed in terms of the intention of the person who causes elements to have the type "h2."
- Another way of making what I believe to be essentially the same
point is that distinctions between a strict <h2> and a
transitional <h2> are not reflected in actual machine processing
outside of validation.
- If XHTML really is several languages and the similarly named elements of those languages really are different from each other, then those different languages are going to require different HTML DOMs. ---- Jon Bosak <Jon.Bosak@eng.sun.com>
Namespaces
Interested in exploring alternative models for creating XML vocabularies and applications, a rough draft at: http://www.simonstl.com/articles/doubting.htm Namespaces basically do nothing but sow confusion, as noted in previous message threads about namespaces and validation.
As a namespace declaration is a URI and doesn't have the option of a URL, there is no way for it refer to a DTD or schema defintion. So, the namespace prefix merely differentiates 2 names foo:bar and zoo:bar.
But, foo:bar and zoo:bar may be the same if the URI's are the same. It is not enough to compare prefixes, you must compare URIs. And the idea of equivalent URIs would render even that comparision inaccurate. So the best you can say is that foo:bar and foo:bar refer to the same element and foo:bar and zoo:bar may refer to different elements. But, you can't determine what the valid members of foo or zoo are.
Adding validation really makes it messy. If the document using the DTD uses namespace prefixes, then the DTD must use the same namespace prefixes (foo:bar is not the same as bar). There are no declarations for a DTD to define a default namespace.
So, for validation, standard prefixes must be established for namespaces (the document and DTD must use same prefixes). Of course the prefixes could collide and then we're back in the same boat as before.
I truly question the value of namespaces without association with some DTD or schema. They purport to resolve ambiguity, but only do it syntically - there is no identification of what each element is a member of. The problem is punted off to the application, which somehow must assign meaning to the URIs. In doing so, validation is thrown to the wind - we might as well redefine XML to only parse well-formed documents and toss the DTD baggage.
Through associating a URI with a schema or DTD such identication can be added. So why not do it as a optional parameter, add declaration of default namespaces to DTDs/Schemas, and get it done with?
(I know DTDs just provide a content syntax and not a full semantic meaning, but at least syntactic validity can be performed. I can tell if an element is not part of a DTD (unless it makes use of ANY of course))
All right, a new namespace firestorm begins ;) ---- Marc B. McDonald, Principal Software Scientist, Design Intelligence, Inc. http://www.design-intelligence.com
==========
Namespaces - there is a big advantage over simple prefix matching because prefixes cannot be guaranteed unique, and Namespace URIs can.
Namespaces are already in use all over the place-- the implementation-specific behavior of among different processors might vary, but the integration of namespaces w/XML ver 1.0 doesn't appear to be "impossible", and certainly isn't the culprit for the inconsistencies between the different "namespace aware" applications.
-- XSL and XSLT namespaces are currently being used all the time
-- HTML namespaces are being "used reliably" in IE5
-- Even RSS's erroneous RDF namespace declaration does nothing reliably every time :-)
I am confused about XML namespaces
I would like to get some and look at them but there does not seem to me to be any available or I am blind.
Do namespaces get defined in DTD's or are they special XML files or can they be defined in the new xml-Schema spec?
How would I define my own for my own application? The spec tells how to use them and refer to them, but I do not see how to make them?????
The reason you haven't been able to "get and look at" some namespaces isn't that you are blind. It's that a namespace is an ad-hoc solution to a general problem -- there's nothing to "look at" except *references* to a namespace.
For starters, no, namespaces aren't typically defined in DTDs, and they're not XML files in their own right, and you don't need XML Schema in order to use one.
Let's take an XSL style sheet as (I think) the easiest case in which to understand how a namespace might be useful. Since XSL style sheets are XML documents which *refer to* other XML documents, the style sheets' content is well-formed XML, consisting of a mix of the elements you want to put in the result tree (i.e., what you're transforming the source tree into -- say, HTML) and the elements that are actually part of XSL. Without namespaces, it's potentially real confusing which of those two classes of XML are which. The namespace-defining attributes to the <xsl:stylesheet> element simply declare (typically) "all elements with the following prefix [usually "xsl:"] in their names should be considered to belong to the XSL namespace, and all elements with no prefix in their names at all should be considered to belong to the result tree's namespace."
So "namespace" is really just an overarching term for all the XML *in a given document instance* which belongs to one XML vocabulary, vs. all the XML *in the same document instance* which belongs to others. In theory, the URI associated with a namespace prefix might point to the definition -- the DTD -- for documents in the namespace, but actually that's not required. All that's required is that the prefixes be unique.
So that's why you haven't been able to find a namespace: there's no "there" there. To use a namespace in a given document, simply declare a prefix for it, point the prefix to some unique URI (which doesn't even have to be a specific file), and include the prefix in any element name taken from that particular vocabulary.
Does that help? John E. Simpson Just XML (ISBN 0-13-943417-8) Available now from Prentice Hall PTR
Internal subset, external subset, Namespaces in XML.
At 11:42 AM 8/23/1999 -0400, Blair, Edward (Ed), BCARE wrote:
>I've been writing some XSL stylesheets to do transformations from XML into
>HTML. Currently I am using the XML namespace URI
>"xmlns:xsl="http://www.w3.org/TR/WD-xsl".
>
>I know that for right now my document isn't really "doing" anything with
>this information. It's doesn't reference the URI in an interactive capacity,
>no validity checks are being done, it's just a placeholder for the day when
>XML applications really start to do something with namespaces (and URI's for
>that matter).
>
>But here's my problem, what if one day the URI's get "turned on" by, say, a
>new browser that can do client-side XML processing. And what if the URI I
>reference has moved, or isn't backward compatible to spec it was when I both
>used and referenced it? Will it make the browser choke and the end-user end
>up with a pile of error messages?
A couple of thoughts:
1. You probably already know this, but even though the namespace URIs don't
necessarily point to anything in particular, existing XSL processors *do*
"react" in particular ways to particular URIs. That is, if you want your
result tree to be in HTML 4.0 but its namespace declaration points
elsewhere, you will probably find that certain built-in HTML constructs
(like entities) get goofed up.
2. If the URI you've referenced has moved, a couple of things might happen.
Browsers will probably have a default style for style sheet-less XML, a la
IE5's collapsible/expandable tree of elements. So all will not be lost, and
the user won't end up with a pile of error messages (assuming your XML is
well-formed :). Or yes, the browser might choke, giving the equivalent of
a 404 Not Found just as it does now. But this is actually one of the
advantages of a namespace URI that points to nothing in particular:
applications that presume that it DOES point to something in particular
will do so at their own (and of course, their users') peril.
>Should I avoid using external namespace URI's that I have no control over
>until I can verify they won't cause a problem?
No, don't avoid it. If the URI is a reasonably trustworthy one your
problems should be minimal, and avoiding anything that you personally don't
have control over means you might as well go back to cuneiform.
If this still really bothers you, parameterize the namespace URI so you can
easily change it in the future.
Just $.02 (US).
=============================================================
John E. Simpson | It's no disgrace t'be poor,
simpson@polaris.net | but it might as well be.
| -- "Kin" Hubbard
> To use a namespace in a given document, simply declare a prefix for
> it, point the prefix to some unique URI (which doesn't even have to be a
> specific file), and include the prefix in any element name taken from that
> particular vocabulary.
> ====================
> John E. Simpson
I'm starting to get the picture here myself John et. al. and considering the
following code
snippet understand the author of such to have used 4 different namespaces:
rdf, ocs, dc, and dcq...
> <?xml version="1.0"?>
> <rdf:RDF
> xmlns:rdf = "Error! Hyperlink reference not valid."
> xmlns:ocs = "Error! Hyperlink reference not valid."
> xmlns:dc = "http://purl.org/dc/elements/1.0/"
> xmlns:dcq = "http://purl.org/dc/qualifiers/1.0/">
Each namespace is used for semantic distinction as can be deduced by
reading:
> <dc:subject>
> <rdf:Description>
> <dcq:subjectScheme>DDC Local</dcq:subjectScheme>
> <rdf:value>#Channels.DDC#</rdf:value>
> </rdf:Description>
> </dc:subject>
Where the 'dc' represents the Dublin Core which establishes the semantics
for the word 'subject' as distinct from that of 'dcq' which uses
'subjectScheme' in this example but may also in fact use
the word 'subject' elsewhere in the form dcq:subject so as to have an
entirely different meaning than that of dc:subject.
What makes this all so ambiguous though is not the understanding of how to
resolve verbiage conflict resolution but the unreal aspect of "there not
being there" which only leaves one's mind reeling with the question of how
the conflict is actually resolved specifically with respects to what we all
understand 'meaning' or 'semantics' to actually mean in and of itself.
Lots of babble just to ask how is meaning really conveyed within a specific
namespace and then how is such meaning differentiated between two different
namespaces?
--Regards
Clinton Gallagher
http://www.metromilwaukee.com/
At 12:22 PM 8/24/1999 -0500, WorldNet wrote:
>I'm starting to get the picture here myself John et. al. and considering the
>following code
>snippet understand the author of such to have used 4 different namespaces:
>rdf, ocs, dc, and dcq...
>
> > <?xml version="1.0"?>
> > <rdf:RDF
> > xmlns:rdf = "Error! Hyperlink reference not valid."
> > xmlns:ocs = "Error! Hyperlink reference not valid."
> > xmlns:dc = "http://purl.org/dc/elements/1.0/"
> > xmlns:dcq = "http://purl.org/dc/qualifiers/1.0/">
>
>Each namespace is used for semantic distinction as can be deduced by
>reading:
>
> > <dc:subject>
> > <rdf:Description>
> > <dcq:subjectScheme>DDC Local</dcq:subjectScheme>
> > <rdf:value>#Channels.DDC#</rdf:value>
> > </rdf:Description>
> > </dc:subject>
>
>Where the 'dc' represents the Dublin Core which establishes the semantics
>for the word 'subject' as distinct from that of 'dcq' which uses
>'subjectScheme' in this example but may also in fact use
>the word 'subject' elsewhere in the form dcq:subject so as to have an
>entirely different meaning than that of dc:subject.
Right.
>What makes this all so ambiguous though is not the understanding of how to
>resolve verbiage conflict resolution but the unreal aspect of "there not
>being there" which only leaves one's mind reeling with the question of how
>the conflict is actually resolved specifically with respects to what we all
>understand 'meaning' or 'semantics' to actually mean in and of itself.
Forget about anything being resolved in the way that we're familiar with
the term "resolution" in HTTP-land. In effect, what a namespace-aware
processor does is *internally* replace all occurrences of the prefix string
with all occurrences of the full URI. (Some fool around with the special
characters, replacing /s with _s or whatever.) That is the only purpose
addressed by the current namespace spec -- to disambiguate (!) markup
originating from two different vocabularies that just happen to be
momentarily sharing the same physical space (i.e. a file/document).
>Lots of babble just to ask how is meaning really conveyed within a specific
>namespace and then how is such meaning differentiated between two different
>namespaces?
True "meaning" in this sense isn't inherent in the markup or even the
namespace declaration(s). The meaning of a namespace, I guess you could
say, can't be determined on its own -- only an application sensitive to
that particular namespace can assign a meaning. To an RDF-namespace-aware
processor, the XSL namespace is meaningless, and vice-versa. (Of course
someday someone may develop an app that's BOTH RDF- and XSL-aware, but you
get the idea.)
=============================================================
John E. Simpson | It's no disgrace t'be poor,
simpson@polaris.net | but it might as well be.
| -- "Kin" Hubbard
A very (very!) rough draft of a specification that allows us to reliably
interpret variants of a particular document type. I wrote this a few
months ago but never got time to clean it up and solicit comments. Now
seems like a good time even if I can't clean it up right now.
----
It is often the case that two namespaces will be very similar but not quite identical. In this case "similar" means that the semantics and structures associated with names might be "close enough" for all processing associated with one namespace to also apply to the other. The namespaces specification does not address this issue.
This specification describes a convention for stating that namespaces are similar and formally stating the nature of the similarlity.
The scope of these declarations is the directly containing element and all of that element's children which follow the declaring element.
The <xmlns:evolution href=""> element states that the attributes on the
The <xmlns:same-name newURI="" newName="" oldURI="" oldName=""> states that the given name in the namespace "new" can be interpreted as identical to the name oldName in the namespace oldURI. So HTML 4.0 strict's A element type would be the same-name as HTML 4.0 loose's A element type.
The <xmlns:subset newURI="" oldURI="" exceptions=""> element states that any name in the namespace "new" can be directly interpreted as a name in the namespace "old" except for the names specified in the exceptions attribute. So HTML 4.0 would be identical to HTML 3.0, except for the APPLET tag and some other similar stuff.
The <xmlns:suppress newURI="" oldURI="" names=""> element states that elements and attributes with the listed names in the new namespace should be ignored by applications understanding only the old namespace. It should be as if they did not exist. For instance, HTML BGCOLOR attribute and BGSOUND element.
The <xmlns:suppress-unknown-content newURI="" oldURI="" names=""> element states that sub-elements of the element that are not known by the application to be part of oldURI should be surpressed. For instance, HTML APPLET or OBJECT.
The
<xmlns:transform newURI="" newName="" oldURI="" oldName="">
<xmlns:transformation lang="" uri=""/>
<xmlns:transformation lang="" uri=""/>
</xml:transform>
element states that the name newName in namespace newURI can be interpreted as equivalent to the name oldName in the namespace oldURI after the application of any of the given transformations. The lang attribute is a URI that identifies the transformation language. The lang attribute is optional if the transformation is defined in prose (for instance an "ignore elements that start with _" rule might be globally understood).
Recommended transformation languages include XSLT, STTS, DSSSL, XML architectural forms (with or without a meta-dtd) and a Javascript/DOM program).
Using the built-in transformational elements is superior to referring to an external transformation because they are guaranteed to be universally implemented.
Using an external transformation in a simple, standardized external language is better than using an external transformation in a complex, standardized external language but it increases the liklihood of implementation.
Using an external transformation in a standardized language is better than using one in an unstandardized language. The other option is provided only because some applications may require the extra flexibility of pointing (e.g.) to Java classes or an Active-X program.
Paul Prescod
=============
> As there is no defined mechanism for namespace processing and it seems
> that with xmlns and contained elements "inheriting" namespaces, you would
> still need some mechanism to recognize namespaces and it would be folly to
> use current non-recognizing parsers anyway.
There is no defined mechanism for the processing per se, but there are
several models for the result of the processing; see
http://www.w3.org/TR/xml-infoset
http://www.w3.org/TR/xpath#namespace-nodes
http://www.w3.org/TR/xslt#data-model
http://www.w3.org/TR/WD-DOM-Level-2/namespaces.html
(These are the public versions -- internal, in-progress versions may
differ.) While there are significant variations in the details, all
of these adhere to a basic model: for every element or attribute name
in a document, you are able to obtain at least the following
information:
1. The Namespace URI, if any.
2. The local part of the name.
Some of these go further, and make available additional information:
3. The original prefix that was mapped to the Namespace URI.
4. The original attributes used for the Namespace declarations.
Nevertheless, just 1 and 2 together provide a pretty clear picture of
how Namespace processing works. If SAX were being designed now, it
would probably have
void startElement (String uri, String name, AttributeList atts);
void endElement (String uri, String name);
etc.
If you're working directly in a procedural programming language like
Perl or Java, it's fairly straight-forward (if somewhat inefficient)
to check for three qualified names instead of one:
boolean isAnHTMLNamespace (String uri)
{
return uri.equals("http://www.w3.org/TR/xhtml1/strict") ||
uri.equals("http://www.w3.org/TR/xhtml1/transitional") ||
uri.equals("http://www.w3.org/TR/xhtml1/frameset);
}
In Java, especially, you might take a hit for doing so, though, if
your interface happens to deliver the names in a single string:
"{http://www.w3.org/TR/xhtml1/strict}a"
Furthermore, there's a deployment problem. If the next version of
XHTML also has a different Namespace, then you'll need
boolean isAnHTMLNamespace (String uri)
{
return uri.equals("http://www.w3.org/TR/xhtml1/strict") ||
uri.equals("http://www.w3.org/TR/xhtml1/transitional") ||
uri.equals("http://www.w3.org/TR/xhtml1/frameset) ||
uri.equals("http://www.w3.org/TR/xhtml1.1");
}
Some software will have this, and some will still have only the old
ones, so the only safe way to work will be to keep using the original
XHTML Namespaces forever and ever.
Things get even nastier in higher-level languages like template
languages or search/query languages, where it's no longer possible to
define your own subroutines to factor out the complexity.
All the best,
David
--
David Megginson david@megginson.com
http://www.megginson.com/
========
> Namespaces are about unique identification; they are not about
> meaning. Identification is necessary to the establishment of meaning,
> but it does not constitute meaning in itself.
>
> [followed by a long discussion to the point that namespaces govern identity in the
> encoding and decoding process only and leading to the following conclusions: ]
>
> -------------------------------------
> Should XHTML use multiple namespaces?
> -------------------------------------
>
> ...
>
> - The main argument for specifying three namespaces for XHTML rests
> on the assumption that there is a one-to-one association between
> namespaces and schemas. This is not true.
as established above, it is also insignificant.
>
> - A second argument for specifying three namespaces is that it's
> intended to indicate that XHTML actually specifies three different
> tag languages and that <h2> in one of these languages means
> something basically different from <h2> in the other two. In my
> opinion, <h2> means basically the same thing in all three
> versions. ...
> ... If the HTML WG decides to maintain the position that
> XHTML is defining three different languages, then it should be
> ready to explain how an <h2> in one would materially differ in
> meaning from an <h2> in another, "meaning" here being expressed in
> terms of the intention of the person who causes elements to have
> the type "h2."
which is also, as established above, insignificant.
>
> - Another way of making what I believe to be essentially the same
> point is that distinctions between a strict <h2> and a
> transitional <h2> are not reflected in actual machine processing
> outside of validation.
which decides the issue. as the namespaces are about unambiguously identifying
the encoded specifications for the validation, it is appropriate to make
adequate distinctions.
? is it specified somewhere that the various XHTML forms will never appear in
the same document?
>
> - If XHTML really is several languages and the similarly named
> elements of those languages really are different from each other,
> then those different languages are going to require different HTML
> DOMs.
i don't understand this one: if the variants are in different namespaces, then
elements of each could well be mixed in the same dom instance. isn't that the
point of the whole thing?