[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: What is the rule for parsing XML in a namespace inside HTM

• To: XML Developers List <xml-dev@l...>
• Subject: Re: What is the rule for parsing XML in a namespace inside HTML?
• From: Michael Champion <mc@x...>
• Date: Tue, 13 Jul 2004 13:50:20 -0400
• In-reply-to: <0E36FD96D96FCA4AA8E8F2D199320E52025A71DB@R...>
• References: <0E36FD96D96FCA4AA8E8F2D199320E52025A71DB@R...>

On Jul 12, 2004, at 9:56 PM, Joshua Allen wrote:
>
> Yeah, it's shows the narcissism of most developers.  "Please rewrite
> your page in some buzzword-compliant gobbledy-gook subset of XML that 
> is
> less reliable and harder to test than what you were already doing, and
> then I can theoretically write a screenscraper".
>
>
The point about developers asking end users to make life easy for them 
is well taken.  It's amazing how much ingenuity goes into doing useful 
things with tag soup and minimal metadata, but how much real benefit we 
get from all that lousy HTML via browsers, search engines, script 
applications, etc.  But maybe it is more globally efficient to have a 
small group of developers learn how to make sense out of tag soup than 
to force the masses to deal with the very real pain of full standards 
compliance.  [Browse the Atom mailing list archives if you disagree 
about the pain; the intersection of the appropriate HTTP, URI, MIME, 
HTML, and XML specs is a difficult target to hit once things get at all 
interesting.]

Still, the point of XHTML is not so much to be a stopgap but to bring 
some rigor to content so that ALL SORTS of XML technology can be thrown 
at it.  Screenscraping is just one use case, there's also querying, 
transformation, syndication, content re-use (without worrying about the 
HTML escaping hassles), web-services enablement ... for just about 
every XML infrastructure spec, there's a plausible scenario in which 
having Web content in XHTML enables all sorts of interesting things 
without relying on tidy or a tag soup parser to build a clean syntax or 
infoset.

We're at an interesting juncture:  The browser is being reinvigorated 
as a product and platform, and the importance of "standards" [in the 
broad sense, not the narrow sense of conformance to RFC's and 
Recommendations] is becoming obvious.  At the same time, it is becoming 
unpleasantly apparent that some Recommendations such as Namespaces and 
XHTML have run into a lot of resistance in the real world.  I'd like to 
see some real give and take -- "refactoring" if you will -- to realign 
the Recommendations with end-user reality and to re-synch the end-users 
with the vision enabled by standardization.

• References:
  • RE: What is the rule for parsing XML in a namespace inside HTML?
    • From: "Joshua Allen" <joshuaa@m...>

• Prev by Date: RE: What is the rule for parsing XML in a namespace inside HTML?
• Next by Date: Re: Edi complexity, does ebxml really reduce it?
• Previous by thread: RE: What is the rule for parsing XML in a namespaceinside HTML?
• Next by thread: RE: What is the rule for parsing XML in a namespace inside HTML?
• Index(es):
  • Date
  • Thread