469,268 Members | 942 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,268 developers. It's quick & easy.

DTDs, www & validation

I've been wandering around the results of numerous googles for several
hours without reaching a conclusive solution, so I'm dipping a tentative
toe back in ciwah...

I've been persuaded here in the past that serving xhtml is a bad thing (tm).

I want the extra constraints xhtml imposes.

It has been suggested before to create a DTD which requires these &
includes all the requirements of HTML 4.01 & validate against that.

I've downloaded such a document from
http://www.spartanicus.utvinternet.i...1-stricter.dtd which I'm
sure looks familiar to all the regulars here.

My questions are pretty simple to state:

How do I make use of this to achieve the above?

I know I can declare <!DOCTYPE HTML SYSTEM
"http://www.spartanicus.utvinternet.ie/html401-stricter.dtd">
(though I'd first either enquire as to whether I should use this url or
duplicate the file on my own server).

However I'm concerned as to whether some browsers will do something
undesirable in their interpretation of my pages when they see this,
rather than a standard public declaration.

Also, http://www.spartanicus.utvinternet.ie/no-xhtml.htm which links to
the above DTD, declares itself as HTML 4.01.

This leads me to wonder, am I supposed to use the !DOCTYPE HTML SYSTEM
form only for development validation & then replace this with a !DOCTYPE
HTML PUBLIC referring to HTML 4.01 prior to the site going live?

However, if that is what one should do, why not just declare an XHTML
1.0 doctype while developing & then replace this with the html 4.01 type
prior to going live to achieve an equivalent effect?

Is there an ideal solution?

Along the way, which resources do the readers here use for validation?
Software installed locally & if so, what, or the online services of w3c
or wdg?

Lastly, for a current project I'm forced to use DreamweaverMX2004; can
it be persuaded to validate against a custom dtd?

Perhaps there's a different & better solution to this whole problem.

--
Michael
m r o z a t u k g a t e w a y d o t n e t
Jul 23 '05
81 4347
On Mon, 13 Dec 2004 03:08:47 GMT, "Arjun Ray" <ar**@nmds.com.invalid>
wrote:
On Sun, 12 Dec 2004 21:36:15 -0500, Neal wrote:
Arjun:

The why of it is an open secret.


I like secrets. Tell me...


(1) To support Doctype Sniffing ("version information")
(2) Keeping The Web Safe For Netploder


Doctype sniffing was introduced in 2000. Section 7.2 of HTML 4.01 is
identical in wording to Section 7.2 of HTML 4.0 from 1997. Was doctype
sniffing predicted in 1997?

Steve

Jul 23 '05 #51
On Sun, 12 Dec 2004, Neal wrote:
(1) To support Doctype Sniffing ("version information")
(2) Keeping The Web Safe For Netploder


So, using the pecified format of the doctype is ultimately a wise
thing to do.


Incrementally, perhaps. But "ultimately"?

Jul 23 '05 #52
On Mon, 13 Dec 2004 08:32:48 +0000, Steve Pugh wrote:
Doctype sniffing was introduced in 2000.
That's when the term was coined, true, to describe a browser "feature".
In that sense my usage is an anachronism.
Was doctype sniffing predicted in 1997?


Not predicted. Invited.

(That isn't to say that what the authors had in mind was what the browsers
subsequently implemented. But the basic notion - of user agents modifying
treatment according to "version information" goes back to before RFC 1866.)

Jul 23 '05 #53
On Mon, 13 Dec 2004 11:22:11 GMT, "Arjun Ray" <ar**@nmds.com.invalid>
wrote:
On Mon, 13 Dec 2004 08:32:48 +0000, Steve Pugh wrote:
Doctype sniffing was introduced in 2000.


That's when the term was coined, true, to describe a browser "feature".
In that sense my usage is an anachronism.


Are there any examples of doctype sniffing before Mac IE5?
Was doctype sniffing predicted in 1997?


Not predicted. Invited.

(That isn't to say that what the authors had in mind was what the browsers
subsequently implemented. But the basic notion - of user agents modifying
treatment according to "version information" goes back to before RFC 1866.)


I can understand UAs treating markup different depending on the
doctype specified when the doctype refers to different specifications.
That's all well and good.

The different doctypes in RFC 1866 reference different DTDs, the same
way that the HTML 4 has different DTDs. But that's not what we're
talking about.

But the particular case here is treating the markup different
depending on which one of two equivalent forms of the doctype
referencing the same specification is used.

The doctype <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"> isn't in
the list from which authors must choose in HTML 4. So was the
intention that if an author used such a doctype that it would be
treated as HTML 4 by SGML tools but that non-SGML UAs could treat it
as something other than HTML 4?

Steve

Jul 23 '05 #54
On Mon, 13 Dec 2004 12:11:45 +0000, Steve Pugh wrote:
Are there any examples of doctype sniffing before Mac IE5?
Offhand, I don't remember which wowser was first. Mac IE5 may have been the
first out of the gate. I only recall extensive discussion on the mozilla
lists. It was all the rage for a while.
I can understand UAs treating markup different depending on the
doctype specified when the doctype refers to different specifications.
That's the basic problem. In SGML, a doctype declaration does *not* carry
"version information" of any kind. AAMOF, a doctype declaration does not
*refer* at all. Despite the name, the construct is not a "declaration of
type" in the sense of "I am this and none other".
That's all well and good.
No, it isn't.
The different doctypes in RFC 1866 reference different DTDs, the same
way that the HTML 4 has different DTDs.
No. The different document type declaration subsets are formally named
(for locative purposes) by FPIs, not by doctype declarations. FPIs are
not a mandatory component of doctype declarations.
The doctype <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"> isn't in
the list from which authors must choose in HTML 4. So was the
intention that if an author used such a doctype that it would be
treated as HTML 4 by SGML tools but that non-SGML UAs could treat it
as something other than HTML 4?


I have no idea. The authors had this bug in their heads that doctype
declarations are used in SGML to "declare" version information. They were
also laboring to maintain a veneer of SGML legality, and to that extent,
if pre-WebSGML.TC SGML demanded doctype declarations in SGML documents,
they felt compelled to demand them too. Going through the motions and all
that. (HTML 4.01 was post Barcelona, but it's highly unlikely anyone at
the W3C bothered to read the TC.)

The basic practical problem with demanding doctype declarations was that
Tag Soup parsing would barf on any form that "didn't look like a tag". To
keep the web safe for the Tag Soup parsers they had ceased to fear and
learned to love, it therefore became "necessary" to demand that doctype
declarations, that they thought had to be there anyway, appear only in
forms suitable for swallowing silently. "Interoperability" and all that.

The bit about a URI in a SYSTEM identifier tagging along for the ride is
another long story, but there the authors are relatively blameless. They
were following the received wisdom of the time that SYSTEM identifiers
were the proper place for URIs.

To answer your question specifically, the idea that HTML would be treated
by SGML tools has always been a choice delusion of HTML specs writers. No
SGML system worth the name bothers. Or has bothered, since about 1993.

Jul 23 '05 #55
Arjun Ray wrote:
On Mon, 13 Dec 2004 12:11:45 +0000, Steve Pugh wrote:

Are there any examples of doctype sniffing before Mac IE5?

Offhand, I don't remember which wowser was first. Mac IE5 may have been the
first out of the gate. I only recall extensive discussion on the mozilla
lists. It was all the rage for a while.


Yes, IIRC Mac IE5 was first and Mozilla followed suit. Then came IE6,
and after a while Opera jumped on the bandwagon too. I haven't followed
developments since then, but I read that Safari and Konqueror are also
doing it now. Poor misguided souls.
Matthias

Jul 23 '05 #56
On Mon, 13 Dec 2004 14:17:20 +0100, Matthias Gutfeldt
<sa************@gmx.net> wrote:
Arjun Ray wrote:
On Mon, 13 Dec 2004 12:11:45 +0000, Steve Pugh wrote:
Are there any examples of doctype sniffing before Mac IE5?

Offhand, I don't remember which wowser was first. Mac IE5 may have
been the
first out of the gate. I only recall extensive discussion on the
mozilla lists. It was all the rage for a while.


Yes, IIRC Mac IE5 was first and Mozilla followed suit. Then came IE6,
and after a while Opera jumped on the bandwagon too. I haven't followed
developments since then, but I read that Safari and Konqueror are also
doing it now. Poor misguided souls.


Only the market leader can get away with substantially changing the way it
treats tagsoup and get away with it without a system like Doctype
switching. It is a crazy concept once you understand what happens, but
only the market leader could force the adaption of a proper alternative
(such as using different mime types). IMHO and all that...

--
Rijk van Geijtenbeek

The Web is a procrastination apparatus:
It can absorb as much time as is required to ensure that you
won't get any real work done. - J.Nielsen

Jul 23 '05 #57
On Mon, 13 Dec 2004 15:24:05 +0100, "Rijk van Geijtenbeek"
<ri**@operaremovethiz.com> wrote:
Only the market leader can get away with substantially changing the way it
treats tagsoup and get away with it without a system like Doctype
switching.


I don't agree the market leader could achieve this, people would
simply refuse to upgrade and would complain like mad, and then
seriously consider using other browsers.

Other user agents without an installed base have a much better chance
of changing things.

Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/

Jul 23 '05 #58
Rijk van Geijtenbeek wrote:
On Mon, 13 Dec 2004 14:17:20 +0100, Matthias Gutfeldt
<sa************@gmx.net> wrote:
Arjun Ray wrote:
On Mon, 13 Dec 2004 12:11:45 +0000, Steve Pugh wrote:

Are there any examples of doctype sniffing before Mac IE5?

Offhand, I don't remember which wowser was first. Mac IE5 may
have been the
first out of the gate. I only recall extensive discussion on the
mozilla lists. It was all the rage for a while.

Yes, IIRC Mac IE5 was first and Mozilla followed suit. Then came IE6,
and after a while Opera jumped on the bandwagon too. I haven't
followed developments since then, but I read that Safari and
Konqueror are also doing it now. Poor misguided souls.

Only the market leader can get away with substantially changing the way
it treats tagsoup and get away with it without a system like Doctype
switching. It is a crazy concept once you understand what happens, but
only the market leader could force the adaption of a proper alternative
(such as using different mime types). IMHO and all that...


The way I see it, only the market leader could get away with a
hare-brained idea like Doctype Switching. But IIRC we already had this
discussion when they came up with the scheme.
Matthias

Jul 23 '05 #59
On Mon, 13 Dec 2004 15:54:37 +0100, Matthias Gutfeldt
<sa************@gmx.net> wrote:
Rijk van Geijtenbeek wrote:
Only the market leader can get away with substantially changing the way
it treats tagsoup and get away with it without a system like Doctype
switching. It is a crazy concept once you understand what happens, but
only the market leader could force the adaption of a proper
alternative (such as using different mime types). IMHO and all that...

The way I see it, only the market leader could get away with a
hare-brained idea like Doctype Switching. But IIRC we already had this
discussion when they came up with the scheme.


Huh? MacIE5 and Mozilla .9 being market leaders when they started doing
Doctype switching? And it was discussed to death then, and they still got
away with it, because as non market-leaders it mostly worked, never mind
that it didn't really make sense conceptually. Expecting users to simply
not care that tagsoup and broken CSS is handled differently from MSIE
doesn't work. Opera 6 introduced support for pixelless units in CSS,
because it had to. In Opera 7 this could be limited to the then newly
introduced Quirksmode.

--
Rijk van Geijtenbeek

The Web is a procrastination apparatus:
It can absorb as much time as is required to ensure that you
won't get any real work done. - J.Nielsen

Jul 23 '05 #60
On Mon, 13 Dec 2004, Jim Ley wrote:
I don't agree the market leader could achieve this, people would
simply refuse to upgrade and would complain like mad, and then
seriously consider using other browsers.


People already do "complain like mad" about the software that comes
from the "market leader", yet somehow the vast majority of them do
nothing effective about it: they just continue to use software from
the same source.

I was told, any number of times, that they could never do anything
substantial about their many security vulnerabilities, as it would
make their software unusable. Well: they did XP SP2. It's not a
complete answer, and in some respects it replaces known problems with
as-yet-unknown problems. But it -does- make a considerable difference
compared with what was before. So I'd say they /can/ do it, when they
decide they want to.

"hence or otherwise deduce", as they say around here.
Jul 23 '05 #61
In article <pa****************************@nmds.com.invalid >,
"Arjun Ray" <ar**@nmds.com.invalid> wrote:
AAMOF, a doctype declaration does not *refer* at all.


It has been long ago established that a document type declaration does
not declare the type of the document but is it also the case that an
external entity reference does not refer to an external entity?

--
Henri Sivonen
hs******@iki.fi
http://iki.fi/hsivonen/
Mozilla Web Author FAQ: http://mozilla.org/docs/web-developer/faq.html
Jul 23 '05 #62
On Mon, 13 Dec 2004 21:27:06 +0200, Henri Sivonen wrote:
is it also the case that an external entity reference does not
refer to an external entity?


That's correct. An 'external entity reference' indicates the incorporation
(i.e. transclusion of the content of) an entity stored elsewhere, directly
in the document at the point where the reference occurs.

Entity references are a text replacement mechanism (substitute the content
for the marker operating as a placeholder).

Jul 23 '05 #63
On Mon, 13 Dec 2004 16:27:16 +0000, Alan J. Flavell wrote:
People already do "complain like mad" about the software that comes
from the "market leader", yet somehow the vast majority of them do
nothing effective about it: they just continue to use software from
the same source.


And, as it happens, "learn" from that same source. If something "works",
they don't bother to determine why - and the more aggressively clueless
conclude that every accident must be a feature - but if something doesn't
"work", then they do find out what to avoid.

How many people miss the closing quote on attribute values today?

("Complain like mad" doesn't begin to describe the reaction to that
particular change in Netscape 2.0.)

Jul 23 '05 #64
"Arjun Ray" <ar**@nmds.com.invalid> writes:
Consider the benefits of

<!DOCTYPE html SYSTEM>
Even I can understand that, works fine, since quite some time.
or even just

<!DOCTYPE html>

(Catalogs, anyone?)


Of course. But for the latter, I wouldn't know how.
--
| ) Più Cabernet,
-( meno Internet.
| ) http://bednarz.nl/
Jul 23 '05 #65
On Sat, 11 Dec 2004 15:00:22 -0500, "C A Upsdell"
<cupsdell0311XXX@-@-@XXXrogers.com> wrote:
> There are _no_ extra constraints imposed by XHTML.


Not correct. E.g., xHTML requires end tags where in HTML they are optional.


No, XHTML does not require this. _XML_ requires this.

This is the only additional constraint that XHTML _implies_ over HTML,
even though it's not XHTML itself that is _imposing_ it.

The original poster appears to be looking for some way of "using XHTML
that is not XHTML". Now this could mean they're either after the
XML-implied constraint, or they think there's some DTD level
constraint coming from XHTML. Now in neither case does their question
make sense.

If what they're after is the constraint (which has to mean XML,
because nothing else has changed) then they could easily invent any
"HTML in XML" protocol they like. But this is ridiculous, because
XHTML is already doing this, doing it well, and doing it with the
minimal additional constraint possible. You can certainly do this,
but there's no advantage (and major disadvantages) to doing this
instead of XHTML.

If they're after some DTD-level constraint of XHTML compare to HTML,
other than the implied XML, then there just isn't any.

Jul 23 '05 #66
On Sun, 12 Dec 2004 22:39:08 GMT, "Arjun Ray" <ar**@nmds.com.invalid>
wrote:

Hi Arjun ! Good to see you posting agan 8-)

Jul 23 '05 #67
On Tue, 14 Dec 2004 23:53:35 +0100, Eric B. Bednarz
<be*****@fahr-zur-hoelle.org> wrote:
"Arjun Ray" <ar**@nmds.com.invalid> writes:
Consider the benefits of
<!DOCTYPE html SYSTEM>
Even I can understand that, works fine, since quite some time.
Yep, a decent catalog file "at home" solves that part.
<!DOCTYPE html>
(Catalogs, anyone?)

Of course. But for the latter, I wouldn't know how.


Same thing basically, but maybe Arjun had something else in mind?

=====

What puzzles me a bit is how far can a "Catalog" be stretched?

I mean; Do I have to have my own on my own physical system?

Or was it ever intended that a generic Catalog of sorts was meant to be
available on a global scale (and I mean global as to the whole world) at
which point it has to be provided over the one and only global network
we have today.

Very unreliable, if you ask me :-)

(scaling problem, SGML narrow - some "yet undefined else" wider, maybe)

=====

As of today I only know of "Peter Flynn" and "Liam Quinn" to have been
able to register "PUBLIC TEXT" in their own names (the +// thingy), and
as per ISO standard requirements.

Would their registrations have any inclination at all on a possible
existence of a "usable Catalog" on Internet?

--
Rex
Jul 23 '05 #68
On Tue, 14 Dec 2004 23:53:35 +0100, Eric B. Bednarz wrote:
"Arjun Ray" <ar**@nmds.com.invalid> writes:

<!DOCTYPE html SYSTEM>
<!DOCTYPE html>

(Catalogs, anyone?)


Of course. But for the latter, I wouldn't know how.


The latter should work anywhere the former works, because they key off the
same entry in the catalog :-)

Jul 23 '05 #69
On Wed, 15 Dec 2004 01:57:21 +0100, Jan Roland Eriksson wrote:

I mean; Do I have to have my own [catalog] on my own physical system?
In general, you should. But I think I'm misunderstanding your question.
Or was it ever intended that a generic Catalog of sorts was meant to be
available on a global scale (and I mean global as to the whole world) at
which point it has to be provided over the one and only global network
we have today.
This is a very hard problem. Resolving PUBLIC identifiers (dynamically) is
like resolving URNs. I suppose a system like DNS could be used, but AFAIK
there have been no substantive proposals yet.
Very unreliable, if you ask me :-)
Well, one theoretical advantage of PUBLIC IDs is that, with sufficient
storage space, you need only resolve them once: grab the entity and cache
it.
Would their registrations have any inclination at all on a possible
existence of a "usable Catalog" on Internet?


Interesting thought. What if there were another TLD dedicated to the
namespace of such registered names? Then, one could use DNS to get the
address of a host - say an LDAP server - which could then be queried by a
another protocol designed for catalog queries/updates?


Jul 23 '05 #70
On Wed, 15 Dec 2004 04:46:01 GMT, "Arjun Ray" <ar**@nmds.com.invalid>
wrote:
On Wed, 15 Dec 2004 01:57:21 +0100, Jan Roland Eriksson wrote:
I mean; Do I have to have my own [catalog] on my own physical system?
In general, you should. But I think I'm misunderstanding your question.
Well, I was not very clear on what I was asking either. Let's try again.

I had some old memories about a process that was run by GCA.ORG to the
effect that any one was supposed to be able to get an approved ISO
registration, and an FPI of course, for their PUBLIC TEXT's

As I recall only some 12-15 FPI's ever got registered, several of them
military but with the added twist that PF and LQ had their own private
entries in there.

Side note: W3C was not to be found on that list of registered FPI's :-)

What I never understood was if that ISO registration process also
produced an entry in a www accessible SGML catalog or not, and I still
don't know anything about that idea.

[...]
Would their registrations have any inclination at all on a possible
existence of a "usable Catalog" on Internet?

Interesting thought. What if there were another TLD dedicated to the
namespace of such registered names?
It would not cost much to set one up. Theoretically I could do it on a
financial basis of some $150 a year on the most reliable server system I
know of (Hurricane Electric, same as where css.nu has been from the
start)
Then, one could use DNS to get the address of a host - say an LDAP
server - which could then be queried by a another protocol designed
for catalog queries/updates?


That would be for catalog maintenance, right/wrong? Or maybe I'm not up
to date on what 'LDAP' stands for?

But allow me to stay on the catalog(s) themselves for a while.

What I mean is;

If I have my own private catalog at home that maps FPI's to stored local
resources on my own system.

Would it not be just about the same to provide a www accessible catalog
that maps FPI's to their corresponding URL's?

Basically the only thing needed for this to work, as I see it, is
stability in the form of "cool URL's never change" :-)

Well, provided that some one (e.g. me) was willing to provide the "cool
and non changing TLD" for a catalog system, it might not be ISO approved
(but who cares really, the +// could be handed out any way I think) but
otoh, given a stable hosting system, it may work in practice.

Naturally we don't need to put any limits on the entities that gets
mapped, any one who writes a plain article even, could apply for and be
given an FPI and a URL mapping in a catalog for it, right/wrong?

[what about the attempts of SGML and XML catalogs at oasis? nothing
usable to be had from there?]

--
Rex
Jul 23 '05 #71
"Arjun Ray" <ar**@nmds.com.invalid> writes:
Eric B. Bednarz wrote:

"Arjun Ray" <ar**@nmds.com.invalid> writes:

<!DOCTYPE html SYSTEM>
<!DOCTYPE html>

(Catalogs, anyone?)


Of course. But for the latter, I wouldn't know how.


The latter should work anywhere the former works, because they key off the
same entry in the catalog :-)


Maybe *anywhere* isn't good enough for me, I'm just a jazz musician with
some spare time (pleomasm acknowledged).

DOCTYPE HTML path/to/some.dtd

certainly doesn't do the trick for SP over here. But then, maybe I just
don't grok the big -- or any -- picture.

--
| ) Più Cabernet,
-( meno Internet.
| ) http://bednarz.nl/
Jul 23 '05 #72
On Wed, 15 Dec 2004 22:01:26 +0100, Jan Roland Eriksson wrote:
On Wed, 15 Dec 2004 04:46:01 GMT, "Arjun Ray" <ar**@nmds.com.invalid>
wrote: What I never understood was if that ISO registration process also
produced an entry in a www accessible SGML catalog or not, and I still
don't know anything about that idea.
AFAIK, it doesn't. The GCA is authorized to issue registered identifiers
but I don't think they're obliged to publish them in a www-accessible way.
Interesting thought. What if there were another TLD dedicated to the
namespace of such registered names?


It would not cost much to set one up. Theoretically I could do it on a
financial basis of some $150 a year on the most reliable server system I
know of (Hurricane Electric, same as where css.nu has been from the
start)


Not a domain name, but a top-level domain (like .gov, .edu, .com, etc)
itself, which takes considerably more doing:-) That would provide a
reserved namespace which could then be shoehorned into DNS to get the
resolution process started.
Would it not be just about the same to provide a www accessible catalog
that maps FPI's to their corresponding URL's?
But how does anyone know what the URL is to get such a catalog? At the
least you would need a standardized (naming) convention. The point being,
having encountered a brand new FPI, how would you go about resolving it?
Going to a single ("well-known") place for every conceivable FPI is not
likely to scale - we would need a system to distribute the load, like DNS.
Hence my suggestion of a reserved TLD to "root" the hierarchic structure
of FPIs. For instance, suppose you have a FPI of the form

+//STRING1//DTD STRING2

As a thought experiment, consider the hierarchic analog

STRING2.DTD.STRING1.fpi

and imagine using DNS to look this up, possibly recrusively, for either a
host (which could be queried with another protocol) or even a URL. This
may work if we could have the 'fpi' TLD reserved for such things.
[what about the attempts of SGML and XML catalogs at oasis? nothing
usable to be had from there?]


I'm behind on my RTFM.

Jul 23 '05 #73
On Thu, 16 Dec 2004 01:04:54 +0100, Eric B. Bednarz wrote:
DOCTYPE HTML path/to/some.dtd

certainly doesn't do the trick for SP over here.


Hmm, you're right. Looks like they've fixed a "bug" in SP. A close
reading of the TR shows that this behavior is now correct (though
illogical.) Oh well. Sorry about that.

Jul 23 '05 #74
Been busy missing a deadline...

Spartanicus wrote:
Michael Rozdoba <mr**@nowhere.invalid> wrote:

What are the problems of giving no uri?

None that I'm aware of for the HTML 4.01 *Strict* doctype, although it's
not allowed by the specs.


Yes, I only just discovered it wouldn't validate at
http://validator.w3.org/, so I've put it back.
That just leaves element case sensitivity...

I haven't bothered enforcing that, I didn't see the point since UAs are
not going to care one iota.


Oh I know, but the code's prettier.
Remember that to code using all the extra "strictness" of xhtml does not
need a custom DTD at all, it's purely down to the author. The only
benefit you get from incorporating it into a DTD is validator warnings
if you get it wrong.
I realise that. Maybe I'm just into cyber BDSM & like being dominated by
validators :)
There may be some benefits to doing that for
mandatory closing of elements, but I can't see any point in requiring
case sensitivity.


Mostly just personal curiosity of the can I make it do it variety. BTW
Do you know if my guess was correct?

Restating:

In the .dcl specify SYNTAX NAMING NAMECASE GENERAL as NO, and in the
dtd, specify all element & attribute names in lowercase, wherever they
appear.
--
Michael
m r o z a t u k g a t e w a y d o t n e t
Jul 23 '05 #75
Arjun Ray wrote:
On Sat, 11 Dec 2004 01:14:03 +0000, Spartanicus wrote:

If you use a local validator then for DTDs that use a subset of the public
DTD, (no new elements), you can use the public doctype and override the
location of the DTD locally to a local DTD. (I've elected to omit the uri
from the doctype declaration but this isn't the best way).

What is the best way?

I'm not sure what the OP is looking for here. A magical doctype decaration
that "works" both locally and globally?


At the time: a declaration which browsers & validators recognise as HTML
4.01 strict and a method to tell a validator to ignore that & validate
against a more restrictive doctype, if possible without first needing to
modify the document.

I can now do this with local validation as described above. I came to
this point as I like the nature of XHTML, but am forced to serve HTML
due to lack of browser support.

--
Michael
m r o z a t u k g a t e w a y d o t n e t
Jul 23 '05 #76
Andy Dingley wrote:
On Sat, 11 Dec 2004 15:00:22 -0500, "C A Upsdell"
<cupsdell0311XXX@-@-@XXXrogers.com> wrote:

There are _no_ extra constraints imposed by XHTML.
Not correct. E.g., xHTML requires end tags where in HTML they are optional.

No, XHTML does not require this. _XML_ requires this.

This is the only additional constraint that XHTML _implies_ over HTML,
even though it's not XHTML itself that is _imposing_ it.

The original poster appears to be looking for some way of "using XHTML
that is not XHTML".


I was, but I'm a fool.
Now this could mean they're either after the
XML-implied constraint, or they think there's some DTD level
constraint coming from XHTML. Now in neither case does their question
make sense.
The latter, but I now know a little better.
If what they're after is the constraint (which has to mean XML,
because nothing else has changed) then they could easily invent any
"HTML in XML" protocol they like.
Yes.
But this is ridiculous, because
XHTML is already doing this, doing it well, and doing it with the
minimal additional constraint possible. You can certainly do this,
but there's no advantage (and major disadvantages) to doing this
instead of XHTML.
Quite, I'd be happy with that. However I can't use it, as I can't serve
such pages in a useful way. Instead, I'll settle for HTML with (using
possibly wrong terminology) additional SGML restrictions, such as
attribute quoting & enforcement of lower case) /&/ the ability to
validate against this.
If they're after some DTD-level constraint of XHTML compare to HTML,
other than the implied XML, then there just isn't any.


Understood. However with local validation using an over ridden modified
dtd & sgml declaration, I can achieve the above whilst still validating
as HTML 4.01 strict.

--
Michael
m r o z a t u k g a t e w a y d o t n e t
Jul 23 '05 #77
Michael Rozdoba <mr**@nowhere.invalid> wrote:
What are the problems of giving no uri?


None that I'm aware of for the HTML 4.01 *Strict* doctype, although it's
not allowed by the specs.


Yes, I only just discovered it wouldn't validate at
http://validator.w3.org/, so I've put it back.


You must have made an error, the validator doesn't care if the uri is
omitted on the html 4 strict doctype.
That just leaves element case sensitivity...


Restating:

In the .dcl specify SYNTAX NAMING NAMECASE GENERAL as NO, and in the
dtd, specify all element & attribute names in lowercase, wherever they
appear.


Eric Bednartz or Arjun Ray would probably know.

--
Spartanicus
Jul 23 '05 #78
Spartanicus wrote:
Michael Rozdoba <mr**@nowhere.invalid> wrote:

What are the problems of giving no uri?

None that I'm aware of for the HTML 4.01 *Strict* doctype, although it's
not allowed by the specs.


Yes, I only just discovered it wouldn't validate at
http://validator.w3.org/, so I've put it back.

You must have made an error, the validator doesn't care if the uri is
omitted on the html 4 strict doctype.


Interesting, since the addition of the uri led to it validating as html
4 strict.

I'll double check I'm not making a mistake here <goes off to prove point>

<fails>

Ah, oh. Okay, you're right. In my defence, I did 'discover' this at 4am
this morning & proceeded to fix it there & then. Glad you caught this
before it propagated further through my head, which has little room left
for further erroroneous ideas.
That just leaves element case sensitivity...


Restating:

In the .dcl specify SYNTAX NAMING NAMECASE GENERAL as NO, and in the
dtd, specify all element & attribute names in lowercase, wherever they
appear.

Eric Bednartz or Arjun Ray would probably know.


I shall embrace the likelihood of having another daft conception of mine
exposed :)

--
Michael
m r o z a t u k g a t e w a y d o t n e t
Jul 23 '05 #79
On Thu, 16 Dec 2004 01:02:50 GMT, "Arjun Ray" <ar**@nmds.com.invalid>
wrote:
On Wed, 15 Dec 2004 22:01:26 +0100, Jan Roland Eriksson wrote:
On Wed, 15 Dec 2004 04:46:01 GMT, "Arjun Ray" <ar**@nmds.com.invalid>
wrote:
...What if there were another TLD dedicated to the namespace of
such registered names?
It would not cost much to set one up. Theoretically I could do it...
Not a domain name, but a top-level domain (like .gov, .edu, .com, etc)
itself, which takes considerably more doing:-)
Ah, now I see what you mean.

But it seems to me that we would need a good deal of supporting
arguments from people with real authority to pull that one off.

Only the TLD name would be easy to define, what about .cat (for more
than one reason maybe :-) or maybe .fpi or .reg
That would provide a reserved namespace which could then be
shoehorned into DNS to get the resolution process started.
Yea, that could be made to work.
Would it not be just about the same to provide a www accessible catalog
that maps FPI's to their corresponding URL's?

But how does anyone know what the URL is to get such a catalog?
My simple mind was thinking in terms of "advertising" :)
At the least you would need a standardized (naming) convention.
Well, that part could be worked out for an acceptable solution.
The point being, having encountered a brand new FPI, how would you
go about resolving it? Going to a single ("well-known") place for
every conceivable FPI is not likely to scale - we would need a
system to distribute the load, like DNS.
If FPI reservations[1] and corresponding catalogs on the www where to
become "very popular" I do see what you mean. The load could be quite
high if everything was kept in one single place, www proxy cache systems
could help a bit perhaps but as you say, scalability would not be good.
For instance, suppose you have a FPI of the form
+//STRING1//DTD STRING2
As a thought experiment, consider the hierarchic analog
STRING2.DTD.STRING1.fpi
and imagine using DNS to look this up, possibly recrusively, for either a
host (which could be queried with another protocol) or even a URL. This
may work if we could have the 'fpi' TLD reserved for such things.


So one question remains, would FPI's and catalogs on the www become
popular enough to warrant the trouble of defining a new reserved TLD?

[1]I have avoided to use the word "registration".

All the best...

--
Rex
Jul 23 '05 #80
On Sat, 11 Dec 2004 22:31:52 +0000, Michael Rozdoba wrote:
If I want to require elements & attributes to be lowercase the following
is necessary & sufficient:

In the .dcl specify SYNTAX NAMING NAMECASE GENERAL as NO, and in the
dtd, specify all element & attribute names in lowercase.

Is that at all close to the mark?


Yes. But not just element and attribute names. *All* name tokens are
affected. This includes enumerations (such as <input type=...>, the align
attribute, and so on), and any attribute values that are treated as name
tokens by the parser. (And, as far as the HTML DTDs are concerned, don't
forget the replacement texts of parameter entity references in content
models!) The edit of the HTML DTDs for this will be massive - I say,
don't bother.

A pedantic point: strictly speaking, SGML doesn't have a "case sensitivity"
option. The option is "case folding": whether or not name tokens will be
"normalized" to an upper-case form by the parser.

This is why, with NAMECASE GENERAL NO, you *must* use all SGML reserved
words (ELEMENT, ATTLIST, PCDATA, and so on) in their upper-case form,
because that's how they're defined in the Reference Concrete Syntax.
(Note how XML requires this, for SGML compatibility.)

Jul 23 '05 #81
Arjun Ray wrote:
On Sat, 11 Dec 2004 22:31:52 +0000, Michael Rozdoba wrote:

If I want to require elements & attributes to be lowercase the
following is necessary & sufficient:

In the .dcl specify SYNTAX NAMING NAMECASE GENERAL as NO, and in
the dtd, specify all element & attribute names in lowercase.

Is that at all close to the mark?

Yes. But not just element and attribute names. *All* name tokens
are affected.


Okay - I was being sloppy in my use of language, which in this situation
isn't very sensible.
This includes enumerations (such as <input type=...>, the align
attribute, and so on),
Understood.
and any attribute values that are treated as name tokens by the
parser. (And, as far as the HTML DTDs are concerned, don't forget
the replacement texts of parameter entity references in content
models!)
I think I noticed that.
The edit of the HTML DTDs for this will be massive - I say, don't
bother.
I had a quick look through, not understanding parts of the syntax &
thought, lots of potential to mess up, but just about doable.

Then I had another look & came to the same conclusion as you advise :)

The chances of me not messing up are near zero - I think I'd have to
write something to do the replacement for me, then get a few second
opinions as to whether my code was sound. Maybe as an exercise when I
have some free time.
A pedantic point: strictly speaking, SGML doesn't have a "case
sensitivity" option. The option is "case folding": whether or not
name tokens will be "normalized" to an upper-case form by the parser.
Hmm, I don't think I'd call that pedantic. Thanks. Again, I was being
sloppy to avoid having to check out details & rethink, as I'm not
familiar with the subject - something apparent from my posts to this
thread, I imagine ;)
This is why, with NAMECASE GENERAL NO, you *must* use all SGML
reserved words (ELEMENT, ATTLIST, PCDATA, and so on) in their
upper-case form, because that's how they're defined in the Reference
Concrete Syntax. (Note how XML requires this, for SGML
compatibility.)


Indeed. My first thought was can I just lowercase the lot, but it was
clear from what little I did read that that wasn't going to be an
option. Though just perhaps it might be simpler to approach this from
the point of view of what has to remain uppercase rather than the other
way around.

<wastes time>

I'm not sure it makes much difference :/ Specifically for HTML 4.01
Strict, I got as far as lowercase all barring:

"-//[non greedy match any]"
"[non greedy match any].ent"

Any of the following when bounded by non-alphanumerics
!ELEMENT
!ATTLIST
EMPTY
IGNORE
CDATA
NAME
ID
IDREF
IDREFS
REF
NUMBER
DATA
PCDATA
OBJECT

However OBJECT requires more information on the context & I wasn't sure
if it was okay to have script as both an element and an entity
reference. By that point the hacky procedure was too messy even for me.

Might be simpler to write something which parses the DTD properly.

Thanks again.

--
Michael
m r o z a t u k g a t e w a y d o t n e t
Jul 23 '05 #82

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

9 posts views Thread by Ray | last post: by
9 posts views Thread by wardy1975 | last post: by
14 posts views Thread by Arne | last post: by
5 posts views Thread by Andy Dingley | last post: by
reply views Thread by Mudiya Dissa | last post: by
1 post views Thread by CARIGAR | last post: by
reply views Thread by zhoujie | last post: by
reply views Thread by suresh191 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.