Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > HTML > Fake XSL for HTML :)

Reply
Thread Tools

Fake XSL for HTML :)

 
 
The Doormouse
Guest
Posts: n/a
 
      04-20-2004
I have been searching for an XLST processor that is novice-friendly, and
came up with a really weird idea.

Here's my (possibly insane) idea:

What if there was an XLS processor that simply performed "find and
replace" on a grand scale? There would be no processor directives. There
would be no logical branching or DTDs or Schema or any of that - just a
list of tags and what they are suppossed to mean in real code (or
whatever the output should be). It would be the ultimate in user-
friendliness because it would be so easily used.

For example, my XML code would be:
<mytag>Content blah blah blah</mytag>
(No directives, declarations, nothing - just the tags)

My fake XSL code would be:
mytag
{
HTML/code/whatever
}
*and*
/mytag
{
HTML/code/whatever
}

My fake XLST processor would (of course) just spit out content direct.

I could use this fake stuff to build real XML and XSL files - and that's
scary. There would be no geeky learning curve. A ten-year-old could learn
it in minutes. All the standards/validating/etc is just thrown out the
window ...

I wonder if anyone would use it but me? Maybe it's already been written?

The Doormouse (The giggling insane?)

--
The Doormouse cannot be reached by e-mail without her permission.
 
Reply With Quote
 
 
 
 
Hywel
Guest
Posts: n/a
 
      04-20-2004
In article <Xns94D15BFF44CF8doormouseattnet@68.12.19.6>,
http://www.velocityreviews.com/forums/(E-Mail Removed) says...
> I have been searching for an XLST processor that is novice-friendly, and
> came up with a really weird idea.
>
> Here's my (possibly insane) idea:
>
> What if there was an XLS processor that simply performed "find and
> replace" on a grand scale? There would be no processor directives. There
> would be no logical branching or DTDs or Schema or any of that - just a
> list of tags and what they are suppossed to mean in real code (or
> whatever the output should be). It would be the ultimate in user-
> friendliness because it would be so easily used.
>
> For example, my XML code would be:
> <mytag>Content blah blah blah</mytag>
> (No directives, declarations, nothing - just the tags)
>
> My fake XSL code would be:
> mytag
> {
> HTML/code/whatever
> }
> *and*
> /mytag
> {
> HTML/code/whatever
> }
>
> My fake XLST processor would (of course) just spit out content direct.
>
> I could use this fake stuff to build real XML and XSL files - and that's
> scary.


Where's your real XSL file?


> There would be no geeky learning curve. A ten-year-old could learn
> it in minutes. All the standards/validating/etc is just thrown out the
> window ...


Rubbish. The idea's rubbish.

--
Hywel I do not eat quiche
http://kibo.org.uk/
http://kibo.org.uk/mfaq.php
 
Reply With Quote
 
 
 
 
David Christopher Weichert
Guest
Posts: n/a
 
      04-20-2004
On Tue, 20 Apr 2004 16:02:21 +0000 The Doormouse posted:

> I have been searching for an XLST processor that is novice-friendly, and
> came up with a really weird idea.
>
> Here's my (possibly insane) idea:
>
> What if there was an XLS processor that simply performed "find and
> replace" on a grand scale?


XSLT is more than find and replace otherwise you could just perform that
with any editor. Find and replace only work reasonably well if the
tree structure of the XML document and the resulting HTML document are
very similar if not identical. XSLT is a turing complete programming
language.

> There would be no processor directives.


Do you mean processing instructions? What's bad about them?

> There
> would be no logical branching or DTDs or Schema or any of that


How could I be sure of the grammatical correctness of the document
instances?

> - just a
> list of tags and what they are suppossed to mean in real code (or
> whatever the output should be). It would be the ultimate in user-
> friendliness because it would be so easily used.
>
> For example, my XML code would be:
> <mytag>Content blah blah blah</mytag>
> (No directives, declarations, nothing - just the tags)


What about proper nesting and having only one root element? Since you
suggested forgetting grammar (DTDs and Schema) why bother with tags at all?

> My fake XSL code would be:
> mytag
> {
> HTML/code/whatever
> }
> *and*
> /mytag
> {
> HTML/code/whatever
> }


Clearly your XSLT replacement suffers from the same defect as CSS, yet
another syntax. The beauty of XML, XSLT, XSL-FO and XML Schema is, that
they all have the *same* syntax, you can use all as a tool for the other.
An XML Schema is an XML instance, you can therefore write an XSLT
Stylesheet that will generate HTML documentation from the comments
(<xs:documentation/>) embedded in your XML Schema Grammar. All the XML
based languages and the respective tools work together much in the same
way Unix tools work together, you can 'pipe' the output of one into the
other and thereby create tool chains that allow mightier operations than
any so-called application software.

> My fake XLST processor would (of course) just spit out content direct.


So do not fake XSLT processors.

> I could use this fake stuff to build real XML and XSL files - and that's
> scary. There would be no geeky learning curve. A ten-year-old could learn
> it in minutes.


I seem to have completely not understood the point of your proposal. You
should consider shipping aforementioned ten-year-old with your software.

> All the standards/validating/etc is just thrown out the
> window ...


This makes me worry.

> I wonder if anyone would use it but me? Maybe it's already been written?


I wonder too.


Kind regards
David
 
Reply With Quote
 
Jeff Thies
Guest
Posts: n/a
 
      04-20-2004
> I have been searching for an XLST processor that is novice-friendly, and
> came up with a really weird idea.
>
> Here's my (possibly insane) idea:
>
> What if there was an XLS processor that simply performed "find and
> replace" on a grand scale? There would be no processor directives.


I read this entirely differently than the others who are concentrating on
the XSLT part.

Forget the XSLT for the moment. Think templates.

What you want is a template that you can mark up with your own syntax.

Say ::My Heading:: or ::Editable Block One::

It's not a complex thing to substitute editable content for that:

Simplified Example

http://thelimit.com/cgi-bin/page_editor/manager.cgi

username: admin
password: password

(That was actually designed for affiliates to clone sites)

Now, lets fake an XSL tag (forget XML):

<fakexsl:template match="testimonial" mode="data" />

Now what you have is a processing instruction. This particular one may tell
your "processor" to grab a testimonial routine and return the data from
that.

I find this to be a rather usefull abstraction. Templating with embeded
processing instructions. It enables you to make complex sites with a single
template (or templates) just by changing how the template is called.

I doubt there is any interest in this group, at least there wasn't last
time I asked.

Cheers,
Jeff


 
Reply With Quote
 
The Doormouse
Guest
Posts: n/a
 
      04-20-2004
"David Christopher Weichert" <(E-Mail Removed)> wrote:

> XSLT is more than find and replace otherwise you could just perform that
> with any editor. Find and replace only work reasonably well if the
> tree structure of the XML document and the resulting HTML document are
> very similar if not identical. XSLT is a turing complete programming
> language.


I have been thinking that what I really wanted all along was something
equivalent to a "mail merge" function.

XML, for my purpose, is hunting fleas with a hammer.

The Doormouse

--
The Doormouse cannot be reached by e-mail without her permission.
 
Reply With Quote
 
The Doormouse
Guest
Posts: n/a
 
      04-20-2004
"Jeff Thies" <(E-Mail Removed)> wrote:

> What you want is a template that you can mark up with your own syntax.
>
> Say ::My Heading:: or ::Editable Block One::


Thank you, Jeff. Yes, that was the idea!

=)

The Doormouse

--
The Doormouse cannot be reached by e-mail without her permission.
 
Reply With Quote
 
The Doormouse
Guest
Posts: n/a
 
      04-20-2004
Thank you! =)

The Doormouse

--
The Doormouse cannot be reached by e-mail without her permission.
 
Reply With Quote
 
David Christopher Weichert
Guest
Posts: n/a
 
      04-20-2004
On Tue, 20 Apr 2004 18:48:26 +0000 The Doormouse wrote:

> I have been thinking that what I really wanted all along was something
> equivalent to a "mail merge" function.
>
> XML, for my purpose, is hunting fleas with a hammer.


Although not a bad tool for the purpose. Consider this toolchain:

You have an XML file like this:

<!DOCTYPE letter "letter.dtd" [
<!ENTITY mrfoo SYSTEM "mrfoo.xml">
]>
<letter>
<to>&mrfoo;</to>
<content>
Your content goes here.
</content>
</letter>

You have another XML file called mrfoo.xml sitting in the same directory
(or whatever the system identifier states):

<contact>
<name>Mr. Foo</name>
<street>Foo Street</street>
<city>Bar</city>
</contact>

An XSLT Stylesheet transforming the whole thing could look like this:

<xsl:stylesheet version="1.0">
<xslutput method="html"
doctype-system="http://www.w3.org/TR/html4/loose.dtd"
doctype-public="-//W3C//DTD HTML 4.01 Transitional//EN"
encoding="ISO-8859-1" indent="yes"/>
<xsl:template match="letter">
<html>
<head>
<title>Letter to <xsl:value-of select="to/contact/name"/></title>
</head>
<body>
<p>To:<br/>
<xsl:value-of select="to/contact/name"/><br/> <xsl:value-of
select="to/contact/street"/><br/> <xsl:value-of
select="to/contact/city"/>
</p>
<p>Dear <xsl:value-of select="to/contact/name"/></p>
<p><xsl:value-of select="content"/></p>
</body>
</html>
</xsl:template>
</xsl:stylesheet>

Any good XSLT Processor, i.e. Saxon, will give you an HTML file like this:
result:
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>Letter to Mr. Foo</title>
</head>
<body>
<p>To:<br>
Mr. Foo<br>
Foo Street<br>
Bar</p>
<p>Dear Mr. Foo</p>
<p>Your content goes here.</p>
</body>
</html>

You see "mail merge" (or similar stuff) is very well possible with XSLT.
You can do XSLT Transformations serverside and clientside, depending on
the availability of a XSLT Processor on your server.


hth
David
 
Reply With Quote
 
The Doormouse
Guest
Posts: n/a
 
      04-21-2004
"David Christopher Weichert" <(E-Mail Removed)> wrote:

> You see "mail merge" (or similar stuff) is very well

possible with XSLT.

Yes, I see now.

It took me awhile to get an XSLT tool running on my machine.
XML is starting to make sense.

Thank you!

The Doormouse

--
The Doormouse cannot be reached by e-mail without her
permission.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
XSL: putting a XSL value inside an html attribute? Kourosh XML 6 05-17-2006 09:13 PM
XSL Question tp xsl:for-each and xsl:variable schaf@2wire.ch XML 1 05-27-2005 09:25 PM
XSL-1000: (Fatal Error) Error while parsing XSL file (org.apache.xerces.parsers.AbstractSAXParser$AttributesProxy) Kevin Flood Java 1 09-13-2004 02:28 PM
XSL-1000: (Fatal Error) Error while parsing XSL file (org.apache.xerces.parsers.AbstractSAXParser$AttributesProxy) Kevin Flood Java 0 09-08-2004 02:11 PM



Advertisments