 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2/27/2012 1:15, Invisible wrote:
> On 26/02/2012 12:35 AM, Darren New wrote:
>> On 2/25/2012 2:37, Orchid Win7 v1 wrote:
>>> For example, to say "this XML file actually contains XHTML", you're
>>> supposed
>>> to add something like 5 separate headers, each about 25 million miles
>>> long,
>>> to the top of the file. Why? Would one header not be sufficient?
>>
>> Really? What do you have to add? I suspect you exaggerate a bit.
>
> First, you must say
>
> <?xml version="1.0" encoding="ISO-8859-1" ?>
You have to do that for XML anyway, so you don't have to do that for "this
contains XHTML." Yes, it's more than you need for HTML, but then you don't
have to rely on a web browser header to tell you what type it is.
> Which is fair enough, although the 5-digit ISO code number isn't exactly
> easy to remember.
I guess if you don't do it often you don't already have such memorized. :-)
> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
Right. That's the one line that you need to make it xhtml.
> Yeah, I'm really going to remember that without looking it up. :-P No, you
> can't just say "this is XHTML". You really do have to write all that crap.
> And after /that/, you still have to say
>
> <html xmlns="http://www.w3.org/1999/xhtml">
Er, no, you don't, unless you want an "html" namespace in your XML. If you
don't want to use anything *except* html in your html document, you don't
need this line.
> In short, that's a /hell/ of a lot of typing, before I've even written my
> document. It's also a lot of typing that I have to go look up on three
> different websites every single damned time I want to write XHTML.
So, store it somewhere. The first line says it's XML, the second says it's
XHTML, and the third says how you'll name things if you *don't* use XHTML.
> So why isn't there a DTD somewhere that contains all the entities that
> everybody uses, which I can just link to?
There is. That's what the <!DOCTYPE> tag you complain about is doing. It's
linking to the entities for xhtml. See that ".dtd" on the end of the URL?
> More to the point, since everybody
> uses the same set of entities, why aren't they built in?
Because they don't. Only the people using XHTML use that set of entities,
and you complain about having to supply the URL to them. :-)
> You would /think/ you could just say "hey, this stuff here is in the XHTML
> namespace, this stuff here is in the SVG namespace", and that would work.
> But it doesn't. You need to use a DTD specially written for the exact
> combination of XHTML+SVG.
http://www.rpbourret.com/xml/NamespacesFAQ.htm#valid_2
Plus, things like SOAP wouldn't work at all, where you're embedding an
arbitrary XML inside another arbitrary XML and expecting the processor of
the latter to be able to understand the former without change.
> To me, this indicates that the system is
> fundamentally broken. It should not be necessary to write a separate DTD for
> every possible combination of XML documents imaginable. You should just be
> able to refer to the DTD for XHTML and the DTD for SVG and have it work.
http://www.rpbourret.com/xml/NamespacesFAQ.htm#use_5
The basic problem is that you still have to define how the bits combine. Can
you attach XHTML color declarations to color svg shapes? Can you use svg
shapes as the shape for bullet points in a bulletted list? If you combined a
vcard with xhtml, would you be allowed to nest a html:hr element inside the
street address element of a vcard? Without a DTD that says the allowable
combinations, there's no way to validate a complete document against a DTD.
The purpose of the DTD is to ensure that the <hr> element goes inside the
body and not the head of the HTML document, and that there's only one head
and one body. How is a generic XML parser supposed to know that you can't
put an SVG <use> in the header, or a <symbol> between </body> and </html>?
--
Darren New, San Diego CA, USA (PST)
People tell me I am the counter-example.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>> Really? What do you have to add? I suspect you exaggerate a bit.
>>
>> First, you must say
>>
>> <?xml version="1.0" encoding="ISO-8859-1" ?>
>
> You have to do that for XML anyway, so you don't have to do that for
> "this contains XHTML."
Well, that at least is true enough.
>> Which is fair enough, although the 5-digit ISO code number isn't exactly
>> easy to remember.
>
> I guess if you don't do it often you don't already have such memorized. :-)
I don't generally make a habit of memorising long code numbers, no.
>> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
>> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
>
> Right. That's the one line that you need to make it xhtml.
Well, it's more like 3 lines. :-P
>> And after /that/, you still have to say
>>
>> <html xmlns="http://www.w3.org/1999/xhtml">
>
> Er, no, you don't, unless you want an "html" namespace in your XML. If
> you don't want to use anything *except* html in your html document, you
> don't need this line.
The W3C validator disagrees.
The above declaration sets the default namespace for any elements which
do not have a namespace explicitly declared. W3C seems to insist that
this is /required/, even though a doctype has already been given.
(For example, my personal web pages do not have this third declaration.
When I wrote them, the validator accepted them. Today, it rejects them
because of the missing third declaration. Gotta love how a set of
standards compliant pages are no longer compliant with the same
standard, even though the pages haven't changed...)
>> In short, that's a /hell/ of a lot of typing, before I've even written my
>> document. It's also a lot of typing that I have to go look up on three
>> different websites every single damned time I want to write XHTML.
>
> So, store it somewhere.
That's what I end up doing. And then every time I go to a different
computer, I have to look it up all over again.
>> So why isn't there a DTD somewhere that contains all the entities that
>> everybody uses, which I can just link to?
>
> There is. That's what the <!DOCTYPE> tag you complain about is doing.
> It's linking to the entities for xhtml. See that ".dtd" on the end of
> the URL?
It's linking the entire definition of the XHTML language, not just the
character entities.
As far as I know, there is no way of using XHTML entities without also
declaring that this is an XHTML document. If just the entity definitions
were in a separate DTD, you could maybe do it. (But even then, I have a
sinking feeling you can only have one DTD per document, so you'd still
be stuffed.)
>> More to the point, since everybody
>> uses the same set of entities, why aren't they built in?
>
> Because they don't. Only the people using XHTML use that set of
> entities, and you complain about having to supply the URL to them. :-)
Well, 3 URLs. :-P
>> You would /think/ you could just say "hey, this stuff here is in the
>> XHTML
>> namespace, this stuff here is in the SVG namespace", and that would work.
>> But it doesn't. You need to use a DTD specially written for the exact
>> combination of XHTML+SVG.
>
> http://www.rpbourret.com/xml/NamespacesFAQ.htm#valid_2
I'm not sure what this is trying to say.
I know that you /can/ stuff more than one namespace into an XML
document. It's just that it doesn't /work/ when you try to use it.
> Plus, things like SOAP wouldn't work at all, where you're embedding an
> arbitrary XML inside another arbitrary XML and expecting the processor
> of the latter to be able to understand the former without change.
Didn't we just...? Oh wait, that's SOPA. Never mind.
>> To me, this indicates that the system is
>> fundamentally broken. It should not be necessary to write a separate
>> DTD for
>> every possible combination of XML documents imaginable. You should
>> just be
>> able to refer to the DTD for XHTML and the DTD for SVG and have it work.
>
> http://www.rpbourret.com/xml/NamespacesFAQ.htm#use_5
I still don't follow.
> The basic problem is that you still have to define how the bits combine.
> Can you attach XHTML color declarations to color svg shapes? Can you use
> svg shapes as the shape for bullet points in a bulletted list? If you
> combined a vcard with xhtml, would you be allowed to nest a html:hr
> element inside the street address element of a vcard? Without a DTD that
> says the allowable combinations, there's no way to validate a complete
> document against a DTD.
Isn't that the purpose of the HTML <object> tag though? So it can
contain an arbitrary object? If you just state that <object> is the only
place where elements from another namespace can go, the problem is solved.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2/29/2012 1:24, Invisible wrote:
> The W3C validator disagrees.
Their validator might not be compliant with the standard.
> (For example, my personal web pages do not have this third declaration. When
> I wrote them, the validator accepted them. Today, it rejects them because of
> the missing third declaration. Gotta love how a set of standards compliant
> pages are no longer compliant with the same standard, even though the pages
> haven't changed...)
See? Either it wasn't before, or it isn't now. Hard to say without actually
delving deep into the mess.
>> There is. That's what the <!DOCTYPE> tag you complain about is doing.
>> It's linking to the entities for xhtml. See that ".dtd" on the end of
>> the URL?
>
> It's linking the entire definition of the XHTML language, not just the
> character entities.
Right. Well, what do you expect?
> As far as I know, there is no way of using XHTML entities without also
> declaring that this is an XHTML document.
Right. Because that would be meaningless.
> If just the entity definitions
> were in a separate DTD, you could maybe do it. (But even then, I have a
> sinking feeling you can only have one DTD per document, so you'd still be
> stuffed.)
Correct and correct, and it makes perfect sense why this is so.
>> http://www.rpbourret.com/xml/NamespacesFAQ.htm#valid_2
>
> I'm not sure what this is trying to say.
It's explaining why it doesn't make sense to ask to have more than one DTD
for a document. An XML document forms a tree. A DTD describes which types of
nodes can be descendants of other types of nodes. It wouldn't make sense to
have two of those declarations for one tree.
It's like complaining in Haskell that if you want to use either an integer
or a string in a variable, you have to declare a type that supports a choice
between *both*, instead of just mixing them together.
If you don't check structure with a DTD, you can mix and match whatever you
want. But a DTD is the "strong typing" for XML (and SGML), and it doesn't
make sense to say "here's a set of two independant declarations of types."
> I know that you /can/ stuff more than one namespace into an XML document.
> It's just that it doesn't /work/ when you try to use it.
It ... works for me. You just have to (a) do it right and (b) have a tool
that supports it.
> Isn't that the purpose of the HTML <object> tag though? So it can contain an
> arbitrary object? If you just state that <object> is the only place where
> elements from another namespace can go, the problem is solved.
1) Can HTML appear inside the <object> tag? If so, can your other namespace
also appear inside the <object> tag inside the <html> tag inside the
<object> tag? Etc.
2) Sure, for HTML. Solve that in a general way. What if you want only some
tags to appear in the <head> and only other tags appear in the <body>? No,
there's no notation in a DTD that says "by the way, don't check the validity
of anything inside this particular type of tag." Other than CDATA maybe.
--
Darren New, San Diego CA, USA (PST)
People tell me I am the counter-example.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 02/03/2012 05:54 AM, Darren New wrote:
> On 2/29/2012 1:24, Invisible wrote:
>> The W3C validator disagrees.
>
> Their validator might not be compliant with the standard.
That sounds /highly/ implausible...
> See? Either it wasn't before, or it isn't now. Hard to say without
> actually delving deep into the mess.
I'm going to suggest that they changed the standard to be more
restrictive, or they added a missing check to the validator. It seems
unlikely that the validator would become /less/ compliant over time. But
sure, "mess" seems like an accurate way to describe it. :-P
>> It's linking the entire definition of the XHTML language, not just the
>> character entities.
>
> Right. Well, what do you expect?
>
>> As far as I know, there is no way of using XHTML entities without also
>> declaring that this is an XHTML document.
>
> Right. Because that would be meaningless.
The point is, any XML document that contains text may potentially need
non-ASCII characters. But only XML documents which are also XHTML can
contain non-ASCII characters. How is that sensible?
Sure, having more than one DTD doesn't make a lot of sense. (Except that
it would be nice to apply different DTDs to different namespaces. But
that has little to do with entities.) The problem is that character
entities are in the DTD, not defined in the XML spec for /everyone/ to use.
>>> http://www.rpbourret.com/xml/NamespacesFAQ.htm#valid_2
>>
>> I'm not sure what this is trying to say.
>
> It's explaining why it doesn't make sense to ask to have more than one
> DTD for a document. An XML document forms a tree. A DTD describes which
> types of nodes can be descendants of other types of nodes. It wouldn't
> make sense to have two of those declarations for one tree.
OK. But it could make sense for different DTDs to apply to different
subtrees, surely?
>> I know that you /can/ stuff more than one namespace into an XML document.
>> It's just that it doesn't /work/ when you try to use it.
>
> It ... works for me. You just have to (a) do it right and (b) have a
> tool that supports it.
Write at XHTML document which contains some MathML. Unless you use the
magic XHTML+MathML DTD, it doesn't work at all. Clearly it /should/, but
it doesn't.
>> Isn't that the purpose of the HTML <object> tag though? So it can
>> contain an
>> arbitrary object? If you just state that <object> is the only place where
>> elements from another namespace can go, the problem is solved.
>
> 1) Can HTML appear inside the <object> tag? If so, can your other
> namespace also appear inside the <object> tag inside the <html> tag
> inside the <object> tag? Etc.
>
> 2) Sure, for HTML. Solve that in a general way. What if you want only
> some tags to appear in the <head> and only other tags appear in the
> <body>? No, there's no notation in a DTD that says "by the way, don't
> check the validity of anything inside this particular type of tag."
> Other than CDATA maybe.
In summary, XML doesn't provide the necessary tools to solve common
problems such as mixing more than one markup together.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 2012-03-02 04:25, Invisible a écrit :
> On 02/03/2012 05:54 AM, Darren New wrote:
>> On 2/29/2012 1:24, Invisible wrote:
>>> As far as I know, there is no way of using XHTML entities without also
>>> declaring that this is an XHTML document.
>>
>> Right. Because that would be meaningless.
>
> The point is, any XML document that contains text may potentially need
> non-ASCII characters. But only XML documents which are also XHTML can
> contain non-ASCII characters. How is that sensible?
Non-XHTML documents can and do contain non-ASCII characters. What you
meant to say is that you can't use their XHTML representations outside
an XHTML document. Case in point: a .DOCX file does not use é or
à but can most definitely contain the characters represented by
those entities.
--
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/* flabreque */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/* @ */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/* gmail.com */}camera{orthographic location<6,1.25,-6>look_at a }
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 3/2/2012 1:25, Invisible wrote:
> The point is, any XML document that contains text may potentially need
> non-ASCII characters. But only XML documents which are also XHTML can
> contain non-ASCII characters. How is that sensible?
No. Only XML documents which are also XHTML documents can use the XHTML
standard for specifying ASCII-only names for non-ASCII characters.
You *can* put non-ASCII characters in an XML document. That's what the first
line is for, with the hard-to-remember code numbers, remember? Different
standards can have different entities. If I want an XML entity that
represents the symbol for the left eyeball, or an XML entity that represents
a internal link to the document management system of google, I can do that
-- just not in XHTML. Look at the triglyphs for C-on-punched-cards. Same
sort of thing. They're only applicable to C.
> Sure, having more than one DTD doesn't make a lot of sense. (Except that it
> would be nice to apply different DTDs to different namespaces. But that has
> little to do with entities.) The problem is that character entities are in
> the DTD, not defined in the XML spec for /everyone/ to use.
So type the characters directly. Nothing stops you from embedding a thron or
an omega in your document except that you don't want to learn how to type
one on the keyboard you have.
> OK. But it could make sense for different DTDs to apply to different
> subtrees, surely?
You still have to have one DTD that says where the trees are allowed to join
up. There's nothing that says that DTD isn't trivial to construct from two
other DTDs.
>>> I know that you /can/ stuff more than one namespace into an XML document.
>>> It's just that it doesn't /work/ when you try to use it.
>>
>> It ... works for me. You just have to (a) do it right and (b) have a
>> tool that supports it.
>
> Write at XHTML document which contains some MathML. Unless you use the magic
> XHTML+MathML DTD, it doesn't work at all. Clearly it /should/, but it doesn't.
Sure. You have to have the right DTD, because MathML expressions can't
appear inside URLs, nor can they appear as a child of a <meta> link in the
header, etc. You have to know the rules of where each can appear in the
other if you want to actually check it's right.
> In summary, XML doesn't provide the necessary tools to solve common problems
> such as mixing more than one markup together.
It does. You just don't like the solution. It's like you're saying "Haskell
doesn't provide the necessary tools to incorporate C syntax into its type
declarations." No, they're completely different type systems.
--
Darren New, San Diego CA, USA (PST)
People tell me I am the counter-example.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> The point is, any XML document that contains text may potentially need
>> non-ASCII characters. But only XML documents which are also XHTML can
>> contain non-ASCII characters. How is that sensible?
>
> No. Only XML documents which are also XHTML documents can use the XHTML
> standard for specifying ASCII-only names for non-ASCII characters.
Why would you want three different standard names for the same character?
> So type the characters directly. Nothing stops you from embedding a
> thron or an omega in your document except that you don't want to learn
> how to type one on the keyboard you have.
Well, for that matter, you can just type the Unicode code number
directly. (This at least works with all operating systems and text
editors, doesn't break every five minutes, etc.) It's just that
memorising large quantities of code numbers isn't exactly trivial.
>> OK. But it could make sense for different DTDs to apply to different
>> subtrees, surely?
>
> You still have to have one DTD that says where the trees are allowed to
> join up. There's nothing that says that DTD isn't trivial to construct
> from two other DTDs.
Well, if it were possible for one DTD to import several others, then it
could be pretty easy... As it is, constructing even one DTD is so
insanely hard that only the professionals can do it.
>> In summary, XML doesn't provide the necessary tools to solve common
>> problems
>> such as mixing more than one markup together.
>
> It does. You just don't like the solution.
What, a combinatorial explosion of DTDs for every possible combination
of XML applications that you might ever want to combine? No, that's just
silly.
> It's like you're saying
> "Haskell doesn't provide the necessary tools to incorporate C syntax
> into its type declarations." No, they're completely different type systems.
Not relevant, but: Actually Haskell does let you do this. There's a
standard preprocessor for exactly this task. People use it when binding
to external C or C++ libraries.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 3/3/2012 1:29, Orchid Win7 v1 wrote:
> Why would you want three different standard names for the same character?
What's the chinese word for "quotation mark"? For that matter, why would you
even want a "name" for a character, unless your text editor is too lame to
actually store the character? Leap-frog into the 21st century and start
using Windows Notepad to edit your text or something.
> Well, for that matter, you can just type the Unicode code number directly.
> (This at least works with all operating systems and text editors, doesn't
> break every five minutes, etc.) It's just that memorising large quantities
> of code numbers isn't exactly trivial.
Right. So you're complaining that XML is broken because your text editor
can't handle Unicode? Just type the unicode characters directly into the
text document, without using any code numbers.
> Well, if it were possible for one DTD to import several others, then it
> could be pretty easy... As it is, constructing even one DTD is so insanely
> hard that only the professionals can do it.
... says the man who programs in Haskell. ;-)
You don't really have to *import* DTDs. You can pretty much just concatenate
them, as long as there aren't conflicting definitions, and fix up only the
places where they actually interact. I mean, if you have some java-specific
XML (say, a build system), and you want to embed SVG into that (say, to
define the splash screen for the completed program), your build system is
going to have to understand how to interpret SVG.
> What, a combinatorial explosion of DTDs for every possible combination of
> XML applications that you might ever want to combine? No, that's just silly.
Why not? You get a combinatorial explosion of types in your computer
programs for every new program you write.
Generally, your XML processor has to understand the combination you're using
anyway, so it's not really obvious there's a problem here. It's not like
you're going to combine SEP and XHTML in one program and expect to not do
more work than frobbing around the DTD.
--
Darren New, San Diego CA, USA (PST)
People tell me I am the counter-example.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Why would you want three different standard names for the same character?
>
> What's the chinese word for "quotation mark"? For that matter, why would
> you even want a "name" for a character, unless your text editor is too
> lame to actually store the character? Leap-frog into the 21st century
> and start using Windows Notepad to edit your text or something.
It's not possible to type exotic characters. But it's trivial to type in
their names.
> Right. So you're complaining that XML is broken because your text editor
> can't handle Unicode? Just type the unicode characters directly into the
> text document, without using any code numbers.
...aaaand then watch it break into a thousand pieces because raw text
files have no way of specifying what actual character encoding is being
used. :-P
>> Well, if it were possible for one DTD to import several others, then it
>> could be pretty easy... As it is, constructing even one DTD is so
>> insanely hard that only the professionals can do it.
>
> ... says the man who programs in Haskell. ;-)
The problem is, the only real documentation on how to write DTDs is the
antiquated SGML reference documentation, which is hardly easy going.
From what I've seen from other written DTDs, it's just damned hard,
that's all.
>> What, a combinatorial explosion of DTDs for every possible combination of
>> XML applications that you might ever want to combine? No, that's just
>> silly.
>
> Why not? You get a combinatorial explosion of types in your computer
> programs for every new program you write.
Actually... no, you don't.
In any half-decent language, you can implement sorting and searching.
Once. In a language that's not so good, you have to reimplement this for
every individual datatype. And that's what the DTD situation feels like;
endlessly reimplementing the same language specs over and over again.
And these aren't exactly trivial languages... It would be frighteningly
easy to come up with an XHTML+MathML DTD where the XHTML part doesn't
actually match the stand-alone XHTML DTD, for example.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 3/3/2012 14:04, Orchid Win7 v1 wrote:
> It's not possible to type exotic characters.
Sure it is. I just turned on chinese for my wife. Use alt-shift to toggle
between languages. :-)
The problem is that your *editor* doesn't make it simple to type exotic
characters, yes? Why do you complain that your XML processor doesn't
understand exotic characters when its your editor that makes them difficult
to type?
> ...aaaand then watch it break into a thousand pieces because raw text files
> have no way of specifying what actual character encoding is being used. :-P
That's why the first line of your XML document includes the character set in
which the rest of the document is written. *right there* is the reason you
have to put <?xml ...> at the start, along with the funky code number for
your character set.
> The problem is, the only real documentation on how to write DTDs is the
> antiquated SGML reference documentation, which is hardly easy going. From
> what I've seen from other written DTDs, it's just damned hard, that's all.
It's actually pretty straightforward. Google "dtd tutorial".
> It would be frighteningly easy to come up with
> an XHTML+MathML DTD where the XHTML part doesn't actually match the
> stand-alone XHTML DTD, for example.
Sure. And it would be frighteningly easy to come up with a generic sorting
algorithm that works incorrectly on certain types. Don't do that.
The point is that a DTD is a type specification. It also originally
specified what closing tags could be left out by specifying what could be
nested inside what. (You don't have to close a paragraph in a book if the
next tag opens a new chapter, because chapters don't nest and paragraphs
can't contain chapters.)
So don't use a DTD. Use an XSL or whatever they call it these days.
--
Darren New, San Diego CA, USA (PST)
People tell me I am the counter-example.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
