Re: supporting both formats html5 & xhtml5 re: http://www.w3.org/html/wg/html5/#xhtml5

 > Yes, the use of XML+XSLT in the browser is interesting, and
 > once shipped a feature to customers that made heavy use of XSLT.
 > On the other hand, I suspect that in future the data going
 > across the wire is more likely to JSON - not XML - and
 > future solutions are more likely JSON+Javascript.

Now you are comparing apples with oranges!

XML and JSON both have their strengths.
XML+XSLT in the browser has a lot of potential.


That's all,
Andrew R.



Preston L. Bannister wrote:
> On Dec 21, 2007 11:51 PM, Ben Boyle <benjamins.boyle@gmail.com 
> <mailto:benjamins.boyle@gmail.com>> wrote:
> 
>     On Dec 21, 2007 10:36 PM, Preston L. Bannister <preston@bannister.us
>     <mailto:preston@bannister.us>> wrote:
>      > The advantage to XHTML lies in server-side XML-based processing
>     pipelines,
>      > not in the browser.  Once you come to that realization, then you
>     have to ask
>      > whether a server-side rendering to HTML is in fact the more
>     optimal choice.
> 
>     An interesting point, but I think this is highly dependent on whether
>     you are publishing information primarily for browsers. Personally I
>     like a combination of atom and html, both generated from a single
>     source of data (for which I prefer XML). HTML is for the browsers,
>     atom for feed readers and other (potential) consumers/aggregators. I
>     use XHTML within Atom (personal preference to avoid CDATA where I
>     can).
> 
> 
> 
> Hmm - yes, I agree.  The web-fragment embedded in XML (of which Atom is 
> an excellent example) does indeed call for an XML representation of 
> HTML. You could get by with CDATA but ... this strikes me as inelegant 
> and less versatile.
> 
> We need to be a shade careful about calling this XHTML.  This use-case 
> calls for a (large) subset of HTML, but it is not necessary - and 
> probably not desirable - to have full HTML represented.  Seems I've seem 
> a few examples in recent months exploring what should be left out (from 
> Sam Ruby?).  The term XHTML means a lot more to some folk than is called 
> for by this use-case.
> 
>  
> 
>     I do agree: "the advantage to XHTML lies in server-side XML-based
>     processing pipelines"
> 
>     I don't specifically need browsers to support XHTML - I certainly
>     don't need the specification to mandate any compliance. When I stop to
>     think about it, browser support for XML+XSLT (including HTML output)
>     would be more valuable (to me) than XHTML support. One day, if/when it
>     is well established in UAs and AT. Until then, it seems beyond the
>     scope of this WG but an interesting topic ~:)
> 
> 
> 
> Yes, the use of XML+XSLT in the browser is interesting, and once shipped 
> a feature to customers that made heavy use of XSLT.  On the other hand, 
> I suspect that in future the data going across the wire is more likely 
> to JSON - not XML - and future solutions are more likely 
> JSON+Javascript. JSON tends to be leaner on the wire, and more readily 
> useful in the browser. The number of cases where XML+XSLT proves 
> suitable is probably shrinking.
> 
> The above is largely outside the scope of this working group, aside for 
> establishing the irrelevance of XML.  :)
>

Received on Saturday, 22 December 2007 23:33:20 UTC