Fake XSL for HTML :)

T

The Doormouse

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?)
 
H

Hywel

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.
 
D

David Christopher Weichert

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
 
J

Jeff Thies

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
 
T

The Doormouse

David Christopher Weichert said:
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
 
T

The Doormouse

Jeff Thies said:
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
 
D

David Christopher Weichert

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">
<xsl:eek:utput 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
 
T

The Doormouse

David Christopher Weichert said:
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
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top