safe range of characters in a <A name="">

[Dan Jacobson]

Using <A name="x_y-z"></A>, I even get nervous about the _ and -.
w3-recs/RECS/html4/struct/links.html seems to say all of ascii is cool
and beyond. Anyway, just what is the safe range for characters in a
name="" ? I don't plan to go beyond usual Unix filename chars.

[Alan J. Flavell]

On Fri, Jul 25, Dan Jacobson inscribed on the eternal scroll:

Using <A name="x_y-z"></A>, I even get nervous about the _ and -.
w3-recs/RECS/html4/struct/links.html seems to say all of ascii is cool
and beyond.
Well, in the HTML4.01 spec, name is declared as CDATA, whereas id is
declared as something else (see below).

But it then says of "name":

Note that this attribute shares the same name space as the id
attribute.

Strange that they share the same space but are formed according to
very different syntax rules, what?

By the way, don't confuse the attributes called "name" and "id" with
the declared types "name" and "id". The attribute called "name" is,
as I said, declared as "cdata", whereas the attribute called "id" is
declared as "name".... erm... Hangonabit, the SGML tutorial at
http://www.w3.org/TR/html401/intro/s...html#h-3.3.3.4 says that
the id attribute is declared of type id, and so does the actual DTD,
but the text of the specification asserts at
http://www.w3.org/TR/html401/struct/global.html#adef-id that it's
declared as type "name". I hadn't noticed that discrepancy before.

Is there an SGML doctor in the house?
Anyway, just what is the safe range for characters in a
name="" ? I don't plan to go beyond usual Unix filename chars.

Ultimate safety would be to stick to the SGML name token rules which
were incorporated into RFC1866/HTML2.0:

3.2.3. Names

A name consists of a letter followed by letters, digits, periods, or
hyphens.

So on that basis, scrub the underscores.

This has not been a formal requirement since HTML3.2, but it seems to
do no harm to stick to it if you feel that you can. However, you'll
see underscores used e.g in an example in the HTML4.01 specification,
and HTML4.01 also includes colons as eligible characters; so... it's
up to you.

[Terje Bless]

In article <Xn*****************************@193.229.0.31>,
Jukka K. Korpela <jk******@cs.tut.fi> wrote:

[...] but when, oh when, will the World Wide Web Consortium invent the
idea that on the Web, unlike in print media, you can actually change a
document behind a URL and everyone who accesses it, modulo cache
issues, will get the updated document? Do they really expect people to
dig through the Errata, perhaps every one of us editing our local
copies of the specifications according to them? Or are the errors
recorded just to please some unknown deity?

To avoid the W3C's Recommendations becoming a "moving target",
documents in TR space are frozen. The Errata documents are collections
of known erratum -- acknowledged issues -- that the relevant WG MUST
address and MAY choose to address by publishing a revised
Recommendation. HTML 4.01 was one such. I'm hoping for a HTML 4.02...

Did you not know that or did I not understand your complaint? :-)

--
T.E.R.J.E. - Technician Engineered for Repair and Justified Exploration
B.L.E.S.S. - Biomechanical Lifeform Engineered for Scientific Sabotage

[Terje Bless]

In article <Pi*******************************@lxplus001.cern. ch>,
Alan J. Flavell <fl*****@mail.cern.ch> wrote:

Strange that they share the same space but are formed according to
very different syntax rules, what?
BTW, according to ISO-8879:1986, they actually cannot have the same
definition as

[[[
Within a document type definition, the same /attribute name/
should be used for all attributes having a /declared value/
of "ID".
]]]

thus @name and @id cannot both be of type "ID".

Ultimate safety would be to stick to the SGML name token rules which
were incorporated into RFC1866/HTML2.0:

3.2.3. Names

A name consists of a letter followed by letters, digits, periods, or
hyphens.

So on that basis, scrub the underscores.

This has not been a formal requirement since HTML3.2, but it seems to
do no harm to stick to it if you feel that you can. However, you'll
see underscores used e.g in an example in the HTML4.01 specification,
and HTML4.01 also includes colons as eligible characters; so... it's
up to you.

Actually, the SGML Declaration governs this by specifying the LCNMSTRT,
UCNMSTRT, LCNMCHAR, and UCNMCHAR. In HTML 4.01, the former two are
specified as "" (the empty set) and the latter two as ".-_:".

The Reference Concrete Syntax and SGML together defines a "name
character" as a "name start character" followed by "Digits" and
[LC|UC]NMCHAR. A "name start character" is "LC Letter", "UC Letter", or
any char assigned to the roles LCNMSTRT and UCNMSTRT.

In sum, the legal characters are: a-z A-Z 0-9 . - _ :

[ Source: Goldfarb's "The SGML Handbook". ]
That doesn't quite jive with my existing assumptions (or yours,
apparently), but it's the only conclusion I can draw from the source
material. Can anyone shed some light on the discrepancy?

--
T.E.R.J.E. - Technician Engineered for Repair and Justified Exploration
B.L.E.S.S. - Biomechanical Lifeform Engineered for Scientific Sabotage

[Alan J. Flavell]

On Fri, Jul 25, Jukka K. Korpela inscribed on the eternal scroll:

"Alan J. Flavell" <fl*****@mail.cern.ch> wrote:

But then we'd have to put a date and time stamp on any reference to
the authoritative document, and someone would need to maintain an
archive of the changes,
I thought such things were in the basic ideas of the Web.

That's ideal for tutorials, FAQs etc, but not for authoritative
specifications. I interpret a published specification as in effect a
contract: once it's out there and people are relying on it, it would
be fraud to quietly change its content. Updates should be issued only
in a controlled fashion and with an accompanying version reference,
IMHO (but I fear I'm just repeating myself...)
If records of changes are needed, they should be created as well.
Yes, indeed. Now we're saying much the same thing as each other, I
reckon.

Your argument is at least plausible for simple typos, but IMHO a
document which asserts itself to be the authoritative definition of
something cannot be quietly amended as if nothing had happened.

We surely agree on that.

Good...
Neither should such a document, when published on the Web, contain
errors that have been reported and acknowledged as errors
The problem with CSS2 is that the working group seem to have decided
"well, we said precisely A, but we _really_ meant B, so we'll change A
to B and pretend that's what had been meant all along". Foul!

There are other ways of handling that, as I'm sure you know.

No, I don't. I don't know how to publish a version of HTML 4.01 with
errata fixed incorporated, in a manner that raises no copyright issues

Fair comment. But I wasn't meaning "other ways" which could be
applied by third parties, I was meaning "other ways" which might be
considered by the W3C.

but the TR was formally approved by the
W3C (whatever that might really mean), whereas the so-called
"Errata" seem to be a somewhat wooly product from a working group.

So we don't really know what the content of the specification is, do
we? The specification makes a reference to the Errata.

That was inserted into the cover page post facto. That doesn't make
it part of the 1998 CSS2 TR.
Is it a normative reference or not?
The specification itself says that it is not! But I'm sure the
working group saw that differently!! They evidently conceive of what
is effectively a "CSS2 du jour" - defined by applying the Errata to
the original TR.
But surely just in the sense of fixing errors, i.e. correcting errors
in the documentation of what was meant at the time of writing the
specification, not introducing any "on second though, it should..."
ideas.

It seems to me that it's not unfair to say that the working group
evidently lacked the self-restraint implied by that plan.

cheers