[
Lists Home |
Date Index |
Thread Index
]
[As a preface to this message, I want to warn that this is more oriented
towards the application of XML-based technologies versus XML-based
technologies themselves. Hopefully this doesn't offend or peeve anybody
unintentionally.]
I am working on a project to allow web-based creation of XHTML documents,
whose contents are optionally annotated with non-XHTML elements [referred to
as "pages" from here on]. The pages are stored within a sort of content
repository system, whose job it is -- among other things -- to process and
expand the non-XHTML sections into conformant XHTML for delivery to an end
user. The processing and expansion of these elements allows for dynamic
inclusion of data residing within the content repository, be it binary
documents (PDF, MS Word, ...), images, or even other pages.
Now, the processing of these pages is straightforward and is in fact has
been completed. I am looking for suggestions, references, or even examples
of previous work, regarding building the UI for transparent creation of
these pages.
I have abandoned the WYSYWIG concept (mostly due to the complexity of doing
this w/out a rich client) in favor of a more "data with a visual twist"
approach -- similar to the Xerox Parc Sparrow[1][2] project. Unfortunately,
most of the literature on similar projects or approaches, while useful and
very interesting, appears to be quite dated[3]. Getting to where I am now
has taken some false starts, prototypes, and of course time.
I am investigating and prototyping at the moment the use of a mix of XML
Schema -- for type and context information -- combined with custom XML
documents which describe the visual aspects of the various types defined by
the XSDs. (For example, sure I can determine that a "td" element makes sense
as a child of a "tr," and also what makes sense belonging to a "td," but
what does it actually look like?) The base schema will of course be the
XHTML 1.0 XSD[4]. By taking this approach, my thinking is that the product
will be much more extensible, maintainable, powerful, and easier to
implement; as the schemas evolve and/or change, the UI will sort of re-adapt
itself w/out the need for much (any?) coding. This statement is in
comparison to hand crafting custom code to handle the various element types.
Additionally, rather than mixing up, and consequently mucking up, my XSDs by
forcing my annotation schemas to recognize the XHTML types directly and vice
versa, I am thinking that I could create a sort of intermediary document
which describes between XSD A and XSD B which types can intermingle with
each other (i.e., A.contentRepeater "makes sense" within a B.td). This for
some reason feels a bit wrong, however; once I begin doing this sort of
trickery, my end-product XML document becomes nothing but a big mess of
syntactically incorrect elements -- from XSD's point of view at least. But I
digress...
A number of problems crop up, however, in that some elements have no visual
appearance ("tr," for example), yet have interesting properties of their
own. As part of the look and feel, I have opted to use a similar approach to
that of [3]; each element has a number of properties (XML attributes) that
are directly editable and whose types are constrained by the XSD, and
children elements with the same features. Insertion points are available to
add new elements as children, using the XSD to determine what "makes sense"
as a child of the parent element of the insertion point. As one drills
deeper into the design, complexity arises from all over. Seeing a similar
approach, I hope, could alleviate some of these problems.
So, consider this my plea for advice, references, ...
Thanks in advance!
<joe/>
[1] http://www.parc.xerox.com/sparrow/
[2] http://www2.parc.com/istl/projects/sparrow/doc/www7/
[3] http://www5conf.inria.fr/fich_html/papers/P35/Overview.html
[4] http://www.w3c.org/2002/08/xhtml/xhtml1-strict.xsd
|
