[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
Re: [xml-dev] Bag of ideas and breaking the formatting-structurebarrier
- From: Brett Zamir <brettz9@yahoo.com>
- To: xml-dev@lists.xml.org
- Date: Tue, 12 Jun 2007 13:50:16 +0800
Hello,
Thanks for your response. But while your suggestion might work to move
items into say the style element of an XHTML document, wouldn't the
original elements still be within the document? And I don't think this
cuold offer the option of getting the styling (or scripting, etc.)
content moved to an external file--in order to take advantage of the
benefits of a complete separation of formatting from structure.
Here's a more complete example to give an idea of what I was talking about.
(I changed the attributes to follow a new namespace (with the "css"
prefix, distinguishing it from those targeted to the document's <style>
element--an XPointer could also be used here also to target a specific
position in the target document, including if it were the same document
as well as with the "xp" prefix for exporting entire blocks of text at
once rather than a portion of the current element.)
( If the css:target and xp:target attributes are left out in the
following, the server/client will simply devise its own unique name for
the external file perhaps relying on the current directory and filename
-- While this would separate the content for that file, the disadvantage
of this is that other XHTML files could not as easily target its
stylesheet for export -- e.g., to make a site-wide CSS file; the below
approach using the target attributes could more easily do it, however. )
HTML file named mydoc.html :
<html xmlns="http://www.w3.org/1999/xhtml"; xmlns:css="whateveritmaybe"
css:target="mytemp1.css" xmlns:xp="whateveritmaybe" xp:target="mytemp1.css">
<h1 id="mypar1" css:i="color:red;"> Write Sloppy, Code Pretty </h1>
<p css:i="font-style:italic;"> A new approach to styling XHTML/XML </p>
<!-- Maybe even the classes below could be auto-detected and generated
by the presence of css:ecl (which stands for element and class as it
will use both the element's name and class to create a selector--in this
case, "p.toc") -->
<p class="toc" css:ecl="font-weight:bold;"> Foreword </p>
<p class="toc"> Introduction</p>
...
<!-- Besides the above inline options, one could also export in a block -->
<xp:moveto href="newfile1.css" priority="0.3">
p.toc {color:gray;}
div.body {background-color:blue;}
</xp:moveto>
<div class="body">Here's what we will take about... </div>
creates the following XHTML 1.1, with formatting entirely shuffled off:
<h1 id="mypar1"> Write Sloppy, Code Pretty </h1>
<p id="autogeneratedid1"> A new approach to styling XHTML/XML </p>
<!-- Maybe even the classes below could be auto-detected and generated
by the presence of css:cl -->
<p class="toc"> Foreword </p>
<p class="toc"> Introduction</p>
...
<div class="body">Here's what we will take about... </div>
and creates an external CSS stylesheet (named mydomain.com_mytemp1.css
or the like if cached by the browser--file-writing I think could take
place either on the server or as new and temporary but cached files in
the browser, though if done by the server one would have to manually
visit all files targeted to a given CSS page in order to create it fully
for the user):
/* Begin auto-gen: mydomain.com/mydoc.html */
/* Priority: 0.3 */
p.toc {color:gray;}
div.body {background-color:blue;}
/* End auto-gen: mydomain.com/mydoc.html */
/* Begin auto-gen: mydomain.com/mydoc.html */
/* Priority: undefined */
#mypar1 {color:red;}
#autogeneratedid1 {font-style:italic;}
p.toc {font-weight:bold;}
/* End auto-gen: mydomain.com/mydoc.html */
This external stylesheet would be created either by:
1) XML editing software familiar with how to handle these
namespaces--whatever they would be (in which case the original code
could optionally be converted by the program entirely into the above
separated code)
2) by server software programmed to make such conversions (I know this
is possible right now, but it is not ideal due to the extra work involved)
3) by the client browser alone (this would achieve the separation, but
wouldn't take advantage of browser caching)
4) by the server in connection with the client (this would be ideal as
it avoid the need for special editing software or user-programmed
server-side software and takes advantage of browser caching-- the server
would automatically remove its style contents from the XML document
before serving it up if the client browser were sending the right header
indicating it didn't need the style contents).
While XSL could also be exported in this fashion (the blocks would need
to be targeted between an XSL document's <xsl:stylesheet> tags), I think
it would probably be more often used for CSS (though I could be wrong).
Remember, the point of all of this is that it allows one to write
quickly and sloppily yet get good resultant separated code. In other
words, one will have no need to organize ahead of time (or to write
sloppily and then do the work of moving things around and of manually
saving an external stylesheet, duplicating the reference information
(e.g., "p.toc"), etc.); one can simply write sloppily and quickly (with
formatting mixed inline (via css:i, css:cl, css:ecl, css:e, etc.
depending on the desired separator) or within xp:moveto blocks), but
have all of the separation performed by the client working with the
server (or the editing program). If one has to tweak ordering later
(e.g., due to several such XHTML files targeting the same stylesheet for
export and having a cascading conflict), just assign a priority attribute.
best wishes,
Brett
James Fuller wrote:
> 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@yahoo.com> 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@lists.xml.org
>> subscribe: xml-dev-subscribe@lists.xml.org
>> List archive: http://lists.xml.org/archives/xml-dev/
>> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>>
>>
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
