#115947 - 2004-03-11 05:31 PM
Re: XML Support
|
Kdyer
KiX Supporter
Registered: 2001-01-03
Posts: 6241
Loc: Tigard, OR
|
Isn't XML just text? Or, am I missing your point?
Kent
|
Top
|
|
|
|
#115954 - 2004-04-05 05:53 PM
Re: XML Support
|
Chris S.
MM club member
Registered: 2002-03-18
Posts: 2368
Loc: Earth
|
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.
|
Top
|
|
|
|
#115958 - 2004-04-06 10:31 AM
Re: XML Support
|
Richard H.
Administrator
Registered: 2000-01-24
Posts: 4946
Loc: Leatherhead, Surrey, UK
|
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.
|
Top
|
|
|
|
#115959 - 2004-04-06 04:45 PM
Re: XML Support
|
jtokach
Seasoned Scripter
Registered: 2001-11-15
Posts: 513
Loc: PA, USA
|
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.
_________________________
-Jim
...the sort of general malaise that only the genius possess and the insane lament.
|
Top
|
|
|
|
#115960 - 2004-04-06 05:40 PM
Re: XML Support
|
Richard H.
Administrator
Registered: 2000-01-24
Posts: 4946
Loc: Leatherhead, Surrey, UK
|
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
|
Top
|
|
|
|
#115964 - 2004-09-28 03:39 AM
Re: XML Support
|
cj
MM club member
Registered: 2000-04-06
Posts: 1102
Loc: Brisbane, Australia
|
hehe, now here's a can of worms we should re-open
cj
p.s. ooh, only 9 more posts to the ton!
|
Top
|
|
|
|
#115966 - 2004-09-28 10:23 PM
Re: XML Support
|
Stevie
Starting to like KiXtart
Registered: 2002-01-09
Posts: 199
|
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.
_________________________
Stevie
|
Top
|
|
|
|
#115968 - 2004-09-29 10:10 AM
Re: XML Support
|
Richard H.
Administrator
Registered: 2000-01-24
Posts: 4946
Loc: Leatherhead, Surrey, UK
|
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
|
Top
|
|
|
|
#115970 - 2004-10-01 10:04 PM
Re: XML Support
|
NTDOC
Administrator
Registered: 2000-07-28
Posts: 11623
Loc: CA
|
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.
|
Top
|
|
|
|
#207641 - 2013-08-24 12:35 PM
Re: XML Support
[Re: NTDOC]
|
Jochen
KiX Supporter
Registered: 2000-03-17
Posts: 6380
Loc: Stuttgart, Germany
|
|
Top
|
|
|
|
Moderator: Lonkero, ShaneEP, Jochen, Radimus, Glenn Barnas, Allen, Ruud van Velsen, Mart
|
0 registered
and 507 anonymous users online.
|
|
|