So, per the analysis in , where do we stand today wrt the W3C XML
Schema Datatypes specification's claim  that
Each built-in datatype defined in this specification can be uniquely
addressed via a URI Reference constructed as follows:
* the base URI is the URI of the XML Schema namespace
* the fragment identifier is the name of the datatype
For example, to address the int datatype, the URI is:
As of today, three representations are available via content
negotiation from the XML Schema namespace URI. One of them is
returned with a 200 in response to any GET of
http://www.w3.org/2001/XMLSchema, depending on the Accept header in
the request, as follows:
DOC2 is an XML document, a W3C XML Schema schema document, valid per
the DTD for schema documents.
Are the media types of these three representations "type-consistent
for int", as defined in my previous email ?
For text/html (R1), per the "[r]egistration of MIME media type
"[a] fragment identifier designates the correspondingly named
element; any element may be named with the 'id' attribute, and A,
APPLET, FRAME, IFRAME, IMG and MAP elements may be named with a
so fragids like 'int' identify elements.
For application/xhtml+xml (R2), per the "[r]egistration of MIME media
type application/xhtml+xml" 
"fragment identifiers for XHTML documents designate the element
with the corresponding ID attribute value (see [XML] section
3.3.1); any XHTML element with the "id" attribute."
so fragids like 'int' identify XHTML elements.
I think we can say that text/html and application/xhtml+xml are
type-consistent for int on that basis.
For application/xml (R3), per the "[a]pplication/xml Registration" 
"As of today, no established specifications define identifiers for
XML media types."
Insofar as the official story then, text/html and application/xml are
type-consisent for int, as are application/xhtml+xml and
application/xml, since application/xml _has_ no definition
But in the unofficial story, widely implemented in practice and now
_nearly_ official in the not-yet-approved updated media type
registration for the XML Media Types , we find
"Conformant applications MUST interpret such fragment identifiers
as designating that part of the retrieved representation specified
by [XPointerFramework] and whatever other specifications define any
XPointer schemes used. Conformant applications MUST support the
'element' scheme as defined in [XPointerElement]."
This amounts to saying that two forms of fragid, namely barenames and
strings roughly of the form 'element([barename](/digits)*)', "identify
element[s] in the resource's information set" 
Again, I think that's close enough. So even on the "in practice/in
the future" story about application/xml, we can conclude that
text/html and application/xml are type-consisent for int, as are
application/xhtml+xml and application/xml.
So _that's_ good: the W3C is not committing a server management error
as things stand.
And, trivially, since in _none_ of the three representations are _any_
fragids multiply defined in inconsistent ways.
Some fragids have definitions in both R1 and R2, not surprisingly, but
they are, again not surprisingly, for "the same" element, so no
problem there. On some readings of the above definitions for
text/html vs. application/xhtml+xml, so fragids have definitions only
in R1, but again, that's not a problem.
A large number of fragids have definitions in R3, but there is no
intersection between this set and the R1/R2 set, so _that's_ alright
too. [We leave as an exercise to the reader whether, supposing my
advice in  had been followed, and the document at  been served
in place of R1/R2, things would have broken at the token-inconsistency
So with respect to (my expanded version of) WebArch, nothing is
fundamentally _broken_ about the _status quo_. The only problem is
with the broken _promise_ in the Schema spec. Jonathan Rees has made and Tim
Berners-Lee has endorsed and elaborated a recommendation that RDFa is
the answer. My next message will explore this from the perspective