Chuck Esterbrook wrote:
>
>At 02:50 PM 5/29/2001 +0200, Ruggier, Mario wrote:
>
>>In the case of HTML/XML, such faithfullness is a significant
>>advantage as this would keep open the option to manipulate
>>templates (HTML/XML + extra template mark-up) with any tool in
>>the ever-growing world of XML tools. (I am quite surprised that
>>*sp frameworks throw away xml-compliancy so easily, making
>>generation of asp or jsp pages, from obvious tool choices such
>>as xslt, require unnecessary twists and acrobatics.)
>
>I don't personally subscribe to the "XML tools" argument, which has been
>presented to me for so long. As of today, I don't personally know anyone
>both using various XML tools and requiring that they work with their
>templates. Actually, I don't know anyone using XML tools. :-)
I wouldn't mind knowing of decent XML tools myself. And I don't mean yet
another "tree widget"-based tool which gives limited editing facilities. What
would be extremely interesting is an editor which can manipulate XML documents
containing mixtures of XHTML and other elements, showing the XHTML elements
visually.
Amaya is a start but can be a pain to use. Mozilla has an editing component but
it needs a lot of work and it isn't as usable as Amaya. Neither of these
products can edit XML in the way I describe above. It's such a shame that
browsers have evolved lots of tedious components without properly addressing
one of the key objectives of the original Web project: editing.
>>And, even if only for HTML, something as innocuos-looking as:
>>
>> <table>
>> #for logEntry in $logEntries:
>> <tr ...
>> ...
>> </tr>
>> #end for
>>
>>will choke an html parser, as text is not allowed between
>>table and tr. Thus the option to use parser-based html tools,
>>to process and rewrite templates, is lost.
[...]
>Likewise, most browsers will deal with the above in some fashion or another
>without balking.
I remember the time of Mosaic and its bizarre interpretation of ill-formed HTML
documents too. ;-) But there is a good point here: if you can vouch for the
validity of the original template, and you can vouch for the transformation of
that template to a document, then you should be able to vouch for the final
document without needing to produce it.
One of the goals I have for XMLForms for Webware is this kind of support for
document validation. Moreover, it should be possible to define XMLForms
templates using valid XML... if the examples I give aren't valid (but well-
formed) XML already.
>>Imagine a web application with an extensive user interface, and
>>an abstract description of that interface in, naturally, xml.
>
>Actually, I find these things to be _much_ more natural in CSV than XML.
>Easier to read, edit and process. Admittedly, CSV doesn't do well with
>arbitrarily nested structures. So far, that hasn't been an issue for me.
That was precisely one of the motivations behind XMLForms (and the earlier
XForms project)!
>> From this description you want to generate every actual
>>'pageview' that the user sees... targeted for different contexts
>>(HTML, WML, ...), different languages, and so on. The interest in
>>being able to use xml-based tools to straightforwardly generate
>>all pageview templates would be rather high...
>
>My choice here is Python, which is a simple, but complete language with
>lots of power and libraries. I use XML only for communicating with other
>systems. Not for "coding", generation and such.
My belief is that many activities are so frequently repeated that they should
permit themselves to be described "declaratively". For example, the editing of
data structures in a form, and the passing of data between forms, are probably
so common in many Web applications that they should not need extensive coding
to be implemented. Another goal of XMLForms for Webware is support for such
operations in the data model descriptions through declaration.
>>Admittedly, seeing the code in a (current web) browser is a
>>convenience. But this is viewer dependent. XML viewers may be used.
>
>An XML viewer will not *render* the [X]HTML. The page designers I work with
>want to see a rendered page in Netscape or IE _with_ the templating
>instructions. So do I.
But I want to be able to view the structure of documents *and* collapse some of
that structure into visual components. That would be fantastic! There are
probably hundreds of half-finished XML editors which pretend to be editors by
providing the stock tree widget on the platform in question. The only half-
decent one I have seen is XML Spy, which does give other representations of
document elements (such as tables).
Regards,
Paul
--
Get your firstname@lastname email for FREE at http://Nameplanet.com/?su
_______________________________________________
Webware-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/webware-devel
