Re: [MiNT] Svar:Re: HRD's & RSC's

[Paul Wratt <paul.wratt@gmail.com>]

On Wed, Jan 13, 2010 at 2:24 AM, Kåre Andersen <kareandersen@gmail.com> wrote:
> On Tue, Jan 12, 2010 at 3:51 PM, Paul Wratt <paul.wratt@gmail.com> wrote:
>> On Tue, Jan 12, 2010 at 10:31 PM,  <KareAndersen@gmail.com> wrote:
>>> Den 11. jan. 2010 22.09 skrev Paul Wratt <paul.wratt@gmail.com>:
>>> <snip>
>>>> Theoretically the resource source format could be defined as xml, or
>>>> specifically as html+css style, which would assist in making the
>>>> addition of scripting to HighWire a reality, even if the format were a
>>>> subset
>>>
>>>
>>> This caught my interest, so I googled a bit. Sounds like the BSDL describes
>>> the problem - http://www2002.org/CDROM/alternate/334/
>>> I don't think html+css would really work. You would need custom elements,
>>> and the meta tag is just evil. XML + XSL however, could.
>>>
>>>
>>>> That indicates that HighWire might be a good basis for a resource
>>>> designer, as it already has the basis for an interpreter, and that
>>>> resources in source form could then be previewed in any web browser,
>>>> which in itself would allow a lot more people to design for the
>>>> platform as a whole
>>>
>>> This I don't see... However, once a schema has been worked out, there are
>>> plenty of tools available to work with XML and XSLT.
>>>
>> All  HTML, XML, and there style counterparts are subsets of sgml.
>> Having cheaked Gentoo and WOW/BattleNet recently they are using xml.
>> It may be more useful to look at an engine that can handle these, like
>> a slim line WebKit, and get the html engine and js with it
>>
>
> Its like this: HTML can be defined in an XML schema (or rather, DTD).
> XHTML is done like this. But XML can be used to model anything -
> that's the whole point. You define your own tags and attributes. This
> is what you can not do in HTML.
>
> Personally I was using TinyXML a few years ago -
> http://www.grinninglizard.com/tinyxml/ for scripting demo code (not on
> Atari tho). Its fairly easy to get started with. There are plenty of
> other free software alternatives as well. A C rather than C++ based
> alternative is probably preferable (which, incidentally, reflects my
> current personal taste well... :)
>
>> xml to RSC as a definition would not be hard, even as HTML+css (even
>> if it is only as ascii, not rendered), however the trick is RSC as
>> binary
>
> This is where the BSDL comes in - as a syntactic device for storing
> binary data as markup, which then can be XSLT'ed into .RSC and .HRD
> files. Probably also the other way around (The BSDL document claims
> this is work in progress, but it seems to be about 8 years old).
>
>> The other point is that there neds to be some updating done on the
>> resource format, an extension at least, that can allow for a standard
>> set of AES objects and in particular 32bit color widgets. XaAES is
>> lacking in this department, and so anything new would help there
>> before any coding was done.. something that can easily be extended
>> into MyAES as well...
>
> Once you start expanding it you may as well replace it for "pure
> future" applications - and with the new computing power available (as
> in, faster than the 8mhz ST) parsing a bit of XML is fast enough to be
> used directly. So, defining a standard like this may actually have
> several uses.
>
>> BTW, as a temp solution, something like python could be used to do xml
>> and xsl to rsc binary... there is a new package available from Mikro
>> that works natively..
>
> Indeed, Python is probably a good tool for the job. As is C. It all
> depends on getting support from the developer community (yes guys,
> thats you!) . I would certainly volunteer work hours for this, but
> only if there is true interest.
>
> /Kaare
>

Python was only an example of having a command line to running within a week.

Kaare, if you are up to the task, your effort would be appreciated
immediately, as the are no current practical alternative to the
problem of RSC data in ascii form, that allows easy text based editing
also, and is extendable

Extensions to the resource format would also come quicker because of
this. I have already started this approach, but at documentation level
only, not at implementation level.

If what you say about TinyXML is true, then any development would have
beneficial result to of areas currently undeveloped, and combined with
an editor, there would be the immediate beginnings of a useful IDE and
rapid dev app

My work requires something like this, so i would be a supporter and
user of such tool. I would also provide any required documentation and
tutorials to help speed the process.

The same can be said of any one elses effort in this (and other
department), especially if an alternate source syntax approach was to
be taken (non-xml), as long as the tools are available and easily
integratable into a (user adjustable) cohesive IDE, multiple tools are
not an issue, as different people require different style to be
productive

The more support, the merrier all will be.

Paul