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

Re: Bag of ideas and breaking the formatting-structure barrier

• From: "James Fuller" <james.fuller.2007@g...>
• To: "Brett Zamir" <brettz9@y...>
• Date: Mon, 11 Jun 2007 14:29:33 +0200

as an aside, u could just opt to use xinclude....e.g. some xml parsers
have an xinclude processor built in and use xpointer to extract a
portion of the document (xsltproc has xinclude processing and  Xalan
can do this if u enable xerces xinclude processing).

the key thing to remember is that xinclude processing occurs during xml parsing.

gl, Jim Fuller

On 6/10/07, Brett Zamir <brettz9@y...> wrote:
> Hello,
>
> (My apologies if the following is already being worked on, but I haven't
> heard about it if it is...)
>
> Even beginners to XML+styling/XHTML, especially those who are familiar
> with HTML, are turned off by the duplication of work needed to separate
> one's formatting from one's structure. The benefits to doing such
> separation are well-known, but it does come at a cost. Not only must one
> repeat information in order to cross-reference one document to another,
> but it can also a little bit harder to read one's own documents, if
> styling is important, when the styling is separated (at least if you're
> like me and likes to see all of the information right there together).
> Many times, we want to write XHTML/XML in a way which is simply like a
> brain dump—sticky note programs, for example, don't expect us to have
> our formatting separated while we dump our ideas. Why not devise systems
> that lets us be sloppy in our document creation process, but which
> predictably cleans it up for us (especially but not exclusively for
> those without server-side skills), whether within XML editing tools,
> server-side programs, or even more universally (though in some ways less
> efficient), server modules?
>
> I was wondering about the potential for making an equivalent for
> XInclude (maybe "XPort"?) which allowed for XML content (including XML
> content containing CDATA such as CSS or scripting text but also
> elements) to be extracted from a document and appended to another
> document (with attributes indicating any desired sequencing). This would
> avoid the need for processing instructions targeting server-side
> programming and could work both with XML editing software—which might
> allow one to extract and remove all such elements and reassemble them
> into a new file—as well as by server-side software and ideally
> optionally, by the server itself and possibly in combination with the
> client (similar to Server-Side Includes, but without the use of comments
> and more like what we might call "Server-Side Excludes" whereby Xpath
> could either process all Xport statements or, if a header is sent by the
> client browser to it that it has already cached its Xport contents, be
> used to find and remove all Xport statements before serving them (to cut
> down on bandwidth as well as cluttering information)—to take advantage
> of increased network speed at "separating" (or more like
> cut-and-pasting) formatting from content).
>
> These Xport statements could have their own target (temporary and
> domain-specific) file names—although I suppose they would probably need
> to be severely limited to certain filetypes like CSS or XSL, unless the
> fact of their privileges (e.g., for Javascript) being limited as with
> other remote content, could be well-understood by the system for
> security reasons. The target names would be generated by the receiving
> browser as temporary files (with some limits on the number of unique
> files that the browser would be willing to create for avoiding malicious
> servers locking up people's browsers by forcing them to do lots of file
> writing). While processing instructions could conceivably be used
> instead, I think XML would allow XML editors to better preserve
> coloring, etc. by allowing genuine child tags, rather than allowing XML
> content within processing instructions, for example.
>
> <xp:moveto href="newfile1.css">
> p.toc {color:red;}
> div.header {background-color:blue;}
> </xp:moveto>
>
> Now, if XSL could include these statements, a document which combined
> style attributes or elements, for example, could be transformed with the
> styles shuffled off by the server software to a separate file while the
> main document was returned without the style information. One might even
> package XSL data and CSS data within one file which could be exported
> and then referenced for transformation by the same document (perhaps
> even as an attribute of the xp:moveto statement rather than requiring a
> new xml-stylesheet processing instruction).
>
> This approach might also use attributes which would later be stripped
> but which could utilize the current element's information.
>
> For example,
>
> <p id="mypar1" istyle="font-weight:bold;">
>
> creates
>
> #mypar1 {font-weight:bold;}
>
> <div class="toc " eclstyle="color:orange;">
>
> div.toc {color:orange;}
>
> These attributes will be stripped but not before being transformed into
> a CSS statement which uses the current element's id, element name,
> and/or class, as a selector. If a class or id is called for by the
> attribute type used but no class or id exists on the element, one could
> be auto-generated. This allows a person, just as one may introduce a new
> abbreviation at the top of one's document, to use a style again later
> but without needing to initially write it globally or in an external file.
>
> I realize that one could simply use XSL stylesheets to do the above, but
> the point here would be to be able to do it without converting one's
> document ahead of time or using server-side programming.
>
> A few other different but related ideas...
>
> Perhaps http headers could be made to support requests to the server to
> perform the transformation before sending.
>
> Maybe processing instructions could instruct an XSL engine to first
> transform on the server-side.
>
>
> If anybody is more curious about this approach, I used it (but not with
> XML, though it can be used to generate XML) in a plugin for the Smarty
> templating system that I made (based on someone else's plugin,
> SmartyDoc), and called it simply SmartyDocB:
> https://sourceforge.net/projects/smartydocb
> http://smartydocb.sourceforge.net/docs/documentation.xml
>
> I can only think that such developments--while perhaps being looked down
> upon by purists who think documents should even be originally written
> with style separated from content, might hold more promise in weaning
> people away from HTML or transitional XHTML without so much of the pain.
>
> I'd be eager to know if such approaches already exist or not, people's
> opinions, etc.
>
> thanks and best wishes,
> Brett
>
> _______________________________________________________________________
>
> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
> to support XML implementation and development. To minimize
> spam in the archives, you must subscribe before posting.
>
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Or unsubscribe: xml-dev-unsubscribe@l...
> subscribe: xml-dev-subscribe@l...
> List archive: http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>
>

• Follow-Ups:
  • Re: Bag of ideas and breaking the formatting-structurebarrier
    • From: Brett Zamir <brettz9@y...>
  • Re: Bag of ideas and breaking the formatting-structurebarrier
    • From: Philippe Poulard <Philippe.Poulard@s...>

• References:
  • Bag of ideas and breaking the formatting-structure barrier
    • From: Brett Zamir <brettz9@y...>