[ANN] STS XML Library 2.0.4 Released
A minor upgrade to the STS XML Library (2.0.4) was released today that fixed a few bugs, including a defect in the stsXML_DeleteNode command that would cause problems when deleting the last child node of a parent node. Additionally, a new version of the RSS Plugin (1.0.2) that fixed a few bugs related to the use of the Workshop utility inside the RSS Plugin user interface is also available. For more information, see: http://www.sonsothunder.com/products/xmllib/xmllib.htm Thanks! Ken Ray Sons of Thunder Software, Inc. Email: [EMAIL PROTECTED] Web Site: http://www.sonsothunder.com/ ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
[ANN] STS XML Library Version 2.0.3 Now Available
Version 2.0.3 of the STS XML Library is now available, and fixes a few bugs that were found in the previous version. For more information on what was fixed, please visit: http://www.sonsothunder.com/products/xmllib/xmllib_versionhistory.htm And if you don't know about the STS XML Library, you can take a look at what it does and how it compares with Revolution's XML DLL here: http://www.sonsothunder.com/products/xmllib/xmllib.htm Regards, Ken Ray Sons of Thunder Software Web site: http://www.sonsothunder.com/ Email: [EMAIL PROTECTED] ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
[ANN] STS XML Library 2.0.2 Available
Just a quick note to let you all know that I have posted version 2.0.2 of the STS XML Library at my web site which fixes a couple of small handful of bugs and provides an enhancement to stsXML_GetNodeData to get access to embedded CDATA. For a complete breakdown on what changed, see the Version History page at: http://www.sonsothunder.com/products/xmllib/xmllib_versionhistory.htm For information on the XML Library itself, please see the main page at: http://www.sonsothunder.com/products/xmllib/xmllib.htm Thanks! Ken Ray Sons of Thunder Software Web site: http://www.sonsothunder.com/ Email: [EMAIL PROTECTED] ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
[ANN] STS XML Library 2.0 Now Available
Hey, everyone! The long-awaited, and long-promised STS XML Library 2.0 has finally been released, adding node path support, search and array methods, conditional validation and plugin support to the all-Transcript XML parsing library. It is also fully Revolution Interoperability (RIP) compliant, and ships with a special Compatibility Library that enables current 1.x users the ability to easily transition to the new 2.0 syntax. The new plugin architecture enables third parties to provide libraries that can utilize the XML Library for specialized XML parsing, and Version 2.0 comes with a plugin for manipulating RSS feed documents. The web site, in addition to providing more information about the library, also includes a full comparison of how the STS XML Library compares with the revXML.DLL that comes with Revolution. It also includes the full documentation of the library, so you can look it over to decide for yourself if the STS XML Library if for you. Read more about the XML Library at: http://www.sonsothunder.com/products/xmllib/xmllib.htm Enjoy! Ken Ray Sons of Thunder Software Web site: http://www.sonsothunder.com/ Email: [EMAIL PROTECTED] ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
[ANN] XML Library 1.1.7 Available
This is a quick announcement to let those who have used the STS XML Library that there's a minor update that takes care of a couple of regex bugs that will enable it to work properly in Rev 2.6. You can download your copy of 1.1.7 at: http://www.sonsothunder.com/products/metacard/xmllib.htm Thos of you who purchased the "Standard" version, you should be receiving upgrades in your email (let me know if you don't get it). Thanks, Ken Ray Sons of Thunder Software Web site: http://www.sonsothunder.com/ Email: [EMAIL PROTECTED] ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
[ANN] ReplaceText Bug and STS XML Library
-- IF YOU DON'T USE THE SONS OF THUNDER XML LIBRARY
-- YOU CAN IGNORE THIS POST
Hey everyone... I'm sorry to "shotgun" this email, but I know that there are
dozens of you who have downloaded the Basic version of my XML Library, and
many who have purchased the Standard version, so this is the fastest way to
communicate with you all.
I have recently logged a bug in Bugzilla (#3074) related to Rev 2.6 (I'm
running Build 108) that has a replacetext problem that causes issues with
the XML Library (since that's what it's based on).
The 'xml_normalize' function in the library strips spaces from a string
(leading and trailing spaces) as well as converting space runs to a single
space. The command:
put replaceText("Thisisatest"," *"," ")
in 2.5.1 would return "This is a test". But in 2.6 Build 108, it returns
" " (3 spaces). Apparently it is successful in converting the space runs
to a single space, but at the same time deletes all non-space characters
from the string.
This totally screws up the XML Library since this function is called not
only when you pass parameters that say you want the information normalized
(which you can get around by passing "false" for the normalize param), but
it is *also* called automatically by xml_storeAttribute and
xml_getAttributes - which are called in turn by other XML handlers,
including the *main parsing routine*.
So unfortunately, you can't use the XML Library with confidence in Rev 2.6
(2.5.1 is fine) until this is fixed.
Note that this does NOT affect the revXML DLL, so you may wish to switch to
the revXML DLL in the meantime.
The reason I'm posting this is because I'm concerned that those of you using
the XML Library may be dealing with what you think are bugs in your own
program, but which are actually a result of this replaceText bug.
I'll keep you all posted when things change,
Ken Ray
Sons of Thunder Software
Web site: http://www.sonsothunder.com/
Email: [EMAIL PROTECTED]
___
metacard mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/metacard
Re: XML Library in the MC IDE?
Jan Schenkel wrote: --- Wilhelm Sanke <[EMAIL PROTECTED]> wrote: Has anybody tried and succeeded to work with the XML library in the MC IDE? Of course one could write one's own routines for processing XML files where needed, but there *is* a XML library and I am wondering how it could be integrated in Metacard as it possible with other Rev-specific libraries or handlers. It was explained to me at one time that some of the rev externals (like revDB and revXML) check to see if the user has the proper license to use the advanced features (like Oracle for revDB, and DTD validation in revXML) So this might be a good time to bugzilla it and request that the check is adapted for MC users, who are by definition enterprise users, if I recall correctly. Or just use Ken's Transcript-based XML library: <http://www.sonsothunder.com/products/metacard/xmllib.htm> -- Richard Gaskin Fourth World Media Corporation __ Rev tools and more: http://www.fourthworld.com/rev ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: XML Library in the MC IDE?
Wilhelm - Ken has just such a beast on his website at www.sonsothunder.com. He's your man. /H >Has anybody tried and succeeded to work with the XML library in the MC IDE?>>Of course one could write one's own routines for processing XML files >where needed, but there *is* a XML library and I am wondering how it >could be integrated in Metacard as it possible with other Rev-specific >libraries or handlers.>>Regards,>>Wilhelm Sanke ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: XML Library in the MC IDE?
--- Wilhelm Sanke <[EMAIL PROTECTED]> wrote: > I resend my post below (addressed to the > use-revolution list) to you as > "Metacard specialists". > > Has anybody tried and succeeded to work with the XML > library in the MC IDE? > > Of course one could write one's own routines for > processing XML files > where needed, but there *is* a XML library and I am > wondering how it > could be integrated in Metacard as it possible with > other Rev-specific > libraries or handlers. > > Regards, > > Wilhelm Sanke > Hi WIlhelm, It was explained to me at one time that some of the rev externals (like revDB and revXML) check to see if the user has the proper license to use the advanced features (like Oracle for revDB, and DTD validation in revXML) So this might be a good time to bugzilla it and request that the check is adapted for MC users, who are by definition enterprise users, if I recall correctly. Back to lurking, Jan Schenkel. = Quartam - Tools for Revolution <http://www.quartam.com> = "As we grow older, we grow both wiser and more foolish at the same time." (La Rochefoucauld) __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
XML Library in the MC IDE?
I resend my post below (addressed to the use-revolution list) to you as "Metacard specialists". Has anybody tried and succeeded to work with the XML library in the MC IDE? Of course one could write one's own routines for processing XML files where needed, but there *is* a XML library and I am wondering how it could be integrated in Metacard as it possible with other Rev-specific libraries or handlers. Regards, Wilhelm Sanke On Sat Jan 22, 2005, Mark Smith mark at maseurope.net wrote: >>> > Could anybody tell me where the "XML library" is located in the Rev >>> > IDE? > >> >> I think it's found as 'revXML.bundle' for MacOS and 'revXML.dll' for >> Windows in the 'components' folder inside the revolution folder... >> >> Is that what you mean? >> >> Cheers, >> >> Mark Thanks for the information. Unfortunately the XML library with 'revXML.dll' does not seem to work in the Metacard IDE. I am updating the search routines of my "Topsearch" stack to include XML-files. This works in the Rev IDE, but not in Metacard, even if I set up an identical directory structure, i.e. putting 'revXML.dll' into folder "components/global environment" like in Rev. Even the engine (version 2.6.2A3) is the same in both environments, only the names "mc.exe" and "revolution.exe" differ. I also tried to transfer the needed MC stacks into the Rev directory (only 3 extra stacks are needed besides the "mc.exe" engine to put up the slim MC IDE), but in spite of that the XML library was not accessible. The usual "transcripted" libraries or handlers defined elsewhere *can* be used in the MC IDE as well (provided the necessary links to other libraries or handlers in the Rev IDE are established in an analogous way in Metacard - which may be complicated in some cases, given the very complex structure of the Rev IDE). Am I missing something or is this an instance of lacking compatability between Revolution and Metacard? I am not familiar with DLLs, but could it be that 'revXML.dll' checks for the engine name (or the other way round) and only cooperates with "Revolution.exe" and not with the same engine named "mc.exe"? If this would be the case the compatability problem could be easily fixed inside the engine - or the DLL? - with an improved "name-calling" routine. Cheers, Wilhelm Sanke ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
RE: xCard client for XML-RPC with PmWiki
That sounds great Alain and given we are discussing hooking up a wiki to the rev docs over on the improve list this should come in handy. Cheers Monte > >Hello y'all, > >I would just like to give y'all a little advance >notice of an upcoming 'event' of interest to all >xCarders : I will soon be releasing my new >xCard-client for XML-RPC with PmWiki. IOW, browse & >update a PmWiki from within an xCard stack. for more >impact, recall that Rev & Pan both use wiki for >artefact-sharing, community-building, etc. > >For you ol' timers out there, it is kind of like the >Pan inventory stack which generated our previous web >sites, but now the frontend is a wiki instead of a >static site. > >With some modifications, it could be adapted to >frontend MicroSoft's Web Services. The "Big Leagues", >folks, and not just because MS is involved. > >No download link yet. This is just a teaser. Stay >tuned for the first beta release of my xCard client >for XML-RPC with PmWiki .. in the next couple of days >(or so). > >Did I mention that it will be free, e.g. open source >AND free-of-charge. It goes without saying, but for >those of you who don't know me well, I thought it best >to mention it. After all, new members still join this >list, despite our steved-ness. > >Cheers! > >Alain > > > > >__ >Do you Yahoo!? >Win a $20,000 Career Makeover at Yahoo! HotJobs >http://hotjobs.sweepstakes.yahoo.com/careermakeover >___ >metacard mailing list >[EMAIL PROTECTED] >http://lists.runrev.com/mailman/listinfo/metacard > ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
xCard client for XML-RPC with PmWiki
Hello y'all, I would just like to give y'all a little advance notice of an upcoming 'event' of interest to all xCarders : I will soon be releasing my new xCard-client for XML-RPC with PmWiki. IOW, browse & update a PmWiki from within an xCard stack. for more impact, recall that Rev & Pan both use wiki for artefact-sharing, community-building, etc. For you ol' timers out there, it is kind of like the Pan inventory stack which generated our previous web sites, but now the frontend is a wiki instead of a static site. With some modifications, it could be adapted to frontend MicroSoft's Web Services. The "Big Leagues", folks, and not just because MS is involved. No download link yet. This is just a teaser. Stay tuned for the first beta release of my xCard client for XML-RPC with PmWiki .. in the next couple of days (or so). Did I mention that it will be free, e.g. open source AND free-of-charge. It goes without saying, but for those of you who don't know me well, I thought it best to mention it. After all, new members still join this list, despite our steved-ness. Cheers! Alain __ Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs http://hotjobs.sweepstakes.yahoo.com/careermakeover ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
[ANN] Script Browser, XML Text & OZ-RUG
Howdy I've just uploaded upgrades to my Script Browser plugin and libXMLtext. Download from http://www.sweattechnologies.com/rev/ Script Browser (sorry rev only) - will now show all declared locals, globals and constants even if you didn't javadoc comment them. If you do normal inline rev comments after each declaration this will be included in the browser window. - If libXMLtext is in use then you can modify the text styles. This is a good example of using libXMLtext for style sheet type functionality. libXMLtext - I've finally done an example style setter. Have a play (it's really cool!). - fixed a couple of issues related to Rev 2.0 custom property handling OZ-RUG (Australian Revolution Users Group) To join up go to http://groups.yahoo.com/group/oz-rug/ Current members (me). We will even accept New Zealanders ;-) Actually anyone in the general area is welcome. Maybe we can encourage the RunRev team to do a tour? Cheers Monte ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
XML Library Beta Available
Hello, everyone... I have been working on a W3C-compliant script library for parsing XML in MetaCard. My intention is to make it available in three forms: A Basic form that acts like a callable "plugin" that allows for reading XML data and working with its nodes (which is free and is a locked stack), a Standard form that allows for reading and writing XML data (which is to be sold probably for $19.99 as an unlocked stack w/source code), and a Professional version that includes DTD/Schema support. I currently have the Standard version available for beta testing to anyone who is interested. It requires MC 2.4.2 or later (since it makes heavy use of the fabulous Perl Compatible Regular Expressions library). The following functions (methods) are supported: Loading Methods XMLLoadData Document Management Methods XMLCreateDocument XMLDeleteDocument XMLGetDocuments Node Methods XMLCreateNode XMLDeleteNode XMLGetNode XMLGetNodeName XMLGetNodeType XMLGetRoot XMLIsEmptyElement Parent/Child Methods XMLAppendChild XMLCountChildren XMLCountNamedChildren XMLGetChildren XMLGetFirstChild XMLGetNamedChildren XMLGetLastChild XMLGetNextSibling XMLGetParent XMLGetPrevSibling XMLHasChildren Text Methods XMLGetCDATA XMLGetText Attribute Methods XMLCountAttributes XMLCreateAttribute XMLDeleteAttribute XMLGetAttribute XMLGetAttributes XMLHasAttribute XMLSetAttribute Anyone who is interested to beta test this please send me an email me off-list. Thanks! Ken Ray Sons of Thunder Software Email: [EMAIL PROTECTED] Web Site: http://www.sonsothunder.com/ ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: XML format (was Re: mcRipper .2)
>At 10:23 AM -0700 5/7/2001, David Bovill ><[EMAIL PROTECTED]> wrote: >>Not too clear myself on the CData bit of XML, anyone got a definition for >>me? > >It basically means "text that doesn't include tags or other special >references". CDATA isn't parsed by an SGML parser; it's just taken as >literal text. Another few points to remember: CData can have returns in it; I don't think other tags can. CData can have (non-parsed) tags in it, allowing it to store html or xml. CData ends with ]]> which means that ]] is the only sequence that can't appear in a CData. gc Archives: http://www.mail-archive.com/metacard@lists.runrev.com/ Info: http://www.xworlds.com/metacard/mailinglist.htm Please send bug reports to <[EMAIL PROTECTED]>, not this list.
Re: XML format (was Re: mcRipper .2)
At 10:23 AM -0700 5/7/2001, David Bovill <[EMAIL PROTECTED]> wrote: >Not too clear myself on the CData bit of XML, anyone got a definition for >me? It basically means "text that doesn't include tags or other special references". CDATA isn't parsed by an SGML parser; it's just taken as literal text. -- jeanne a. e. devoto ~ [EMAIL PROTECTED] http://www.jaedworks.com Archives: http://www.mail-archive.com/metacard@lists.runrev.com/ Info: http://www.xworlds.com/metacard/mailinglist.htm Please send bug reports to <[EMAIL PROTECTED]>, not this list.
Re: XML format (was Re: mcRipper .2)
Not too clear myself on the CData bit of XML, anyone got a definition for me? > From: "Jeanne A. E. DeVoto" <[EMAIL PROTECTED]> > > This seems like the best way to go. I think, though, that I'd consider > making an element in its own right, one that could nest inside any > object. This is for two reasons: Any object can have a script (for > instance, you need to put the stack script somewhere in the above), and > objects can contain other objects (for instance, your card can contain > controls). So your prototype would look something like: > > <stack name="My Stack" ID="33" mainstack="Some Main Stack"> > <script> > CDATA stack script goes here > > > > CDATA card script goes here > > > > CDATA card script goes here > > > CDATA button contents goes here > > > > > > > Would need to be careful about tags in the scripts... this may be what the CData tag is for... but otherwise what would you do with a script like: on crashXmlMarkup put "" end crashXmlMarkup There are some simple things you do to get around this I believe - for now, as I just urlencode and decode everything? Archives: http://www.mail-archive.com/metacard@lists.runrev.com/ Info: http://www.xworlds.com/metacard/mailinglist.htm Please send bug reports to <[EMAIL PROTECTED]>, not this list.
Re: XML format (was Re: mcRipper .2)
At 6:37 AM -0700 5/4/2001, "Geoff Canyon" <[EMAIL PROTECTED]> wrote: >It seems there are two basic ways to handle output to XML. Does >anyone have any thoughts on which way would be better, or right? > > cantDelete="false" > marked="false" > showBorder="false"> > > > > > This seems like the best way to go. I think, though, that I'd consider making an element in its own right, one that could nest inside any object. This is for two reasons: Any object can have a script (for instance, you need to put the stack script somewhere in the above), and objects can contain other objects (for instance, your card can contain controls). So your prototype would look something like: <stack name="My Stack" ID="33" mainstack="Some Main Stack"> <script> CDATA stack script goes here CDATA card script goes here CDATA card script goes here CDATA button contents goes here I'm not quite sure how to handle shared groups. They can be defined right under the stack, on the same level as cards, but how to indicate that a group is on a card? Perhaps just a card attribute listing the groups in layer order >The other way would be to have each of the properties of the control >be another element, or CData sections. Doable, but I think it would bloat the XML unnecessarily. >Also, how forgiving are XML parsers of whitespace? returns? The >editors I looked at seemed to turn out very dense XML. For ease of >editing as a text document, I would be inclined to format it more >like it looks below, but would that mess things up? XML doesn't care about whitespace between tags, as far as I know. -- jeanne a. e. devoto ~ [EMAIL PROTECTED] http://www.jaedworks.com Archives: http://www.mail-archive.com/metacard@lists.runrev.com/ Info: http://www.xworlds.com/metacard/mailinglist.htm Please send bug reports to <[EMAIL PROTECTED]>, not this list.
Re: XML format (was Re: mcRipper .2)
The basic question here is when to use elements v. when to use attributes. While there are no hard and fast rules for XML, here are some guidelines that I've found useful. 1. Elements are often a better choice because (a) they can contain substructures, (b) they can contain multiple lines without losing readibility, and (c) they are easier to parse. 2. The best use of an attribute is when there is a small number of fixed choices (enumerated types like Boolean, and other standard MC properties). Also when the data is a small, simple string that rarely if ever changes. This would suggest that most MC properties such as name, loc, etc. be stored as attributes. But the points property of a polygon would have to be stored as an element because it has multiple lines, as would the script of an object. --Leston At 07:37 AM 5/4/01, you wrote: >It seems there are two basic ways to handle output to XML. Does anyone >have any thoughts on which way would be better, or right? Also, the two >could be mixed. I've listed examples below. > >Also, how forgiving are XML parsers of whitespace? returns? The editors I >looked at seemed to turn out very dense XML. For ease of editing as a text >document, I would be inclined to format it more like it looks below, but >would that mess things up? > >Regards, > >Geoff > >Examples: > >First, each control in MetaCard could be translated into an element, with >its properties being converted to attributes. In plain text that would >look something like: > > > cantDelete="false" > marked="false" > showBorder="false"> > > > > > > > >The other way would be to have each of the properties of the control be >another element, or CData sections. That would look like this: > > > > first > false > false > false > > > > another > > > > >Archives: http://www.mail-archive.com/metacard@lists.runrev.com/ >Info: http://www.xworlds.com/metacard/mailinglist.htm >Please send bug reports to <[EMAIL PROTECTED]>, not this list. > Archives: http://www.mail-archive.com/metacard@lists.runrev.com/ Info: http://www.xworlds.com/metacard/mailinglist.htm Please send bug reports to <[EMAIL PROTECTED]>, not this list.
XML format (was Re: mcRipper .2)
It seems there are two basic ways to handle output to XML. Does anyone have any thoughts on which way would be better, or right? Also, the two could be mixed. I've listed examples below. Also, how forgiving are XML parsers of whitespace? returns? The editors I looked at seemed to turn out very dense XML. For ease of editing as a text document, I would be inclined to format it more like it looks below, but would that mess things up? Regards, Geoff Examples: First, each control in MetaCard could be translated into an element, with its properties being converted to attributes. In plain text that would look something like: The other way would be to have each of the properties of the control be another element, or CData sections. That would look like this: first false false false another Archives: http://www.mail-archive.com/metacard@lists.runrev.com/ Info: http://www.xworlds.com/metacard/mailinglist.htm Please send bug reports to <[EMAIL PROTECTED]>, not this list.
Re: XML...
Richard MacLemale wrote: > Enter XML. Instead of sending a 700K MetaCard stack, the program now sends > a 20K XML file. What I did was to essentially write each card as an xml > entry into an xml file, then send the file. On downloading a theme, > MetaCard then makes a copy of an empty template stack, then parses the data > into the stack. > Our district IS folks were VERY happy to see the size of the files we're > sending go from 700K down to 20K! It's funny how customer perceptions work like that. Unless I'm misunderstanding something, instead of sending one large file you're sending several small ones which total to rougly the same size, no? Given the size of the extra ASCII XML tags vs. MC's binary data structures, my hunch is you could send a series of one-card stacks (using "go...in this window") for the same effect, and possibly trim another few k off of the aggregate data size (or am I underestimating the overhead of the stack object?). -- Richard Gaskin Fourth World Media Corporation Multimedia Design and Development for Mac, Windows, UNIX, and the Web _ [EMAIL PROTECTED] http://www.FourthWorld.com Tel: 323-225-3717 ICQ#60248349Fax: 323-225-0716 Archives: http://www.mail-archive.com/metacard@lists.runrev.com/ Info: http://www.xworlds.com/metacard/mailinglist.htm Please send bug reports to <[EMAIL PROTECTED]>, not this list.
Re: XML everything
> I guess the appeal of XML is its generality. So this seems to be the best answer to why people use XML. If in doubt, use XML. Andu Archives: http://www.mail-archive.com/metacard@lists.runrev.com/ Info: http://www.xworlds.com/metacard/mailinglist.htm Please send bug reports to <[EMAIL PROTECTED]>, not this list.
XML...
Sorry I'm late to the party... I just finished a (MetaCard) software project where teachers create stacks, and the stacks are essentially thematic unit plans correlated to our curriculum. Since we have 30 elementary schools, we decided to set up a server which could host stacks written by teachers from all over the county. I built an ftp engine into the program with one button uploading and downloading of stacks. The server is an iMac running WebStar. The whole thing worked great, except for one thing... the stacks were 600 - 700K, and so transfer times were not super-zippy. The reason the stacks were so large was because they had a lot of curriculum listed, as well as other resources. Enter XML. Instead of sending a 700K MetaCard stack, the program now sends a 20K XML file. What I did was to essentially write each card as an xml entry into an xml file, then send the file. On downloading a theme, MetaCard then makes a copy of an empty template stack, then parses the data into the stack. A simple example would be a card named "A1" with a text field named "activity." On creating the xml file, the xml code would look like this (I'm using parenthesis instead of the usual less-than, greater-than symbols, because that might screw up this post!) (entry) (card_name)A1(/card_name) (activity)Students will write an essay.(/activity) (/entry) The downloading script is simple - it just reads each entry and places the info into the appropriate fields of each card. Worked perfectly. Then I made it a bit more complicated by putting the htmlText of each field in to keep the formatting, and that worked fine also. Our district IS folks were VERY happy to see the size of the files we're sending go from 700K down to 20K! And the download and upload speed is, of course, a katrillion times faster. Everyone is happy. It gets better. Since the xml files can be indexed by WebStar, I was able to build a search engine into my program which lets users look INSIDE of uploaded themes. So a teacher can search for "whales" and WebStar will return any units that have that word in them. Cool! XML in this case proved to be very, very useful! :) Richard MacLemale Instructional Technology Specialist James W. Mitchell High School Archives: http://www.mail-archive.com/metacard@lists.runrev.com/ Info: http://www.xworlds.com/metacard/mailinglist.htm Please send bug reports to <[EMAIL PROTECTED]>, not this list.
Re: XML everything
Phil Davis wrote: >> The benefits of XML are many, at least as a format for exchanging > data >> between applications. >> >> On the flipside, for use within an application I find it hard to > beat the >> speed and convenience of using MC's custom properties. MC's > interpreter is >> fast, but not as fast as it's compiled code for getting and setting >> properties. And with multiple property sets within a rich object > hierarchy, >> one can implement complex hierarchical data structures quite easily. > > > Concept: what if MC could automatically convert an XML document to an > array or set of arrays? And convert arrays to XML? > > Would there be a way to set up the new "split" and "combine" commands > to parse/unparse an XML document into/out of an array or set of > arrays? That would be about as cool as it gets, no? With one hitch: XML is inherently n-levels deep in terms of nesting, while MC custom props are only one level deep (conceivably two if you include multiple data sets). The key to getting depth with MC is to use the object hierarchy in conjunction with custom prop sets, and while that's more depth than most people will need it will, being a fixed number, not be able to directly address some XML needs. Another Q: Are you folks creating and parsing DDTs with your XML, or just dropping tags in without regard for the DDT component? -- Richard Gaskin Fourth World Media Corporation Multimedia Design and Development for Mac, Windows, UNIX, and the Web _ [EMAIL PROTECTED] http://www.FourthWorld.com Tel: 323-225-3717 ICQ#60248349Fax: 323-225-0716 Archives: http://www.mail-archive.com/metacard@lists.runrev.com/ Info: http://www.xworlds.com/metacard/mailinglist.htm Please send bug reports to <[EMAIL PROTECTED]>, not this list.
Re: XML everything
- Original Message - From: "Richard Gaskin" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, April 18, 2001 10:12 AM Subject: Re: XML everything > > The benefits of XML are many, at least as a format for exchanging data > between applications. > > On the flipside, for use within an application I find it hard to beat the > speed and convenience of using MC's custom properties. MC's interpreter is > fast, but not as fast as it's compiled code for getting and setting > properties. And with multiple property sets within a rich object hierarchy, > one can implement complex hierarchical data structures quite easily. Concept: what if MC could automatically convert an XML document to an array or set of arrays? And convert arrays to XML? Would there be a way to set up the new "split" and "combine" commands to parse/unparse an XML document into/out of an array or set of arrays? That would be about as cool as it gets, no? Phil Davis > > But always looking to improve XML speed for when it's needed, I've been > using the offset function for parsing XML but can't help but think there's a > faster method. > > I haven't spent much time running various alternatives through my > benchmarking tool, MetaBench (downloadable for free from > <ftp://ftp.fourthworld.com/MetaCard/4W_MetaBench.mc.sit.hqx>) -- have any of > you come up with faster means of reliably parsing XML than using offset? > > -- > Richard Gaskin > Fourth World Media Corporation > Multimedia Design and Development for Mac, Windows, UNIX, and the Web > _ > [EMAIL PROTECTED] http://www.FourthWorld.com > Tel: 323-225-3717 ICQ#60248349Fax: 323-225-0716 > > > > Archives: http://www.mail-archive.com/metacard@lists.runrev.com/ > Info: http://www.xworlds.com/metacard/mailinglist.htm > Please send bug reports to <[EMAIL PROTECTED]>, not this list. > > Archives: http://www.mail-archive.com/metacard@lists.runrev.com/ Info: http://www.xworlds.com/metacard/mailinglist.htm Please send bug reports to <[EMAIL PROTECTED]>, not this list.
Re: XML everything
The benefits of XML are many, at least as a format for exchanging data between applications. On the flipside, for use within an application I find it hard to beat the speed and convenience of using MC's custom properties. MC's interpreter is fast, but not as fast as it's compiled code for getting and setting properties. And with multiple property sets within a rich object hierarchy, one can implement complex hierarchical data structures quite easily. But always looking to improve XML speed for when it's needed, I've been using the offset function for parsing XML but can't help but think there's a faster method. I haven't spent much time running various alternatives through my benchmarking tool, MetaBench (downloadable for free from <ftp://ftp.fourthworld.com/MetaCard/4W_MetaBench.mc.sit.hqx>) -- have any of you come up with faster means of reliably parsing XML than using offset? -- Richard Gaskin Fourth World Media Corporation Multimedia Design and Development for Mac, Windows, UNIX, and the Web _ [EMAIL PROTECTED] http://www.FourthWorld.com Tel: 323-225-3717 ICQ#60248349Fax: 323-225-0716 Archives: http://www.mail-archive.com/metacard@lists.runrev.com/ Info: http://www.xworlds.com/metacard/mailinglist.htm Please send bug reports to <[EMAIL PROTECTED]>, not this list.
Re: XML everything
The reasons that I am planning on adding better XML formattings for my applications are (these may or not be directly applicable to your situation, but it may help to see other's reasoning) 1. Everything I work on will be integrated with the internet at some level. Knowing that most server platforms have some support for XML parsing, I know that if I have to communicate with something other than an MC server, the parsing code should be relatively simple on the other platform. My goal is to have all communications between mc client and mc server stacks to be in XML so I can jump servers quickly if necessary. 2. Backup files are easy to create, easy to parse, and...sometimes more important..easy to read (human reading :). I.E. I have a database of references...these are all stored in XML...XML files can be read by Internet Explorer 5 as a hierarchical tree...makes it easy to poke through a backup file. 3. Data sets that have varied (loose) formats and embedded structure are easier to deal with.. i.e. things like There are three points:Point 1Point 2Point 3 Something like that is difficult to deal with with simple key structures Like others who have posted, the processing is done in other formats (i.e. arrays,etc) that are native to MC...but, this is really the case for all systems (i.e. try multiplying two XML elements together without first converting them to numbers). In your specific case, your structure is quite similar to XML, and if it doesn't need to be shared with other apps, then you really have no reason to change over (and there is quite a bit of code that makes reading key structures easy). Well..other than you could impress fellow party-goers that you are using XML ;) -ml >Using XML for the lesson content probably makes good sense. But the >program also has to output various student data such as test results, >lesson progress, etc. Currently, this is done in typical key/value >style. E.g.: >[GENERAL] >userid=123 >lastname=Cragg >firstname=Dave >[TEST_RESULTS] >recenttestdate=2001,4,1 >recenttestscore=0 >etc. > >Should I change this to use XML? Right now, I can't see any good >reason to, so I probably won't. But I think I'm likely to face the >question, "Why aren't you using XML for this?" My answer right now >is a shrug of the shoulders. So what do you think? Should I change it >to XML or not? > >Cheers >Dave Cragg Mark J. Luetzelschwab [EMAIL PROTECTED] Graduate Research Assistant (v) (512) 232 6034 Instructional Technology(f) (512) 232 2322 Reading and Language Arts: http://www.texasreading.org Archives: http://www.mail-archive.com/metacard@lists.runrev.com/ Info: http://www.xworlds.com/metacard/mailinglist.htm Please send bug reports to <[EMAIL PROTECTED]>, not this list.
Re: XML everything
Dave Cragg wrote: > > At 9:00 pm -0400 17/4/01, andu wrote: > >I looked at info on different messaging software the other day and came > >across "Jobber" which is "open source". > >What distinguishes it doesn't seem to be a new technology or philosophy > >but the fact that it's all XML: header information, the message itself > >and client-server control data. > >XML has great advantages at operating with data which is displayed but I > >never understood the usefulness of it when it comes to managing data > >"behind the scene". > >Why would one use "andu" instead of "username: > >andu" and stuff like that in a header? Same goes for webDav. The > >overhead of parsing and transmitting at least twice the length of data > >seems unacceptable to me. > >I'd like to hear what other people think on this subject. > > > > I guess the appeal of XML is its generality. You can use it to > describe anything from publishable documents to conventional > database-like data. > > But I think you're right about the overheads. If your data is > limited to unique fields (user name, id, etc.), and you know when and > how it is going to be used, then why bother with XML. On the other > hand, if you're not sure when you start out how the data might > eventually be used, it might be safer to follow the crowd. > > I'm facing this problem right now. Here's a description. (Excuse the ramble.) > > I've been revising a language teaching program which consists of a > large number of lessons, each one a Metacard stack. The plan is to > convert the "content" of the lessons into XML. This makes sense, as > the lessons can be easily repurposed. From the same XML source, the > lessons can be played interactively in Metacard, published in hard > copy, and even played interactively with other tools (e.g. Flash). > But none of the "final formats" uses XML directly. In the Metacard > lessons, the XML is parsed when the lesson opens and is put into > Metacard properties, variables, etc. From that point, the xml is > never referenced again. For the printed copy, the XML tags are > replaced with rtf formatting code (using Metacard of course) and > output as a formatted Word document that is then printed to PDF. > > Using XML for the lesson content probably makes good sense. But the > program also has to output various student data such as test results, > lesson progress, etc. Currently, this is done in typical key/value > style. E.g.: > [GENERAL] > userid=123 > lastname=Cragg > firstname=Dave > [TEST_RESULTS] > recenttestdate=2001,4,1 > recenttestscore=0 > etc. > > Should I change this to use XML? Right now, I can't see any good > reason to, so I probably won't. But I think I'm likely to face the > question, "Why aren't you using XML for this?" My answer right now > is a shrug of the shoulders. So what do you think? Should I change it > to XML or not? If a shrug of shoulders would do, then don't, otherwise you must come up with something;-). I'd say, if someone wants to interact with the database of students performance she/he can convert the plain text data to whatever format they wish specially if it is in a non MC-specific form, which in your example is not. > > Cheers > Dave Cragg Andu Archives: http://www.mail-archive.com/metacard@lists.runrev.com/ Info: http://www.xworlds.com/metacard/mailinglist.htm Please send bug reports to <[EMAIL PROTECTED]>, not this list.
Re: XML everything
michael kann wrote: > > --- andu <[EMAIL PROTECTED]> wrote: > > I looked at info on different messaging software the > other day and came across "Jobber" > > -- Do you mean "Jabber" ? Yes. > > I'd like to take this opportunity to thank Andu for > all his help on and off this list. > Andu Archives: http://www.mail-archive.com/metacard@lists.runrev.com/ Info: http://www.xworlds.com/metacard/mailinglist.htm Please send bug reports to <[EMAIL PROTECTED]>, not this list.
Re: XML everything
--- andu <[EMAIL PROTECTED]> wrote: I looked at info on different messaging software the other day and came across "Jobber" -- Do you mean "Jabber" ? I'd like to take this opportunity to thank Andu for all his help on and off this list. __ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/ Archives: http://www.mail-archive.com/metacard@lists.runrev.com/ Info: http://www.xworlds.com/metacard/mailinglist.htm Please send bug reports to <[EMAIL PROTECTED]>, not this list.
RE: XML everything
one answer to these questions is the following: changes in the data structure demand less reprogramming if the data model is in xml. imagine you remove field 2 - without xml, you have to change your parser... with xml you dont have to change anything... imagine you have a new field: in xml you can ignore the new field or implement it whenever... without you'll have to parse differently again... as for style, in xml, the logic is the same as the data model. if you use other xml features like xlt etc, you'll have similar advantages... add a little complexity to your program will definitely reduce maintenance later... imoho... -Original Message- From: Dave Cragg [mailto:[EMAIL PROTECTED]] Sent: Wednesday, April 18, 2001 11:06 AM To: [EMAIL PROTECTED] Subject: Re: XML everything At 9:00 pm -0400 17/4/01, andu wrote: >I looked at info on different messaging software the other day and came >across "Jobber" which is "open source". >What distinguishes it doesn't seem to be a new technology or philosophy >but the fact that it's all XML: header information, the message itself >and client-server control data. >XML has great advantages at operating with data which is displayed but I >never understood the usefulness of it when it comes to managing data >"behind the scene". >Why would one use "andu" instead of "username: >andu" and stuff like that in a header? Same goes for webDav. The >overhead of parsing and transmitting at least twice the length of data >seems unacceptable to me. >I'd like to hear what other people think on this subject. > I guess the appeal of XML is its generality. You can use it to describe anything from publishable documents to conventional database-like data. But I think you're right about the overheads. If your data is limited to unique fields (user name, id, etc.), and you know when and how it is going to be used, then why bother with XML. On the other hand, if you're not sure when you start out how the data might eventually be used, it might be safer to follow the crowd. I'm facing this problem right now. Here's a description. (Excuse the ramble.) I've been revising a language teaching program which consists of a large number of lessons, each one a Metacard stack. The plan is to convert the "content" of the lessons into XML. This makes sense, as the lessons can be easily repurposed. From the same XML source, the lessons can be played interactively in Metacard, published in hard copy, and even played interactively with other tools (e.g. Flash). But none of the "final formats" uses XML directly. In the Metacard lessons, the XML is parsed when the lesson opens and is put into Metacard properties, variables, etc. From that point, the xml is never referenced again. For the printed copy, the XML tags are replaced with rtf formatting code (using Metacard of course) and output as a formatted Word document that is then printed to PDF. Using XML for the lesson content probably makes good sense. But the program also has to output various student data such as test results, lesson progress, etc. Currently, this is done in typical key/value style. E.g.: [GENERAL] userid=123 lastname=Cragg firstname=Dave [TEST_RESULTS] recenttestdate=2001,4,1 recenttestscore=0 etc. Should I change this to use XML? Right now, I can't see any good reason to, so I probably won't. But I think I'm likely to face the question, "Why aren't you using XML for this?" My answer right now is a shrug of the shoulders. So what do you think? Should I change it to XML or not? Cheers Dave Cragg Archives: http://www.mail-archive.com/metacard@lists.runrev.com/ Info: http://www.xworlds.com/metacard/mailinglist.htm Please send bug reports to <[EMAIL PROTECTED]>, not this list. Visit us at http://www.clearstream.com Check out current job vacancies at http://www.clearstream.com/public/english/e_vacs.htm IMPORTANT MESSAGE Internet communications are not secure and therefore Clearstream International does not accept legal responsibility for the contents of this message. The information contained in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any views expressed in this e-mail are those of the individual sender, except where the sender specifically states them to be the views of Clearstream International or of any of its affiliates or subsidiaries. END OF DISCLAIMER Archives: http://www.mail-archive.com/metacard@lists.runrev.com/ Info: http://www.xworlds.com/metacard/mailinglist.htm Please send bug reports to <[EMAIL PROTECTED]>, not this list.
Re: XML everything
At 9:00 pm -0400 17/4/01, andu wrote: >I looked at info on different messaging software the other day and came >across "Jobber" which is "open source". >What distinguishes it doesn't seem to be a new technology or philosophy >but the fact that it's all XML: header information, the message itself >and client-server control data. >XML has great advantages at operating with data which is displayed but I >never understood the usefulness of it when it comes to managing data >"behind the scene". >Why would one use "andu" instead of "username: >andu" and stuff like that in a header? Same goes for webDav. The >overhead of parsing and transmitting at least twice the length of data >seems unacceptable to me. >I'd like to hear what other people think on this subject. > I guess the appeal of XML is its generality. You can use it to describe anything from publishable documents to conventional database-like data. But I think you're right about the overheads. If your data is limited to unique fields (user name, id, etc.), and you know when and how it is going to be used, then why bother with XML. On the other hand, if you're not sure when you start out how the data might eventually be used, it might be safer to follow the crowd. I'm facing this problem right now. Here's a description. (Excuse the ramble.) I've been revising a language teaching program which consists of a large number of lessons, each one a Metacard stack. The plan is to convert the "content" of the lessons into XML. This makes sense, as the lessons can be easily repurposed. From the same XML source, the lessons can be played interactively in Metacard, published in hard copy, and even played interactively with other tools (e.g. Flash). But none of the "final formats" uses XML directly. In the Metacard lessons, the XML is parsed when the lesson opens and is put into Metacard properties, variables, etc. From that point, the xml is never referenced again. For the printed copy, the XML tags are replaced with rtf formatting code (using Metacard of course) and output as a formatted Word document that is then printed to PDF. Using XML for the lesson content probably makes good sense. But the program also has to output various student data such as test results, lesson progress, etc. Currently, this is done in typical key/value style. E.g.: [GENERAL] userid=123 lastname=Cragg firstname=Dave [TEST_RESULTS] recenttestdate=2001,4,1 recenttestscore=0 etc. Should I change this to use XML? Right now, I can't see any good reason to, so I probably won't. But I think I'm likely to face the question, "Why aren't you using XML for this?" My answer right now is a shrug of the shoulders. So what do you think? Should I change it to XML or not? Cheers Dave Cragg Archives: http://www.mail-archive.com/metacard@lists.runrev.com/ Info: http://www.xworlds.com/metacard/mailinglist.htm Please send bug reports to <[EMAIL PROTECTED]>, not this list.
Re: XML everything
On 4/18/01 9:00 AM, andu wrote: > I looked at info on different messaging software the other day and came > across "Jobber" which is "open source". > What distinguishes it doesn't seem to be a new technology or philosophy > but the fact that it's all XML: header information, the message itself > and client-server control data. > XML has great advantages at operating with data which is displayed but I > never understood the usefulness of it when it comes to managing data > "behind the scene". In many cases, storing data in XML has advantage of proceeding it with many other tools - even a word processor. However, we parse XML into array for processing most of the time. And only store non-critical (small size, no speed concern) data in XML. There are no speed advantage of dealing with XML on "behind the scene" situation, but we realised that user tent to get more complicated nowadays and would want to deal with data directly. Don't forget PostScript is far more efficient then HTML on page layout, but how many person do you know write PostScript file with word processor? I don't mind to make full use of XML, provided a very efficient XML library is given (definitely not written by myself ;-). However when come to data processing, use whatever is native on your system - in our case, the array in MetaCard. Regards, LiangTyan Fui > Why would one use "andu" instead of "username: > andu" and stuff like that in a header? Same goes for webDav. The > overhead of parsing and transmitting at least twice the length of data > seems unacceptable to me. > I'd like to hear what other people think on this subject. > > Andu Archives: http://www.mail-archive.com/metacard@lists.runrev.com/ Info: http://www.xworlds.com/metacard/mailinglist.htm Please send bug reports to <[EMAIL PROTECTED]>, not this list.
Re: XML everything
MisterX wrote: > > xml has a overhead is true. > but unless you have a greater protocol, it can > be made more compact > it's with parsing functions that these become easy to > manipulate. > > it's also easier to setup between multiple clients of different > origin... imoho... > Why, take for example a basic HTTP/1.1 header which is plain text lines separated by crlf. In XML it would be the same lines surrounded by tags. Any language used for clients understands plain text, but would have to translate XML first. > > I looked at info on different messaging software the other day and came > > across "Jobber" which is "open source". > > What distinguishes it doesn't seem to be a new technology or philosophy > > but the fact that it's all XML: header information, the message itself > > and client-server control data. > > XML has great advantages at operating with data which is displayed but I > > never understood the usefulness of it when it comes to managing data > > "behind the scene". > > Why would one use "andu" instead of "username: > > andu" and stuff like that in a header? Same goes for webDav. The > > overhead of parsing and transmitting at least twice the length of data > > seems unacceptable to me. > > I'd like to hear what other people think on this subject. > > > > Andu Andu Archives: http://www.mail-archive.com/metacard@lists.runrev.com/ Info: http://www.xworlds.com/metacard/mailinglist.htm Please send bug reports to <[EMAIL PROTECTED]>, not this list.
RE: XML everything
xml has a overhead is true. but unless you have a greater protocol, it can be made more compact it's with parsing functions that these become easy to manipulate. it's also easier to setup between multiple clients of different origin... imoho... > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of andu > Sent: Wednesday, April 18, 2001 3:00 AM > To: [EMAIL PROTECTED] > Subject: XML everything > > > I looked at info on different messaging software the other day and came > across "Jobber" which is "open source". > What distinguishes it doesn't seem to be a new technology or philosophy > but the fact that it's all XML: header information, the message itself > and client-server control data. > XML has great advantages at operating with data which is displayed but I > never understood the usefulness of it when it comes to managing data > "behind the scene". > Why would one use "andu" instead of "username: > andu" and stuff like that in a header? Same goes for webDav. The > overhead of parsing and transmitting at least twice the length of data > seems unacceptable to me. > I'd like to hear what other people think on this subject. > > Andu > > Archives: http://www.mail-archive.com/metacard@lists.runrev.com/ > Info: http://www.xworlds.com/metacard/mailinglist.htm > Please send bug reports to <[EMAIL PROTECTED]>, not this list. > > Archives: http://www.mail-archive.com/metacard@lists.runrev.com/ Info: http://www.xworlds.com/metacard/mailinglist.htm Please send bug reports to <[EMAIL PROTECTED]>, not this list.
Re: XML everything
- Original Message - From: "andu" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, April 17, 2001 6:00 PM Subject: XML everything > I looked at info on different messaging software the other day and came > across "Jobber" which is "open source". > What distinguishes it doesn't seem to be a new technology or philosophy > but the fact that it's all XML: header information, the message itself > and client-server control data. > XML has great advantages at operating with data which is displayed but I > never understood the usefulness of it when it comes to managing data > "behind the scene". It seems to me that the XML advantage kicks in when your app has to interact with another (non-MC) app or system. Inside the hard candy coating of an MC app, however, the existing approach works fine for me. Of course, I haven't built any XML apps yet. > Why would one use "andu" instead of "username: > andu" and stuff like that in a header? Same goes for webDav. The > overhead of parsing and transmitting at least twice the length of data > seems unacceptable to me. > I'd like to hear what other people think on this subject. > > Andu > > Archives: http://www.mail-archive.com/metacard@lists.runrev.com/ > Info: http://www.xworlds.com/metacard/mailinglist.htm > Please send bug reports to <[EMAIL PROTECTED]>, not this list. > > Archives: http://www.mail-archive.com/metacard@lists.runrev.com/ Info: http://www.xworlds.com/metacard/mailinglist.htm Please send bug reports to <[EMAIL PROTECTED]>, not this list.
XML everything
I looked at info on different messaging software the other day and came across "Jobber" which is "open source". What distinguishes it doesn't seem to be a new technology or philosophy but the fact that it's all XML: header information, the message itself and client-server control data. XML has great advantages at operating with data which is displayed but I never understood the usefulness of it when it comes to managing data "behind the scene". Why would one use "andu" instead of "username: andu" and stuff like that in a header? Same goes for webDav. The overhead of parsing and transmitting at least twice the length of data seems unacceptable to me. I'd like to hear what other people think on this subject. Andu Archives: http://www.mail-archive.com/metacard@lists.runrev.com/ Info: http://www.xworlds.com/metacard/mailinglist.htm Please send bug reports to <[EMAIL PROTECTED]>, not this list.
Re: XML functions
I've promised to post mine too to a number of people on the list, so I'll do that tonight! > From: "MisterX" <[EMAIL PROTECTED]> > Reply-To: [EMAIL PROTECTED] > Date: Thu, 22 Mar 2001 06:53:00 +0100 > To: [EMAIL PROTECTED] > Subject: RE: XML functions > > i'll share mine when I finish it... > It's not fully compliant but it's a good parser. > > I'll update my site later today and tomorow, > I'll post it as work in progress... > > cheers, > Xavier > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Mark Luetzelschwab > Sent: Wednesday, March 21, 2001 11:19 PM > To: [EMAIL PROTECTED] > Subject: XML functions > > > Hi All, > > Before I take a crack at writing XML-like functions in MC, what has > everyone else been doing? Does anyone have a library to share? > > -ml > Mark J. Luetzelschwab [EMAIL PROTECTED] > Graduate Research Assistant (v) (512) 232 6034 > Instructional Technology (f) (512) 232 2322 > Reading and Language Arts: > http://www.texasreading.org > > Archives: http://www.mail-archive.com/metacard@lists.runrev.com/ > Info: http://www.xworlds.com/metacard/mailinglist.htm > Please send bug reports to <[EMAIL PROTECTED]>, not this list. > > > > Archives: http://www.mail-archive.com/metacard@lists.runrev.com/ > Info: http://www.xworlds.com/metacard/mailinglist.htm > Please send bug reports to <[EMAIL PROTECTED]>, not this list. > > Archives: http://www.mail-archive.com/metacard@lists.runrev.com/ Info: http://www.xworlds.com/metacard/mailinglist.htm Please send bug reports to <[EMAIL PROTECTED]>, not this list.
RE: XML functions
i'll share mine when I finish it... It's not fully compliant but it's a good parser. I'll update my site later today and tomorow, I'll post it as work in progress... cheers, Xavier -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Mark Luetzelschwab Sent: Wednesday, March 21, 2001 11:19 PM To: [EMAIL PROTECTED] Subject: XML functions Hi All, Before I take a crack at writing XML-like functions in MC, what has everyone else been doing? Does anyone have a library to share? -ml Mark J. Luetzelschwab [EMAIL PROTECTED] Graduate Research Assistant (v) (512) 232 6034 Instructional Technology(f) (512) 232 2322 Reading and Language Arts: http://www.texasreading.org Archives: http://www.mail-archive.com/metacard@lists.runrev.com/ Info: http://www.xworlds.com/metacard/mailinglist.htm Please send bug reports to <[EMAIL PROTECTED]>, not this list. Archives: http://www.mail-archive.com/metacard@lists.runrev.com/ Info: http://www.xworlds.com/metacard/mailinglist.htm Please send bug reports to <[EMAIL PROTECTED]>, not this list.
XML functions
Hi All, Before I take a crack at writing XML-like functions in MC, what has everyone else been doing? Does anyone have a library to share? -ml Mark J. Luetzelschwab [EMAIL PROTECTED] Graduate Research Assistant (v) (512) 232 6034 Instructional Technology(f) (512) 232 2322 Reading and Language Arts: http://www.texasreading.org Archives: http://www.mail-archive.com/metacard@lists.runrev.com/ Info: http://www.xworlds.com/metacard/mailinglist.htm Please send bug reports to <[EMAIL PROTECTED]>, not this list.
RE: Parsing HTML/XML: MatchText or Offset?
if im correct, offset if much faster. Skips the REP parsing... testing required of course! -Original Message- From: David Bovill [mailto:[EMAIL PROTECTED]] Sent: mercredi 7 mars 2001 21:08 To: [EMAIL PROTECTED] Subject: Re: Parsing HTML/XML: MatchText or Offset? I have developed some based on some original HyperCard algorithms which used offset. They have now been upgraded to use MatchText, although this ended up getting complicated, so they still use some offset functions. I haven't got them on this machine, but I can email them to anyone who writes me off-list? David > From: Richard Gaskin <[EMAIL PROTECTED]> > Reply-To: [EMAIL PROTECTED] > Date: Wed, 07 Mar 2001 10:03:45 -0800 > To: [EMAIL PROTECTED] > Subject: Parsing HTML/XML: MatchText or Offset? > > Anyone done benchmarking to determine which is faster, using MatchText or > Offset for parsing tags like HTML or XML? > > Anyone have a good set of algorithms for this they can share? > > -- > Richard Gaskin > Fourth World Media Corporation > Multimedia Design and Development for Mac, Windows, UNIX, and the Web > _ > [EMAIL PROTECTED] http://www.FourthWorld.com > Tel: 323-225-3717 ICQ#60248349Fax: 323-225-0716 > > > > Archives: http://www.mail-archive.com/metacard@lists.runrev.com/ > Info: http://www.xworlds.com/metacard/mailinglist.htm > Please send bug reports to <[EMAIL PROTECTED]>, not this list. > > Archives: http://www.mail-archive.com/metacard@lists.runrev.com/ Info: http://www.xworlds.com/metacard/mailinglist.htm Please send bug reports to <[EMAIL PROTECTED]>, not this list. Visit us at http://www.clearstream.com Check out current job vacancies at http://www.clearstream.com/public/english/e_vacs.htm IMPORTANT MESSAGE Internet communications are not secure and therefore Clearstream International does not accept legal responsibility for the contents of this message. The information contained in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any views expressed in this e-mail are those of the individual sender, except where the sender specifically states them to be the views of Clearstream International or of any of its affiliates or subsidiaries. END OF DISCLAIMER Archives: http://www.mail-archive.com/metacard@lists.runrev.com/ Info: http://www.xworlds.com/metacard/mailinglist.htm Please send bug reports to <[EMAIL PROTECTED]>, not this list.
Re: Parsing HTML/XML: MatchText or Offset?
I have developed some based on some original HyperCard algorithms which used offset. They have now been upgraded to use MatchText, although this ended up getting complicated, so they still use some offset functions. I haven't got them on this machine, but I can email them to anyone who writes me off-list? David > From: Richard Gaskin <[EMAIL PROTECTED]> > Reply-To: [EMAIL PROTECTED] > Date: Wed, 07 Mar 2001 10:03:45 -0800 > To: [EMAIL PROTECTED] > Subject: Parsing HTML/XML: MatchText or Offset? > > Anyone done benchmarking to determine which is faster, using MatchText or > Offset for parsing tags like HTML or XML? > > Anyone have a good set of algorithms for this they can share? > > -- > Richard Gaskin > Fourth World Media Corporation > Multimedia Design and Development for Mac, Windows, UNIX, and the Web > _ > [EMAIL PROTECTED] http://www.FourthWorld.com > Tel: 323-225-3717 ICQ#60248349Fax: 323-225-0716 > > > > Archives: http://www.mail-archive.com/metacard@lists.runrev.com/ > Info: http://www.xworlds.com/metacard/mailinglist.htm > Please send bug reports to <[EMAIL PROTECTED]>, not this list. > > Archives: http://www.mail-archive.com/metacard@lists.runrev.com/ Info: http://www.xworlds.com/metacard/mailinglist.htm Please send bug reports to <[EMAIL PROTECTED]>, not this list.
Parsing HTML/XML: MatchText or Offset?
Anyone done benchmarking to determine which is faster, using MatchText or Offset for parsing tags like HTML or XML? Anyone have a good set of algorithms for this they can share? -- Richard Gaskin Fourth World Media Corporation Multimedia Design and Development for Mac, Windows, UNIX, and the Web _ [EMAIL PROTECTED] http://www.FourthWorld.com Tel: 323-225-3717 ICQ#60248349Fax: 323-225-0716 Archives: http://www.mail-archive.com/metacard@lists.runrev.com/ Info: http://www.xworlds.com/metacard/mailinglist.htm Please send bug reports to <[EMAIL PROTECTED]>, not this list.
Re: XML parsing...
At 1:29 PM +0100 10/11/00, David Bovill wrote: >Is there anyone working on this are, who would be interested in >using/advising on the creation of a general purpose XML library? I'm also very interested. I had a go recently at some basic parsing, and ran into problems with using regex. (I think you reported something similar in a recent post.) I resorted to using a mixture of matchText and the offset function for some things. But I was groping in the dark a little as I wasn't completely clear of the various rules for valid XML content (whitespace, case, etc.). I'm still not clear. Right now, my functions will only work with my own home-made xml. These are the functions I made (kind of): xmlElement(pName, pData) This returns the first element with the name pName from a chunk of text (pData). It returns the element complete with tags. (It won't return empty elements.) xmlAllElements(pName, pData) This returns all the elements with the name pName from a chunk of data. It returns them as a return separated list, so assumes all the elements are single lines of text. (As I said, it works with home-made xml.) Probably better to use an array for this. xmlAttribute(pAttrib, pElem) Returns the value of the attribute pAttrib from some xml element. (A bit shaky. Needs more work.) xmlStripStartEndTags(pElem) Strips the start and end tags from an xml element. If anyone's interested, I can mail the scripts. And I'd be happy to see yours, David. (scripts, that is :) So far, I've been surprised that something so conceptually simple as XML has been so tricky to work with in Metacard. But it's early days I guess. Cheers Dave Cragg
RE: XML parsing...
im interested! i have some to contribute too... > >> Is there anyone working on this are, who would be interested in > >> using/advising on the creation of a general purpose XML library? Xavier
Re: XML parsing...
I'll send you a stack if you wish (off-list). It should be ready for consumption Monday? > From: Tereza Snyder <[EMAIL PROTECTED]> > Reply-To: [EMAIL PROTECTED] > Date: Wed, 11 Oct 2000 11:23:53 -0500 > To: <[EMAIL PROTECTED]> > Subject: Re: XML parsing... > > on 10/11/00 7:29 AM, David Bovill at [EMAIL PROTECTED] wrote: > >> Anyone out there who knows anything about this. I have some scripts, but I >> want to get a general purpose parser the goes through all the tags, and does >> some processing, and i'm not sure I have got it right... >> >> Is there anyone working on this are, who would be interested in >> using/advising on the creation of a general purpose XML library? >> >> > > I'm not sure if my earlier message got through, but I wrote: > > >> I'm currently working on an XML-parsing external for MetaCard with a view to >> storing user-preference data to exchange with other programs. I'm still >> groping my way and would love to see what you've done with scripts, and to >> contribute any insights I've won. > > tereza > > . . ... . ACT AGAINST ENTROPY! . ... . . >
Re: XML parsing...
on 10/11/00 7:29 AM, David Bovill at [EMAIL PROTECTED] wrote: > Anyone out there who knows anything about this. I have some scripts, but I > want to get a general purpose parser the goes through all the tags, and does > some processing, and i'm not sure I have got it right... > > Is there anyone working on this are, who would be interested in > using/advising on the creation of a general purpose XML library? > > I'm not sure if my earlier message got through, but I wrote: > I'm currently working on an XML-parsing external for MetaCard with a view to > storing user-preference data to exchange with other programs. I'm still > groping my way and would love to see what you've done with scripts, and to > contribute any insights I've won. tereza . . ... . ACT AGAINST ENTROPY! . ... . .
Re: XML parsing...
on 10/11/00 7:29 AM, David Bovill at [EMAIL PROTECTED] wrote: > Anyone out there who knows anything about this. I have some scripts, but I > want to get a general purpose parser the goes through all the tags, and does > some processing, and i'm not sure I have got it right... > > Is there anyone working on this are, who would be interested in > using/advising on the creation of a general purpose XML library? > > I'm not sure if my earlier message got through, but I wrote: > I'm currently working on an XML-parsing external for MetaCard with a view to > storing user-preference data to exchange with other programs. I'm still > groping my way and would love to see what you've done with scripts, and to > contribute any insights I've won. tereza . . ... . ACT AGAINST ENTROPY! . ... . .
XML parsing...
Anyone out there who knows anything about this. I have some scripts, but I want to get a general purpose parser the goes through all the tags, and does some processing, and i'm not sure I have got it right... Is there anyone working on this are, who would be interested in using/advising on the creation of a general purpose XML library?
