I think I got it straightened out. The type scripts handle the batch file
formats, being .frm/.fld/.mnu/.smn, for multi-source appliance. The subtype
scripts handle the attributes with respect to types. The 'link' type script
redirects link paths to the user agent. So CML script updates on browsers is
what is needed to implement CML.Jacob
On Thursday, October 6, 2016 9:42 AM, Jacob Villarreal <jv1...@yahoo.com>
wrote:
I find it somewhat strange that we are not able to synch up on this proposal.
It's kind of funny, but there isn't much to these new tags I mentioned.
They're used like any regular html tags, like <form
action="action_page.php"></form>, for example, but <source
form:[path]/action_page.php:coord>. So the source tag would retrieve the
action_page.php file by means of the source path, and render it at the pixel
coordinate specified, on the web page. So there are only two main tags for the
whole CML language, being <source>, and <destination>, and one subtype tag,
being <attribute>. So the attributes within source/destination perform
retrieval/storage operations, while the attribute tag performs attribute
operations with respect to the type attribute found in the source/destination
tags. So the attribute tag is always used in connection with either the
source, or the destination tags individually. As far as CSS, and Javascript
coding, it's much more antiquated than the formatting/scripting possibilities
that CML presents. Static formatting on multiple pages, like what CSS does,
can be done more efficiently, by applying one simple line of code to all of the
targeted content on the page. For example:
<destination css><source [type]:[path]:Null><destination
css:[path]/css_settings.css>
This would send all of the settings for the objects between the destination
tags to a single file for appliance of those settings on other pages, with only
two simple lines of code. That's alot more efficient than html, and CSS.
It's not a big deal, seriously, you don't have to worry about it. It was just
something I came up with after having been agitated by the trouble I had with
html. I couldn't get anything to work. That's why I would like to get these
tags implemented, so I can get started doing much more than what html, CSS, and
JavaScript have to offer.
Thanks,Jacob
On Thursday, October 6, 2016 9:14 AM, Jacob Villarreal <jv1...@yahoo.com>
wrote:
Roger,You wrote:How is this any different from PHP, ASP, JSP, .Net,
ColdFusion, etc? You could implement your CML on the backend and have it
'output' XML/HTML+JavaScript+CSS for delivery to user agents with compatibility
with everything out there today.
In response:I've tried a little bit of PHP, and just seen some samples of ASP,
JSP, and ColdFusion. But in case you didn't notice CML only consists of two
tags. Compare that to PHP, which is very similar to C+ programming language.
I'm not sure if you were complementing or what, but it's true CML would be
compatible with pretty much anything out there, including
XML/HTML+JavaScript+CSS. In fact, CSS is accomplished by simply appending
different sources to be rendered on the page in a layered format. As for
example:
line 1: <source form:[path]:coord>+line 2: <source form:[path]:coord>+
line 3: <source form:[path]:coord>
Tabs would be image objects with linkage to lines within a single cascade
record. I know you think it sounds like batch programming, but it's really not
any different from standard html, in that respect, other than the simplicity,
and scalability.
You wrote:If you want to try to replace HTML, JavaScript, and CSS so that every
user agent needs to understand CML natively - that's just not going to happen.
In response:Very funny, but CML is so simple, it would only take you around
5-10 minutes to learn it completely.
You wrote:There are many server-side options and it really sounds like that's
where CML would fit. Your developers would write in CML, and the 'engine'
would render that into the appropriate content for delivery to UAs.
In response:I don't know why everyone keeps referring to server-side
infrastructure in response to CML. When you access html files located on an
Microsoft IIS server, you access folders located either on the server, or on a
remote server/database. CML would access the .frm/.mnu files, for example from
the same server's folders, or from a remote server/database. The difference is
in the backend, being on the unix side, I believe, which runs the scripts for
html. So I was wondering if the browsers translate the html code, or if the
internet servers require a script update with the appropriate implementations
to run on the .frm/.mnu file extensions in order to apply the rules with
respect to line text in those files.
So I don't think we're synched up with it too well. I guess I would like to
know whether the browser's code applies the html, or if the internet servers
handle the translation for rendering of site content onto the web page. If the
server side handles the processing of html code, it might require a new
protocol, or internet information server script. If the browsers handle the
processing of html code, then the browsers would need the update to be able to
run CML. I just thought it would require an entirely new specification in
order to implement it for the general public.
You wrote:
Personally I don't see value in this proposal.
In response:I'm confident that CML would replace html entirely, though, by
popular franchise, haha. I'm beginning to get the idea that I would have to
develop my own open source website, and driver/script update for browsers, like
with Flash updates.
Didn't mean to take up too much of your time.
Thanks anyway,Jacob
On Thursday, October 6, 2016 8:02 AM, Roger Hågensen
<rh_wha...@skuldwyrm.no> wrote:
On 2016-10-06 14:15, MegaZone wrote:
> How is this any different from PHP, ASP, JSP, .Net, ColdFusion, etc? You
> could implement your CML on the backend and have it 'output'
> XML/HTML+JavaScript+CSS for delivery to user agents with compatibility with
> everything out there today.
>...
> There are many server-side options and it really sounds like that's where
> CML would fit. Your developers would write in CML, and the 'engine' would
> render that into the appropriate content for delivery to UAs.
Yeah! For example, I'm working on a offline CMS that actually uses
include/declaration files for all the components of a static site. The
CMS will grab all that apply templates and "render" the finished html,
PHP is actually used to power this CMS.
> Personally I don't see value in this proposal.
I have to agree, I almost feel like I'm being trolled at this point.
Unless a post or a "diagram" shows up that makes me go "Ah! Now I see!"
I'm not going to bother responding to any further posts on this subject.
--
Roger Hågensen, Freelancer, http://skuldwyrm.no/
