 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymous org> wrote:
> That's /one/ reason why XML requires UTF-16 files to start with a byte
> order mark: If the file starts with "FE FF" or "FF FE", it's either
> UTF-16, malformed XML (not starting with optional whitespace followed by
> "<?"), or indeed garbish, so UTF-16 is a safe bet in that case.
> Otherwise rely on the file format being backward compatible with ASCII,
> and treat it as UTF-8 (which is ASCII-compatible as well) until an
> encoding declaration tells you otherwise.
OTOH, it would be quite trivial to guess that a HTML/XML file is
UTF-16-encoded: If each other byte is 0 and each other form valid
HTML/XML (at least up to the header section that specifies the encoding),
then it's a safe bet that it's UTF16-encoded.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New escreveu:
> On 2/23/2012 11:06, Warp wrote:
>> It's verbose, but it has one advantage over most other formats: It's
>> standardized and pretty well supported.
>
> It also has an advantage in that it's a *markup language*. That's what
> it's for. Just as it sucks for passing around arrays of floats or
> passing pov-ray data objects between clusters of renderers or encoding
> routing table updates, it does pretty darn good at things like writing
> help pages, user manuals, and so on.
>
> Bitching that XML is poorly suited for something it was never designed
> to do is just pointless.
Precisely so, like implementing validators or transformers for xml docs.
How recursive and verbose you can get? "Hey, Darren, have you already
wrote that xml document to validate the xml document validator that
validates our client xml document?"
I can't actually believe a typeful haskell supporter (I'm looking at
Orchid) is here advocating an xml document rather than writing a typeful
haskell program to validate data marshalling.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2/24/2012 1:10, Invisible wrote:
> That said, it /does/ seem overly complicated for the simple problem it's
> supposed to solve...
What simple problem do you think it was supposed to solve?
--
Darren New, San Diego CA, USA (PST)
People tell me I am the counter-example.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 25/02/2012 06:04, Darren New wrote:
> On 2/24/2012 1:10, Invisible wrote:
>> That said, it /does/ seem overly complicated for the simple problem it's
>> supposed to solve...
>
> What simple problem do you think it was supposed to solve?
The problem of marking up textual data.
A lot of people seem to think that if you just write some stuff in angle
brackets, that's XML. But it' actually far more complicated than that.
(As an aside, those aren't angle brackets. They're inequality signs. :-P
But I digress...)
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?
Then there's all that stupidity with character entities. It should be
possible to include character entities in /all/ XML documents, not just
XHTML. But to this day, I have never discovered a way of doing this.
One of the nice ideas of XML is that you can use namespaces to include
one sort of XML document inside enought - e.g., you could put an SVG
file inside an XHTML file. But nooo, apparently you need a specialised
DTD to do that. In fact, you need one DTD for XHTML + SVG, another,
different DTD for XHTML + MathML, a third, different DTD for XHTML +
MathML + SVG, and... ARE YOU PEOPLE INSANE?!
In short, most people just end up sticking stuff in angle brackets and
calling that XML. /Actual/ XML is far too complicated.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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.
> Then there's all that stupidity with character entities. It should be
> possible to include character entities in /all/ XML documents, not just
> XHTML. But to this day, I have never discovered a way of doing this.
You have to declare the entities. Otherwise, you run across &frump; and
don't know what it means. That's what DTDs are for.
> One of the nice ideas of XML is that you can use namespaces to include one
> sort of XML document inside enought - e.g., you could put an SVG file inside
> an XHTML file. But nooo, apparently you need a specialised DTD to do that.
You can. Of course, your various processors have to know what the various
namespaces *mean*, so you have to declare them and you have to have a
processor that understands them (which is where the DTDs come in).
--
Darren New, San Diego CA, USA (PST)
People tell me I am the counter-example.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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" ?>
Which is fair enough, although the 5-digit ISO code number isn't exactly
easy to remember. Then you have to say
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
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">
Um, didn't I just declare this as XHTML already? At least this URL is a
bit shorter, I guess...
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.
>> Then there's all that stupidity with character entities. It should be
>> possible to include character entities in /all/ XML documents, not just
>> XHTML. But to this day, I have never discovered a way of doing this.
>
> You have to declare the entities. Otherwise, you run across &frump; and
> don't know what it means. That's what DTDs are for.
So why isn't there a DTD somewhere that contains all the entities that
everybody uses, which I can just link to? More to the point, since
everybody uses the same set of entities, why aren't they built in?
>> One of the nice ideas of XML is that you can use namespaces to include
>> one
>> sort of XML document inside enought - e.g., you could put an SVG file
>> inside
>> an XHTML file. But nooo, apparently you need a specialised DTD to do
>> that.
>
> You can. Of course, your various processors have to know what the
> various namespaces *mean*, so you have to declare them and you have to
> have a processor that understands them (which is where the DTDs come in).
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. 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.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
|
|
