Home. 
.

transparent

transparent

transparent

Altova Mailing List Archives


Re: [xml-dev] xml over http - RFC 3023

From: "Andrew Welch" <andrew.j.welch@-----.--->
To: "Rick Jelliffe" <rjelliffe@-------.---.-->
Date: 12/1/2008 12:13:00 PM
> For application/xml you ignore the first step and go straight to the
> document. If your data is usually in UTF-8 or ASCII, you could perhaps read
> in the first block from bytes to characters and (if the transcoder has not
> generated an exception) confirm that there is no XML encoding declaration or
> BOM or that the string "utf-8" does not appear in the XML encoding
> declaration, in which case you don't need to do anything more complicated.
> If your data is text/xml, you are indeed in a sea of complication, which is
> why text/xml has been discouraged for so long.

ok, that makes sense, thanks.


> Maybe, but the mechanism for this occur, for Apache at least, is for someone
> to write it, contribute it, champion it and maintain it.

Champion a mechanism for a web server to serve xml?  really?


> But the basic XML contract is that the encoding must be explicitly labelled
> by the sender (creator of the document) and the recipient should not guess
> but use the label. If this is too much for naive users, then XML is simply
> not the technology for them, and XML should not be blamed for not working in
> a situation it explicitly was designed to avoid. It is just like if someone
> does not know what + means they cannot use a calculator. It is not an
> indictment of mathematics if someone who does not know + cannot use a
> calculator. Character encoding is just as fundamental to computer
> programming as knowledge of the difference between floats and ints, for
> example: that Western computer science and IT courses have guaranteed the
> ignorance of their students in this is sad.

Er, ok.  You do realise there is a different expert somewhere else in
the world saying exactly the same thing about their specialist area.
(not sure I agree with that analogy either)



> In any case, I thought most people had written off RSS as unprocessable by
> generic XML tools, because so much RSS was not well-formed? I thought one
> reason for Atom was that the early RSS systems creators messed up their XML
> and RSS never recovered.  With RSS, what you are not experiencing the
> failure of XML on the web, you may be experiencing the failure of non-WF XML
> (and the potential complexity of figuring out text/xml).

The vast majority of the feeds are RSS, very few are Atom so from here
it looks like Atom has had little impact so far.  Processing the RSS
feeds are a pain but manageable using xslt 2.0 calling out to tagsoup,
jtidy etc, and using a LexicalHandler to intercept the entities.

From my naive perspective, I would've thought the web server would
serve the XML with the correct encoding in the contenttype so I don't
have to ignore it, and/or I could the XML parser a url and it would
take care of it.  I'm not sure why I should be reading appendices of
the spec and writing low-level code for something that should be an
everyday task.  In that respect, I think, you could argue it hasn't
succeeded yet.



-- 
Andrew Welch
http://andrewjwelch.com
Kernow: http://kernowforsaxon.sf.net/

_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@l...
subscribe: xml-dev-subscribe@l...
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php



transparent
Print
Mail
Like It
Disclaimer
.

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.

.
.

transparent

transparent