E [Xerces] Attribute value "1" of type ID must be an NCName when namespaces are enabled.

Discussion:

Manuel Souto Pico

2009-08-13 09:31:10 UTC

Hi all,

This might be more an XML-related issue than XSL-related, but it happens
in a file that I produced with a XSL stylesheet.

Could you help me interpret this error (in the subject)? What could I do
to make the document valid?

Thank you so much and have a nice day!

My (simplified) file is:

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE martif SYSTEM "TBXcoreStructV02.dtd">
<martif xml:lang="en" type="TBX">
<martifHeader>
<fileDesc>
<sourceDesc>
Generated with TMX2TBX.xsl
</sourceDesc>
</fileDesc>
<encodingDesc>

</encodingDesc>
</martifHeader>
<text>
<body>
<termEntry id="1">
<langSet xml:lang="eng-us">
<tig>
<term>About Manage reference material</term>
</tig>
</langSet>
<langSet xml:lang="spa-es">
<tig>
<term>Acerca de la gestión del material de
referencia</term>
</tig>
</langSet>
</termEntry>
</body>
</text>
</martif>
--
Manuel Souto Pico
Terminòleg / Responsable de servei tècnic
***@star-group.net <mailto:***@star-group.net>

*STAR Servicios Lingüísticos*
C. Sardenya, 195-197 (baixos)
E-08013 Barcelona
Tel. +34 932 440 889
Fax: +34 932 471 273
http://www.star-spain.com
http://www.star-group.net <http://www.star-spain.com>

En cumplimiento con lo previsto en los artículos 21 y 22 de la Ley
34/2002, de 11 de julio, de Servicios de la Sociedad de Información y
Comercio Electrónico (LSSI) y las disposiciones de la Ley Orgánica
15/1999, de 13 de diciembre de Protección de Datos de Carácter Personal
(LOPD) le informamos que procederemos al archivo y tratamiento de sus
datos exclusivamente con fines de promoción de los productos y servicios
ofrecidos por STAR Servicios Lingüísticos, S.L. Este mensaje, y en su
caso, cualquier fichero anexo al mismo, puede contener información
confidencial o legalmente protegida, siendo para uso exclusivo del
destinatario. No hay renuncia a la confidencialidad o secreto
profesional por cualquier transmisión defectuosa o errónea, y queda
expresamente prohibida su divulgación, copia o distribución a terceros
sin la autorización expresa de STAR Servicios Lingüísticos, S.L. Si ha
recibido este mensaje por error, se ruega lo notifique a STAR Servicios
Lingüísticos enviando un mensaje al remitente o al correo electrónico
***@star-spain.com y proceda inmediatamente al borrado del mensaje
original y de todas sus copias. Gracias por su colaboración. Si desea
más información sobre sus derechos en lo que respecta al tratamiento de
sus datos de carácter personal, visite
http://www.star-spain.com/es/inicio/lopd.php

--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-***@lists.mulberrytech.com>
--~--

Michael Kay

2009-08-13 11:18:03 UTC

Permalink

The message means exactly what it says. For bizarre historical reasons that
few people remember, XML requires that an attribute value declared as being
of type ID has the same syntax as an XML name - so it cannot start with a
digit.

Regards,

Michael Kay
http://www.saxonica.com/
http://twitter.com/michaelhkay

-----Original Message-----
Sent: 13 August 2009 10:31
Subject: [xsl] E [Xerces] Attribute value "1" of type ID must
be an NCName when namespaces are enabled.
Hi all,
This might be more an XML-related issue than XSL-related, but
it happens in a file that I produced with a XSL stylesheet.
Could you help me interpret this error (in the subject)? What
could I do to make the document valid?
Thank you so much and have a nice day!
<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE martif SYSTEM "TBXcoreStructV02.dtd"> <martif
xml:lang="en" type="TBX">
<martifHeader>
<fileDesc>
<sourceDesc>
Generated with TMX2TBX.xsl
</sourceDesc>
</fileDesc>
<encodingDesc>

</encodingDesc>
</martifHeader>
<text>
<body>
<termEntry id="1">
<langSet xml:lang="eng-us">
<tig>
<term>About Manage reference material</term>
</tig>
</langSet>
<langSet xml:lang="spa-es">
<tig>
<term>Acerca de la gestión del
material de referencia</term>
</tig>
</langSet>
</termEntry>
</body>
</text>
</martif>
--
Manuel Souto Pico
Terminòleg / Responsable de servei tècnic
*STAR Servicios Lingüísticos*
C. Sardenya, 195-197 (baixos)
E-08013 Barcelona
Tel. +34 932 440 889
Fax: +34 932 471 273
http://www.star-spain.com
http://www.star-group.net <http://www.star-spain.com>
En cumplimiento con lo previsto en los artículos 21 y 22 de
la Ley 34/2002, de 11 de julio, de Servicios de la Sociedad
de Información y Comercio Electrónico (LSSI) y las
disposiciones de la Ley Orgánica 15/1999, de 13 de diciembre
de Protección de Datos de Carácter Personal
(LOPD) le informamos que procederemos al archivo y
tratamiento de sus datos exclusivamente con fines de
promoción de los productos y servicios ofrecidos por STAR
Servicios Lingüísticos, S.L. Este mensaje, y en su caso,
cualquier fichero anexo al mismo, puede contener información
confidencial o legalmente protegida, siendo para uso
exclusivo del destinatario. No hay renuncia a la
confidencialidad o secreto profesional por cualquier
transmisión defectuosa o errónea, y queda expresamente
prohibida su divulgación, copia o distribución a terceros sin
la autorización expresa de STAR Servicios Lingüísticos, S.L.
Si ha recibido este mensaje por error, se ruega lo notifique
a STAR Servicios Lingüísticos enviando un mensaje al
proceda inmediatamente al borrado del mensaje original y de
todas sus copias. Gracias por su colaboración. Si desea más
información sobre sus derechos en lo que respecta al
tratamiento de sus datos de carácter personal, visite
http://www.star-spain.com/es/inicio/lopd.php
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
--~--

--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-***@lists.mulberrytech.com>
--~--

Michael Ludwig

2009-08-13 13:00:54 UTC

Permalink

Post by Michael Kay
The message means exactly what it says. For bizarre historical reasons
that few people remember, XML requires that an attribute value
declared as being of type ID has the same syntax as an XML name - so
it cannot start with a digit.

Bizarre historical reasons is exactly what I'm interested in! Quite
often, they don't find entrance in the documentation, but live on only
in anecdotal camp fire talk. I'd be glad if any of the few people who
remember could point out what these reasons are.

At first, I found it odd that a simple integer value did not qualify for
ID-ness as per the XML spec. Then, becoming aware of the fact that there
is only one ID table per document, I realized it is a useful convention
to *prefix* ID values according to the type of object they refer to, the
prefix stepping in as a substitute for the table, so that there can be
an object HH123 but also BB123. This is when the restriction mentioned
above stopped bothering me.

--
Michael Ludwig

--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-***@lists.mulberrytech.com>
--~--

Eliot Kimber

2009-08-13 13:33:07 UTC

Permalink

Post by Michael Kay
The message means exactly what it says. For bizarre historical reasons that
few people remember, XML requires that an attribute value declared as being
of type ID has the same syntax as an XML name - so it cannot start with a
digit.

Looking at _The SGML Handbook_, I'm not finding a specific discussion of why
ID attributes are names other than a simple statement that IDs are names,
semantically.

I don't remember ever discussing this aspect of SGML design with Charles
although I can imagine his thinking was that IDs are names and therefore
should conform to name lexical rules. I also suspect that Charles'
assumption, or in fact desire, was that element IDs be human-meaningful
names, rather than opaque identifiers used only by processors (e.g.,
pointers and addresses). Thus disallowing values consisting only of digits
would encourage the use of meaningful ID values. Maybe.

Cheers,

Eliot
----
Eliot Kimber | Senior Solutions Architect | Really Strategies, Inc.
email: ***@reallysi.com <mailto:***@reallysi.com>
office: 610.631.6770 | cell: 512.554.9368
2570 Boulevard of the Generals | Suite 213 | Audubon, PA 19403
www.reallysi.com <http://www.reallysi.com> | http://blog.reallysi.com
<http://blog.reallysi.com> | www.rsuitecms.com <http://www.rsuitecms.com>

--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-***@lists.mulberrytech.com>
--~--

Wendell Piez

2009-08-17 18:02:25 UTC

Permalink

Hi,

Post by Eliot Kimber

Post by Michael Kay
The message means exactly what it says. For bizarre historical reasons that
few people remember, XML requires that an attribute value declared as being
of type ID has the same syntax as an XML name - so it cannot start with a
digit.

The campfire talk I heard was that the restriction that names not
start with numbers goes back to IBM naming rules for files in some archaic OS.

But my informant could elucidate neither (a) why a naming rule for
files should be applied to elements in SGML, nor (b) why IBM even had
this naming rules for files.

Does this ring a bell, Eliot? (That would be character U+0007, also
disallowed in names for perhaps more understandable reasons.)

BTW, this thread was always off topic.

Cheers,
Wendell

======================================================================
Wendell Piez mailto:***@mulberrytech.com
Mulberry Technologies, Inc. http://www.mulberrytech.com
17 West Jefferson Street Direct Phone: 301/315-9635
Suite 207 Phone: 301/315-9631
Rockville, MD 20850 Fax: 301/315-8285
----------------------------------------------------------------------
Mulberry Technologies: A Consultancy Specializing in SGML and XML
======================================================================

--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-***@lists.mulberrytech.com>
--~--

Michael Kay

2009-08-17 18:15:33 UTC

Permalink

Post by Wendell Piez
But my informant could elucidate neither (a) why a naming
rule for files should be applied to elements in SGML, nor (b)
why IBM even had this naming rules for files.

If it's related to IBM file names (wash my mouth, I mean dataset names), I
would have expected to see the length of an ID restricted to 8 characters!

I seem to recall hearing some other theory about non-name IDs becoming
ambiguous if you adopted one of SGML's many ways of abbreviating tags - but
that's only a vague memory.

Regards,

Michael Kay
http://www.saxonica.com/
http://twitter.com/michaelhkay

--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-***@lists.mulberrytech.com>
--~--

Wendell Piez

2009-08-17 19:17:09 UTC

Permalink

Mike,

Post by Michael Kay

Post by Wendell Piez
But my informant could elucidate neither (a) why a naming
rule for files should be applied to elements in SGML, nor (b)
why IBM even had this naming rules for files.

If it's related to IBM file names (wash my mouth, I mean dataset names), I
would have expected to see the length of an ID restricted to 8 characters!

This could be done in the SGML declaration, and commonly was.

"Dataset names", ah.

Cheers,
Wendell

======================================================================
Wendell Piez mailto:***@mulberrytech.com
Mulberry Technologies, Inc. http://www.mulberrytech.com
17 West Jefferson Street Direct Phone: 301/315-9635
Suite 207 Phone: 301/315-9631
Rockville, MD 20850 Fax: 301/315-8285
----------------------------------------------------------------------
Mulberry Technologies: A Consultancy Specializing in SGML and XML
======================================================================

--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-***@lists.mulberrytech.com>
--~--

G. Ken Holman

2009-08-13 16:48:41 UTC

Permalink

Post by Manuel Souto Pico
This might be more an XML-related issue than XSL-related, but it
happens in a file that I produced with a XSL stylesheet.
Could you help me interpret this error (in the subject)? What could
I do to make the document valid?

Make the attribute value a name instead of a token leading with a digit.

Note that "when namespaces are enabled" is misleading because even
without namespaces enabled attributes declared of type ID must have
values that are names and the string you have used is not a name
(though it is an NMTOKEN).

Post by Manuel Souto Pico
<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE martif SYSTEM "TBXcoreStructV02.dtd">

You do not show us the DTD, but based on the error message I'm
assuming it has a declaration along the lines of:

<!ATTLIST termEntry id ID #IMPLIED>

... which means its values must be valid XML names per
file:///Z:/data/docs/w3c/Architecture/xml/REC-xml-20081126.htm#sec-attribute-types
that states the validity constraint that values of type ID must match
the Name production.

Post by Manuel Souto Pico
<termEntry id="1">

The string "1" is not a valid name.

I hope this helps.

. . . . . . . . . . Ken

--
Interested in these classes? http://www.CraneSoftwrights.com/s/i/
Crane Softwrights Ltd. http://www.CraneSoftwrights.com/s/
Training tools: Comprehensive interactive XSLT/XPath 1.0/2.0 video
Video lesson:

Video overview:

G. Ken Holman mailto:***@CraneSoftwrights.com
Male Cancer Awareness Nov'07 http://www.CraneSoftwrights.com/s/bc
Legal business disclaimers: http://www.CraneSoftwrights.com/legal

--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-***@lists.mulberrytech.com>
--~--

G. Ken Holman

2009-08-13 19:41:26 UTC

Permalink

Forgive me, I inadvertently posted a local link, here is the remote link:

http://www.w3.org/TR/2008/REC-xml-20081126/#sec-attribute-types

. . . . . . . . . Ken

Post by G. Ken Holman

Make the attribute value a name instead of a token leading with a digit.
Note that "when namespaces are enabled" is misleading because even
without namespaces enabled attributes declared of type ID must have
values that are names and the string you have used is not a name
(though it is an NMTOKEN).

You do not show us the DTD, but based on the error message I'm
<!ATTLIST termEntry id ID #IMPLIED>
... which means its values must be valid XML names per
file:///Z:/data/docs/w3c/Architecture/xml/REC-xml-20081126.htm#sec-attribute-types
that states the validity constraint that values of type ID must
match the Name production.

Post by Manuel Souto Pico
<termEntry id="1">

The string "1" is not a valid name.
I hope this helps.
. . . . . . . . . . Ken

--
Interested in these classes? http://www.CraneSoftwrights.com/s/i/
Crane Softwrights Ltd. http://www.CraneSoftwrights.com/s/
Training tools: Comprehensive interactive XSLT/XPath 1.0/2.0 video
Video lesson: http://youtu.be/PrNjJCh7Ppg
Video overview: http://youtu.be/VTiodiij6gE
G. Ken Holman mailto:***@CraneSoftwrights.com
Male Cancer Awareness Nov'07 http://www.CraneSoftwrights.com/s/bc
Legal business disclaimers: http://www.CraneSoftwrights.com/legal

--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-***@lists.mulberrytech.com>
--~--