#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: 11624
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
|
1 registered
(mole)
and 405 anonymous users online.
|
|
|
]
