jtokach
(Seasoned Scripter)
2004-03-11 05:18 PM
XML Support

Not sure if this is practical, but I'll throw it out there. With .XML becoming more and more prevalent, wouldn't it be nice to have functions to manipulate .XML files like the functions we have to manipulate .INI files?

Kdyer
(KiX Supporter)
2004-03-11 05:31 PM
Re: XML Support

Isn't XML just text? Or, am I missing your point?

Kent


jtokach
(Seasoned Scripter)
2004-03-11 05:32 PM
Re: XML Support

So are .INI's, but we have several functions dedicated to manipulating them. The concept is identical.

Sealeopard
(KiX Master)
2004-03-11 05:40 PM
Re: XML Support

What's the problem with reading XML files? Functionality is already included in Kixtart via the COM interface. Just install the Microsoft XML Parser and read http://msdn.microsoft.com/library/default.asp?url=/library/en-us/xmlsdk30/htm/xmconxmldomuserguide.asp to get started.

jtokach
(Seasoned Scripter)
2004-03-11 05:45 PM
Re: XML Support

Thanks for the tip. I'll look into it and use this for now. I would still like to see some basic support for this integrated though.

Les
(KiX Master)
2004-03-11 07:11 PM
Re: XML Support

I agree. If we wanted to use COM for everything we could do it with VBS. Built-ins is what sets us apart.

cj
(MM club member)
2004-04-03 06:12 AM
Re: XML Support

But, building in EVERYTHING will just bloat the EXE with code that has to be carried around everywhere. The INI functions are just wrappers to API calls that AFAIK exist in Windows from 95 upwards. XML parsing would have to be either added directly for backwards support or contained in an external add-on which would be what we have right now anyway. I think KiXtarts power comes from it's small size and ability to use external add-ons.

my 2c, keep the change.

cj


jtokach
(Seasoned Scripter)
2004-04-05 05:16 PM
Re: XML Support

I'm not disagreeing with the bloat factor. Assuming .XML could replace .INI files, the INI manipulation code in KiX could be deprecated and replaced with the more modern standard of .XML manipulation code. How else is KiX supposed to seperate itself from the pack and modernize itself without growing in size and functionality?

Chris S.
(MM club member)
2004-04-05 05:53 PM
Re: XML Support

Quote:

How else is KiX supposed to seperate itself from the pack and modernize itself without growing in size and functionality?




...as far as XML support goes? I'd say by utilizing the COM functions that other scripting/programming languages use. I can't think of any languages that natively support XML now.

Here is an example of using the XMLDOM...

Code:

Break On

$xml = '
<remoteDir>
<dir>1394</dir>
<dir>backoffice</dir>
<dir>Clients</dir>
<dir>distapps</dir>
<dir>exchange</dir>
<dir>GEN_INFO</dir>
<dir>IIS</dir>
<dir>lanman</dir>
<dir>mail</dir>
<dir>mcis</dir>
<dir>mspress</dir>
<file>
<name>readme.txt</name>
<size>1715</size>
<lastModTime m="5" d="20" y="1996" hh="0" mm="0" ss="0" />
</file>
<file>
<name>ReadMe1.txt</name>
<size>2107</size>
<lastModTime m="7" d="2" y="2002" hh="0" mm="0" ss="0" />
</file>
<dir>sitesrv</dir>
<dir>sql</dir>
<dir>Sysmgrsrv</dir>
<dir>utilities</dir>
<dir>viper</dir>
<dir>winnt</dir>
<dir>WinSock</dir>
</remoteDir>'

$xmlDoc=CreateObject("Microsoft.XMLDOM")
$xmlDoc.async="false"

If $xmlDoc.loadXML($xml)
For Each $x in $xmlDoc.getElementsByTagName("dir")
$x.nodename + ": " + $x.text ?
Next
For Each $x in $xmlDoc.getElementsByTagName("file")
$x.nodename + ": " + $x.childNodes(0).text + " | " + $x.childNodes(1).text + " | " +
$x.childNodes(2).getAttribute("y")+"/"+$x.childNodes(2).getAttribute("m")+"/"+
$x.childNodes(2).getAttribute("d") ?
Next
EndIf



By the way, a very good online tutorial of XMLDOM can be found at W3Schools.


jtokach
(Seasoned Scripter)
2004-04-05 06:12 PM
Re: XML Support

You just can't keep playing that card. "What seperates KiX from the pack?" The ability to call COM objects to handle every task (eehhmm VBScript) or the builtin functionality not found in other languages? It doesn't have to be support for .XML, but it has to be something.

And getting back to bloat; back in the days when we all using P100/16MB that argument was valid. Desktops are rolling off the line at +4GHz/1GB 64bit hyperthreaded blah blah blah. These boxes can consume a 1MB command line exe in the blink of an eye. The same goes for bandwidth. Practically all of our telecommuters are highspeed. This argument just doesn't hold water anymore.


NTDOCAdministrator
(KiX Master)
2004-04-05 10:15 PM
Re: XML Support

bandwidth alone I would disagree with you.

It may be nice and great that you work at a Company that can afford that speed, but there are many Companies around that can not.

Going bloatware should ALWAYS be on the minds of programmers. I gurantee you that if MS didn't have to put in a TON of code to make sure the average user didn't accidentally do something wrong in the OS, it would be much smaller and faster then it currently is. Much of the bloatware of Windows is to protect the user from him or herself.

That does not mean that I disagree with you on functionality improvements in KiX. If Ruud can add such and still keep the EXE a reasonable size, great.


jtokach
(Seasoned Scripter)
2004-04-05 10:39 PM
Re: XML Support

In most cases the company doesn't pick up the cost for our user's highspeed home ISP connections. Still, we haven't changed our practices, we run KiX locally from the workstation so back to the original statement that a larger .EXE would have little impact on a fast computer.

I think we all agree that we want improvements at little cost to performance. I see .XML support as a direct replacement for older technology.


Richard H.Administrator
(KiX Supporter)
2004-04-06 10:31 AM
Re: XML Support

More importantly on this and similar issues is where it makes sense for the support of things like XML to be.

As you quite rightly pointed out, KiXtart can interface with COM automation quite successfully with a couple of notable exceptions.

This has two major benefits. Firstly, there only needs to be one implementation for the support of a feature.

If you take XML as an example, would you expect the coders of Word, Excel, Internet Explorer and so-on to write their own XML parsers and handlers? Of course not, it would be mad. Instead a library is developed, the API is published and any application which needs XML parsing uses the library.

The second major benefit of doing this ways is about who maintains the code. Is it really a good idea for Ruud to have to add massive complexity to KiXtart for something which is at present of limited need just to make the interface simpler? Something that he may well not have expert knowledge in.

No. It is much better for the XML experts to maintain, bug-fix and enhance the XML support libraries.

Ruuds time is better spent developing the core of KiXtart and adding features which enhance the scripting language, rather than adding functionality which is already available.

As a guide, I usually review enhancement requests and fit them into loose categories:
  • Very Good This is something which would benefit most people, but more importantly is it something which can only be achieved by a change in the scripting language. Some examples are static variables, pass by reference, input/output redirection and support for binary data.
  • Good Again, most people would benefit. These are requests which would provide support for facilities which can already be handled by UDFs and COM but should probably be part of the core language. Things like mathematical functions, date handling, pattern matching, associative (hash) arrays.
  • Not so good This category is for those things which don't really belong in KiXtart. It may be because they are so esoteric that very few people will use the feature. More often it is because the feature is available by another method such as via the COM automation and it is appropriate for it to remain that way. Examples of this are network (socket) programming, HTTP, Email, database and LDAP.


Not everyone will agree with me, but I think that XML support sits quite firmly in the last category.


jtokach
(Seasoned Scripter)
2004-04-06 04:45 PM
Re: XML Support

Richard, what you say makes great sense and couldn't agree with you more. Where we disagree is with the categorization of extended functionality such as XML. And quite honestly I think the community takes this Suggestions forum far too seriously, such as to assume that every suggestion should be included in the next release. XML is growing in popularity at an immense rate. By making the suggestion that this should be included, I’m suggestion it would be nice to see it in the future; preferably within a year.

Given the way you designated XML support to be non-value added would be stating that Ruud’s decision to include support for .INI parsing was also non-value added and more of a nicety. Personally, I can remember times where not having such functionality would have made my life a whole lot more difficult and I’m certain that I’m not alone here.

If KiXtart is a tool designed for administrators, (read: not programmers) and its development path remains focused on that philosophy, and XML will replace the current methods in which applications operate, would it not make better sense to have native support for this built into the language so the administrator can quickly accomplish his task? We’re talking about minutes of referencing the manual as opposed to a few hours deciphering the COM interface.

And finally, regarding Ruud’s time, I agree with you. I’d much rather have a completely working COM interface than support for .XML right now. I merely came to offer a suggestion.


Richard H.Administrator
(KiX Supporter)
2004-04-06 05:40 PM
Re: XML Support

Without delving into ancient history INI support is an early feature when KiXtart was a simple login scripting language.

COM automation has developed in later version of KiXtart as it has progressed - it wasn't available in early versions.

It is not that XML support has no value per se, it is simply that building XML support into KiXtart has little added value at the expense of making KiXtart bigger, slower and more difficult to maintain. IMO simply adding API wrappers to KiXtart is just not a very good reason.

Suggestions here get debated by the community and distilled to something which is in a form that can be put forward to Ruud. This peer review process is vital to ensure that the request is beneficial to the community as a whole and is at it's clearest and most concise - the more noise there is around a suggestion the more likely it is to be heard



jtokach
(Seasoned Scripter)
2004-04-06 05:51 PM
Re: XML Support

My wife says I'm pretty noisy. =)

All things considered, I still feel this addition will become worthy as XML grows in popularity and administrators demand simpler methods to maintain them. Think visionary.

Ruud, if you build it they will come.


LonkeroAdministrator
(KiX Master Guru)
2004-04-07 08:29 PM
Re: XML Support

now...
who needs XML anyways?
it's not really needed anywhere and is used just for the hype of it.
the same sillyness that drives tele-communication companies to third generation mobile-networks.
why don't ppl learn.
and to take more precise example, I take java.
nobody really needs that bloody language but for the hype of it, it is teached everywhere!


Jose
(Seasoned Scripter)
2004-09-27 07:13 AM
Re: XML Support

I agree with jtokach about the XML new standard, in my opinion Kixtart should read and write XML easily without COM just like ini files.

By now I will use XMLDOM.


cj
(MM club member)
2004-09-28 03:39 AM
Re: XML Support

hehe, now here's a can of worms we should re-open

cj

p.s. ooh, only 9 more posts to the ton!


Sealeopard
(KiX Master)
2004-09-28 03:53 AM
Re: XML Support

I don't know why everybody is so obsessed with XML files. They're essentially the noisy decendant of COBOL copybooks.

If i'd have to deal with XML versions of the flat files I'm dealing with right now I'd have to read 10GB XML files instead of 1GB flat fixed-length files.


Stevie
(Starting to like KiXtart)
2004-09-28 10:23 PM
Re: XML Support

Though I know this is an old thread, I'm just stumbling across it now that it has been freshly revived.

If bloat is the driving force behind what is included and what is excluded, then the drive mapping, printer mapping, program group, file and file management, ini and registry functions should all be removed as they are all available via external means--either through COM manipulation, or internal/external batch functions. Removing all of these redundant functions will result in an even smaller version of the .exe and a much more streamlined app. However...

If I wanted to use a language that just provided the mechanism to access these functions without providing any real added value itself, I'd just go ahead and focus on VBScript. The beauty of KiX (at least for me) is that if I want to map a drive, or modify some element of the users environment, or do some file manipulations, it's all available to me in the core language. In VBScript you can't even get an environment variable without the WshEnvironment object!!

The fact that these things are in the core language makes it easier to work with, easier for up-and-coming scripters to get their heads around and in short, easier to be more productive. Removing functionality because it already exists in other libraries or refusing to add additional functionality for the same reason just kills the thing that KiX has always had over other script languages.

For me, if the make-or-break issue was the size of the kix executable, and I was on a network where a 5, 10, or 50K increase in the size of this file would have a cataclysmic impact, then I'd probably avoid KiXtart altogether and focus on a different technology.

But it's precisely because the language itself natively contains real value to the scripting community that it really shines over its peers, not because we're able to shave another 5K off the exe size.

Of course, I agree that functionality can't be added ad hoc, but each new inclusion should be well thought out and be deserved. XML as a data format is not going away and its usage will only increase with time. For the same reason that the INI format is supported (because it makes sense, not because it was written before COM interoperability) I feel that XML should be supported as well, so that KiXtart can maintain that sense of dominance over other languages that are nowhere near as feature rich.


Les
(KiX Master)
2004-09-28 10:44 PM
Re: XML Support

...and just maybe Ruud could create the MakeEXE I suggested and strip the executable down to the leanest, meanest runtime that would make room for just a little bloat.

Richard H.Administrator
(KiX Supporter)
2004-09-29 10:10 AM
Re: XML Support

We already have an extensible method of adding functionality to KiXtart as needed - User Defined Functions.

As an example there is no specific ODBC or SQL support built in to KiXtart, but if you browse the UDF forum you will find a number of functions which abstract the code needed to provide the features as simplified APIs.

So why not have an XML document UDF library to manage XML files?

It's entirely possible that I've missed some fundamental reason why support cannot be provided this way and must be built in to the language.

Maybe one of the XML proponents could take this a bit further with a definition of what support is required. Features that cannot be supported with existing KiXtart functionality would be especially interesting.

Has anyone played with the Microsoft XML SDKs in KiXtart?
More information here


Stevie
(Starting to like KiXtart)
2004-09-29 07:05 PM
Re: XML Support

You're absolutely correct in that UDFs can be created to provide a feature complete XML wrapper. I think the disconnect may be in what is meant by "XML support." I agree that KiXtart does not, and should not, contain functions that provide access to the complete XML Document Object Model (XMLDOM). The XMLDOM is too large with too many functions, many of which would be largely untouched.

My only point was that it would definitely be a good thing to have a couple of internal kix functions that return node text data and also attribute data:
GetXMLText(file, node)
GetXMLAttribute(file, node, attribute)

(With corresponding Set functions)

Just a couple of functions to make it as easy to access XML data as it to access ini or registry data now.


NTDOCAdministrator
(KiX Master)
2004-10-01 10:04 PM
Re: XML Support

Just FYI material

Quote:

MSXML 6.0 SDK
What is MSXML?
Microsoft® XML Core Services (MSXML) 6.0 allows customers to build high-performance XML-based applications that provide a high degree of interoperability with other applications that adhere to the XML 1.0 standard.

Among the core services MSXML 6.0 provides is developer support for the following:

The Document Object Model (DOM), a standard library of application programming interfaces (APIs) for accessing XML documents.
The XML Schema definition language (XSD), a current W3C standard for using XML to create XML Schemas. XML Schemas can be used to validate other XML documents.
The Schema Object Model (SOM), an additional set of APIs for accessing XML Schema documents programmatically.
Extensible Stylesheet Language Transformations (XSLT) 1.0, a current W3C XML style sheet language standard. XSLT is recommended for transforming XML documents.
The XML Path Language (XPath) 1.0, a current W3C XML standard used by XSLT and other XML programming vocabularies to query and filter data stored in XML documents.
The Simple API for XML (SAX), a programmatic alternative to DOM-based processing.





Jose
(Seasoned Scripter)
2004-10-01 11:24 PM
Re: XML Support

Very good idea guys about an UDF for XML format. I can tell XMLDOM needs some reading, understanding and practice in order to achieve some results and not all of us have the time or skill to do it. An UDF would be nice definitely!!.
BTW ...nice tutorial reference.


JochenAdministrator
(KiX Supporter)
2013-08-23 02:15 PM
Re: XML Support

While this thread is now round about 9 years old and the last posted link is reported as an attack page in FF meanwhile m(

XML has become a quasi 'industrial' standard .. should we reopen this can of worms as Chris and/or Les stated, or should we take the challenge and build some udfs for more than the standards of 1999 to work?


AllenAdministrator
(KiX Supporter)
2013-08-23 04:50 PM
Re: XML Support

I certainly think having a good set of XML udfs would be beneficial, but... I think the amount of work required to get all that going is going to be tough. I tend to be willing to work on UDFs when I have a direct use for them. But in this case, in all my years of scripting, I think XML code has been needed like 2 or 3 times, and none of those instances were of the Work/Critical type.

NTDOCAdministrator
(KiX Master)
2013-08-24 11:45 AM
Re: XML Support

Would tend to agree with Allen. Have had 0 need to create, add, modify an XML file via script ever.

Curious what your need is Jochen. Maybe something I'm just overlooking.


JochenAdministrator
(KiX Supporter)
2013-08-24 12:35 PM
Re: XML Support

see thread in mods forum Ron ;\)
Problem atm is complex xml and XSD schemas .. I will have to cobble something, but as said there: in case of time's running out I'll write that things out with ADODB.stream(s*)

* depending on the need of BOM or not BOM

[edit: I would be satisfied when the things I start with don't just read and write but rebuild the ease of using read/writeprofilestring \:D ]

[edit2: The things you could do with this are beyond being useful ... but agreed: There will be work to do! Culprit with these standards is that everyone wants to make a quick $ whitit .. even those simple and free xml editors there were in the start/mid 0's are now available only for $$$]