<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
Hi Dan,<br>
<br>
Thanks for taking the time to respond to my (basic) questions about
your proposed changes. The examples for both page and composite
component look good and help further understand what you're
suggesting. Like Jason, I'm not sure I agree w/ the default namespace
changing by default... but that's something we can work out easy
enough. I really like the direction you're taking this so far. :)<br>
<br>
One area I am still not clear on is what changes a page (or component)
author will need to do to accommodate CDATA sections in their page.
Issue 697
(<a class="moz-txt-link-freetext" href="https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=697">https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=697</a>)
states:<br>
<br>
> There should also be control on how comments and CDATA are
handled. There shouldn't be an assumption that what is in the template
should be passed directly to the browser, but rather have more control
over what gets passed and what doesn't.<br>
<br>
So in what cases are CDATA currently required? And how would the
page/component author need to change their document to be non-ambiguous
on how to handle these?<br>
<br>
Thanks!<br>
<br>
Ken<br>
<br>
Dan Allen wrote:
<blockquote
cite="mid:19758da0912112220p5bee4f96yd92146df1e23c43a@mail.gmail.com"
type="cite"><br>
<div class="gmail_quote">
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000">.xhtml for a src file does
not necessarily mean the browser gets
xhtml. The browser might receive an image, a txt file, html, xhtml,
pdf, etc. I doubt (hope) Jacob didn't intend to serve every request as
an xhtml file to the browser! :)</div>
</blockquote>
<div><br>
Right, but that's the leaky abstraction. We've more or less
standardized (it is the default extension, after all) on .xhtml, but
XHTML is not extensible. So let's just call it what it is, XML.<br>
<br>
Of course, I recognize that we can send other things to the browser. In
Seam we send e-mails, create PDFs, create RSS, create images, and
create excel documents. The point I'm making is that if the source
document can transform, then the most logical thing to call the source
is XML, not XHTML. The later implies some relationship with a
particular variety of XML, and specially one that browsers consume,
confusing the whole matter.<br>
</div>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000">
<div class="im"><br>
<blockquote type="cite">So we are using a document with an XHTML
doctype, and XML
declaration, XML namespaces (which XHTML does not support), yet no XML
schema to back it. We are in serious limbo. Do you realize how strange
it is to use .xhtml to produce an ATOM feed? And we wonder why the
tools are having trouble supporting this (okay, NetBeans figured it
out, but still).<br>
</blockquote>
</div>
Rename the extension. :) Does that help? j/k<br>
</div>
</blockquote>
<div><br>
It does, quite a lot. But it needs to be official, not just a personal
change that is made in development.<br>
</div>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000"><br>
I'd like to understand what benefit we're getting by adding more
complexity (proposed below) and potentially taking a performance hit
(although perhaps some of the schema stuff can be turned off). Perhaps
it's worth it. But as a non-IDE guy, I'm struggling to see just how
much (if any) value this adds. Are the benefits theoretical? Are they
material? Does is speed development for the end user, or just make us
sleep better at night knowing we can call it true XML? I'm not against
anything proposed here, but at the same time I don't feel like I
understand that value-add we're shooting for. Can someone please take
the time to explain the pros (and possibly cons) of the proposed
changes? From what I gather, it's all for the benefit of leveraging
existing tools?</div>
</blockquote>
<div><br>
</div>
</div>
Understand that first and foremost, this is a semantic change. It is an
acknowledgement, by the spec, that the source documents are just XML.
Nothing more. I can't see there being any performance change and
probably a minial implementation change. What will get fixed almost
immediately are the problems we are having with doctype declarations,
XML declarations and CDATA, because we are getting source and output
mixed up right now. The XML should describe what should be produced,
not just pass through stuff these critical aspects of the output.<br>
<br>
My point about the XSD is an add-on, of course. You don't have to have
it, but it will sure benefit people with XML editors a whole bunch. The
point is, if we treat these documents as XML documents, and not some
strange hybrid of XHTML and XML component tags, then we can leverage
all the existing XML tools on the planet to edit, transform and
interpret these documents. When I type "vim home.xhtml" it just doesn't
work like if I typed "vim home.view.xml". It makes a difference.<br>
<br>
So while I say it is just about semantics, semantics are a big deal.<br>
<br>
-Dan<br clear="all">
<br>
-- <br>
Dan Allen<br>
Senior Software Engineer, Red Hat | Author of Seam in Action<br>
Registered Linux User #231597<br>
<br>
<a moz-do-not-send="true" href="http://mojavelinux.com">http://mojavelinux.com</a><br>
<a moz-do-not-send="true" href="http://mojavelinux.com/seaminaction">http://mojavelinux.com/seaminaction</a><br>
<a moz-do-not-send="true"
href="http://www.google.com/profiles/dan.j.allen">http://www.google.com/profiles/dan.j.allen</a><br>
</blockquote>
</body>
</html>