legal <xml> tag

[Nice]

Hi.
I read somewhere that in XML the tag <xml> is not legal.
But in W3C specs I can't find this statement.
Does anyone know about it ?

 

[Dimitre Novatchev]

Hi.
I read somewhere that in XML the tag <xml> is not legal.
But in W3C specs I can't find this statement.
Does anyone know about it ?

It is perfectly legal. What is not legal is the *prefix* "xml", because it
is already associated in advance to the following namespace-uri:
http://www.w3.org/XML/1998/namespace
and this association should not be changed/redefined.

"Namespace Constraint: Leading "XML"
Prefixes beginning with the three-letter sequence x, m, l, in any case
combination, are reserved for use by XML and XML-related specifications. "
http://www.w3.org/TR/REC-xml-names/#xmlReserved


Hope this helped.


=====
Cheers,

Dimitre Novatchev.
http://fxsl.sourceforge.net/ -- the home of FXSL

 

[Julian F. Reschke]

It is perfectly legal. What is not legal is the *prefix* "xml", because it
is already associated in advance to the following namespace-uri:
http://www.w3.org/XML/1998/namespace
and this association should not be changed/redefined.

"Namespace Constraint: Leading "XML"
Prefixes beginning with the three-letter sequence x, m, l, in any case
combination, are reserved for use by XML and XML-related specifications. "
http://www.w3.org/TR/REC-xml-names/#xmlReserved


Hope this helped.

XML 1.0:

"[Definition: A Name is a token beginning with a letter or one of a few
punctuation characters, and continuing with letters, digits, hyphens,
underscores, colons, or full stops, together known as name characters.]
Names beginning with the string "xml", or any string which would match
(('X'|'x') ('M'|'m') ('L'|'l')), are reserved for standardization in this or
future versions of this specification."

 

[Andy Dingley]

I read somewhere that in XML the tag <xml> is not legal.

The element <XML> is a Microsoft extension to HTML and so is not valid
_for_ _the_ _HTML_ _DTD_.

In XML, I can see no reason why <xml> wouldn't be valid in some
self-generated document or schema.

 

[Nice]

Thanks to all, I had my doubts resolved.

 

[Dimitre Novatchev]

It is perfectly legal. What is not legal is the *prefix* "xml", because it
is already associated in advance to the following namespace-uri:
http://www.w3.org/XML/1998/namespace
and this association should not be changed/redefined.

"Namespace Constraint: Leading "XML"
Prefixes beginning with the three-letter sequence x, m, l, in any case
combination, are reserved for use by XML and XML-related specifications. "
http://www.w3.org/TR/REC-xml-names/#xmlReserved


Hope this helped.

XML 1.0:

"[Definition: A Name is a token beginning with a letter or one of a few
punctuation characters, and continuing with letters, digits, hyphens,
underscores, colons, or full stops, together known as name characters.]
Names beginning with the string "xml", or any string which would match
(('X'|'x') ('M'|'m') ('L'|'l')), are reserved for standardization in this or
future versions of this specification."

Hi Julian,

Thanks for the correction.

However, as the xml spec was written before the xml-namespace spec, I guess
that the latter overrides the former, providing a more convinient way to
achieve exactly the same.

Also, from practical point of view I tried to procesa this xml document
"<xml/>" : there was not a single error message from any of the parsers of
the 10 XSLT processors I'm using (MSXML3/4, .Net xslTransform, XalanJ 2.4.1,
XalanC 1.5, Saxon 6.5.2, Saxon 7, JD, xsltProc, 4xslt).

On the other side, this xml document:

<t xmlns:xml="ttt"/>

raises an error.

And the question was "what is illegal".

Therefore, I believe that my reply was really precise and of practical
value.


=====
Cheers,

Dimitre Novatchev.
http://fxsl.sourceforge.net/ -- the home of FXSL

 

[Richard Tobin]

However, as the xml spec was written before the xml-namespace spec, I guess
that the latter overrides the former, providing a more convinient way to
achieve exactly the same.

The XML spec reserved names beginning with "xml". The Namespaces spec
used some of those reserved names. The rest are still reserved, but I
think it's unlikely that any will be used because (as you say) new
extensions will probably use the namespaces mechanism.

Also, from practical point of view I tried to procesa this xml document
"<xml/>" : there was not a single error message from any of the parsers of
the 10 XSLT processors I'm using (MSXML3/4, .Net xslTransform, XalanJ 2.4.1,
XalanC 1.5, Saxon 6.5.2, Saxon 7, JD, xsltProc, 4xslt).

Many extensions can be provided as layers after parsing, so it
wouldn't be much use if parsers rejected documents because of reserved
names. Namespaces are a case in point: you can implement namespaces
on top of a vanilla XML 1.0 parser, but you wouldn't be able to do
that if the parser had already rejected your xmlns: attributes.

More recent specs tend to be more explicit about what "reserved" means.
For example, the Namespaces 1.1 CR draft says:

All other prefixes beginning with the three-letter sequence x, m, l,
in any case combination, are reserved. This means that:

users should not use them except as defined by later specifications

processors must not treat them as fatal errors.

-- Richard

 

[Dimitre Novatchev]

Thank you, Richard!

Dimitre.

The XML spec reserved names beginning with "xml". The Namespaces spec
used some of those reserved names. The rest are still reserved, but I
think it's unlikely that any will be used because (as you say) new
extensions will probably use the namespaces mechanism.


Many extensions can be provided as layers after parsing, so it
wouldn't be much use if parsers rejected documents because of reserved
names. Namespaces are a case in point: you can implement namespaces
on top of a vanilla XML 1.0 parser, but you wouldn't be able to do
that if the parser had already rejected your xmlns: attributes.

More recent specs tend to be more explicit about what "reserved" means.
For example, the Namespaces 1.1 CR draft says:

All other prefixes beginning with the three-letter sequence x, m, l,
in any case combination, are reserved. This means that:

users should not use them except as defined by later specifications

processors must not treat them as fatal errors.

-- Richard