Parsing large amounts of data (200,000 entries) with XML?
jamie
<Root>
-<Time>
<TimeData>0.1
<TimeData>0.15
.
. (to 50,000) subnodes
</time>
+<Temperature> (to 50,000 children)
+<Meas1> (to 50,000 children)
+<Meas2> (to 50,000 children)
</Root>
When I try and open this file and parse the data into arrays it takes
forever!?!? (see the code snippet below...)
I have 3 questions:
1. Is the xml format that I am using the most efficient for large data
arrays? Would textnodes be better for the data elements?
2. Is there a better way to parse the data?
3. If XML can't handle this much data efficiently, what is another
technique I can use (it must be hierarchical)
Thanks for your help,
Jamie
Code snippet................
Set aElement =xmlDoc.documentElement.selectSingleNode("Root")
Set aElement2 = aElement.selectSingleNode("Time")
Set nodeListTime = aElement2.selectNodes("TimeData")
Set aElement2 = aElement.selectSingleNode("Temperature")
Set nodeListTemp = aElement2.selectNodes("TempData")
Set aElement2 = aElement.selectSingleNode("Meas1")
Set nodeListMeas1 = aElement2.selectNodes("Meas1Data")
Set aElement2 = aElement.selectSingleNode("Meas2")
Set nodeListMeas2 = aElement2.selectNodes("Meas2Data")
Dim l As Long
Dim aTime(50000) As Double
Dim aTemp(50000) As Double
Dim aMeas1(50000) As Double
Dim aMeas2(50000) As Double
For l = 0 To nodeListTime.length - 1
aTime(l) = nodeListTime(l).nodeTypedValue
aTemp(l) = nodeListTemp(l).nodeTypedValue
aMeas1(l) = nodeListCH1(l).nodeTypedValue
aMeas2(l) = nodeListCH2(l).nodeTypedValue
DoEvents
Next l
Rick Rothstein
however, I'll bet all those DoEvents that you are executing are eating up a
significant amount of time. Maybe you might want to execute the DoEvents
once every 1000, or even 5000, loops of the For-Next block. If it doesn't
take extraordinarily long to execute your bare loop, I consider removing the
call to DoEvents altogether.
Rick - MVP
"jamie" <n...@spam.com> wrote in message
news:xEj4c.48778$6y1.1...@news20.bellglobal.com...
Tony Proctor
be the main cause on a modern machine, given the number of rows you quote.
However, the large number of selectSingleNode() calls may be a serious
performance issue. The last time I checked (it may have changed) the DOM
doesn't index or hash the nodes - they're simply linked together in a
hierarchical arrangement. This means the evaluation of XPath expressions
largely involves a sequential search.
Tony Proctor
"jamie" <n...@spam.com> wrote in message
news:xEj4c.48778$6y1.1...@news20.bellglobal.com...
jamie
> I know nothing about XML, so I can't comment on that part of your question;
> however, I'll bet all those DoEvents that you are executing are eating up a
> significant amount of time. Maybe you might want to execute the DoEvents
> once every 1000, or even 5000, loops of the For-Next block. If it doesn't
> take extraordinarily long to execute your bare loop, I consider removing the
> call to DoEvents altogether.
>
> Rick - MVP
>
>
Jamie
jamie
> The XML DOM is pretty memory intensive Jamie, but I wouldn't expect that to
> be the main cause on a modern machine, given the number of rows you quote.
>
> However, the large number of selectSingleNode() calls may be a serious
> performance issue. The last time I checked (it may have changed) the DOM
> doesn't index or hash the nodes - they're simply linked together in a
> hierarchical arrangement. This means the evaluation of XPath expressions
> largely involves a sequential search.
>
> Tony Proctor
>
Hi Tony, is there a better way to organize the data to make it more
efficient? The code snippet that I posted takes almost 20 minutes to
execute (which is rediculus to say the least...)
If I write each data entry with CreateTextNode would this improve things
at all?
Thanks,
Jamie
Tony Proctor
multiple nodes of a similar type, I'd recommend selectNodes() over repeated
calls to selectSingleNode(). It gives the XML loader (MSXML?) more scope for
optimisation, and prevents rescanning to re-evaluate similar XPath
expressions.
If you're trying to locate virtually every node, and store references to
them in variables, then I'd consider walking the XML tree yourself, and
storing the references in an array or collection as you go.
Tony Proctor
"jamie" <n...@spam.com> wrote in message
news:D4l4c.49025$6y1.1...@news20.bellglobal.com...
Joseph M. Ferris
In addition to what Rick suggested, regarding your DoEvents, I'll try to
help with the XML aspect of your questions.
jamie wrote:
> When I try and open this file and parse the data into arrays it takes
> forever!?!? (see the code snippet below...)
>
> I have 3 questions:
>
> 1. Is the xml format that I am using the most efficient for large data
> arrays? Would textnodes be better for the data elements?
Personally, I would group them together a little more like they were
objects. Looking at your example, the first time node corresponds to
the first temperature node, and the first measurement node, and the
second temperature node.
I would use something more normalized, like this:
<?xml version="1.0"?>
<results>
<result_item>
<time_interval>.3</time_interval>
<temperature>23</temperature>
<measurement1>293</measurement1>
<measurement2>291</measurement2>
</result_item>
</results>
But, you said that you have up to fifty thousand records (two-hundred
thousand individual values). If speed is your main concern, you are
best converting the child nodes to attributes. Why? Because you will
eliminate having to retrieve values from another level down in the
hierarchy. Instead of five node references per assignment, you are down
to one.
This is what I would use, for speed (watch for the wrap):
<?xml version="1.0"?>
<results>
<result_item time_interval=".3" temperature="23" measurement1="293"
measurement2="291"/>
</results>
This way, you would have X number of result_item nodes. If the data is
related, I would much prefer to keep it together like this. To
normalize the data storage in your code, I would use an array of a UDT
or classes to represent the data. The UDT could look more like the XML
structure, as well:
Private Type Results
dlbTimeInterval As Double
dblTemperature As Double
dblMeasurement1 As Double
dblMeasurement2 As Double
End Type
You would then only have one array to deal with, instead of four.
> 2. Is there a better way to parse the data?
Honestly, if all you are doing is reading the data, I would seriously
consider using the SAX parser. It is a little bit harder to use, but
the performance increase is substantial. The MSXML SDK documentation
actually has a really good example that would help you set up a SAX
parser. Basically, it reads through the XML document and raises events
as it comes across different aspects of the XML.
For the time being, let me show you how I would change your code to
reflect the XML changes that I suggested, along with the UDT. We will
still use the DOM, since we can probably get this into a reasonable
timeframe without having the additional code for the SAX parser.
In a new form, add a command button named, cmdTest and paste the
following code (also change the filename in cmdTest_Click to match the
new XML that you create that uses the attributes to store the data.
Watch for the wrap, too!):
Option Explicit
Private Type Results
dlbTimeInterval As Double
dblTemperature As Double
dblMeasurement1 As Double
dblMeasurement2 As Double
End Type
Private m_ResultSet() As Results
Private Const XMLERROR As Long = vbObjectError + 15001
Private Sub cmdTest_Click()
If LoadResults("d:\results.xml") = 0 Then
Debug.Print "Completed" & vbCrLf & vbCrLf
Else
Debug.Print "Failed" & vbCrLf & vbCrLf
End If
End Sub
Private Function LoadResults(FileSpec As String) As Long
On Error GoTo LocalHandler
Dim lngPointer As Long
Dim xdoDOMDocument As DOMDocument40
Dim xnoResultItem As IXMLDOMNode
Dim xnlResults As IXMLDOMNodeList
Debug.Print "Function Started: " & Timer
Set xdoDOMDocument = New DOMDocument40
If Not xdoDOMDocument.Load(FileSpec) Then
Err.Raise XMLERROR, "LoadResults()",
xdoDOMDocument.parseError.reason
End If
Debug.Print "XML Loaded: " & Timer
Set xnlResults = xdoDOMDocument.selectNodes("//result_item")
ReDim m_ResultSet(xnlResults.length - 1)
Debug.Print "Starting Parse: " & Timer
For Each xnoResultItem In xnlResults
m_ResultSet(lngPointer).dlbTimeInterval =
xnoResultItem.Attributes(0).Text
m_ResultSet(lngPointer).dblTemperature =
xnoResultItem.Attributes(1).Text
m_ResultSet(lngPointer).dblMeasurement1 =
xnoResultItem.Attributes(2).Text
m_ResultSet(lngPointer).dblMeasurement2 =
xnoResultItem.Attributes(3).Text
lngPointer = lngPointer + 1
Next
Debug.Print "Complete: " & Timer & vbCrLf & vbCrLf
LoadResults = 0
Exit Function
LocalHandler:
Debug.Print "Terminating due to error: " & Timer
LoadResults = 1
End Function
Using the first normalized XML structure that I gave you, it took almost
seven minutes to process. Ick. We wouldn't want to use that. That is
why the code that I provided you uses the second format. The total time
to process fifty thousand records? 3.5 seconds from start to finish
with a completely populated UDT. Pretty sweet, eh? You could say that
doing it this way would be more built for speed than comfort. I only
wish that I could say the same thing about myself. ;-)
> 3. If XML can't handle this much data efficiently, what is another
> technique I can use (it must be hierarchical)
Just guessing, but your file is probably around eight or nine megabytes
on disk when there are 50,000 items, right? Part of the time that you
are parsing is also dedicated to loading the file into memory. You can
also optimize your code further, by loading the XML into a Stream object
and then populating the XML object through the LoadXML method of the DOM
object. This is not a major optimization, but if your application is
time-critical, every little bit helps. Using the attribute method also
reduces my sample file to just around four and a half megabytes. Less
physical space is less file storage and less time for I/O.
XML is the perfect solution for this sort of application. The thing
with XML, much like many things in our line of work, is that there are
multiple ways to accomplish a given task. Let me know if you get
everything working! If you have any problems getting the sample to
work, send me an email and I will send you the project and the sample XML.
--Joseph
jamie
> Jamie -
>
> In addition to what Rick suggested, regarding your DoEvents, I'll try to
> help with the XML aspect of your questions.
>
Thanks Joseph, I will impliment your suggestions and let you know how I
make out :-)
Jamie
Bonj
> 2. Is there a better way to parse the data?
Possibly a non-XML file?
>
> 3. If XML can't handle this much data efficiently, what is another
> technique I can use (it must be hierarchical)
You can use multiple files for each level of the hierarchy in a similar
structure to a set of hierarchical database tables. (Or just use a
database?)
Joseph M. Ferris
>>2. Is there a better way to parse the data?
>
>
> Possibly a non-XML file?
<?xml version="1.0"?>
<ben_response>
<opinion ignorance="true" source="bonj">XML sucks. I
have never used it, but is sucks anyway.
</opinion>
<reality sarcasm="true">Yes, because the 7 x 10^(-5)
seconds per row from the XML-based solution in this
thread is just unacceptable. Especially if you consider
that over half of that time was the time that the
operating system took to open the file.
</reality>
</ben_response>
jamie
> You can use multiple files for each level of the hierarchy in a similar
> structure to a set of hierarchical database tables. (Or just use a
> database?)
>
This system use to spit out multiple data files per mearsurement... I
am currently updating the system because 4 or 5 files per measurement
was fine back in the day....but it can be done much smarter than this.
Se Joseph's post above for a better solution.
Jamie
Bonj
else are you trying to plug it to everybody?! XML's just... it's ....well,
it's just for *ponces*.
"Joseph M. Ferris" <joseph...@cox.net> wrote in message
news:uEMkM0GC...@TK2MSFTNGP12.phx.gbl...
Joseph M. Ferris
thread and asked a question about it. You obviously had nothing
valuable to add so you just started bashing something that you have no
knowledge of. By my following up to a thread, you instantly assume that
I am plugging it. Well, my friend, questions usually call for answers.
It is obvious that you don't care for any of the ones presented in
this thread.
The original poster had already chosen the technology and was attempting
to follow through. Just because the original poster can establish and
follow requirements, we should not expect you to have to understand that
concept. Your childish rants and constant chiding of people who choose
to do things that you don't understand or don't care to learn about only
goes to prove that you have nothing valuable to add to a conversation.
Why don't you take a second to look at the code I provided in this
thread? You always ask for a good reason to use XML, and this is a
fairly basic example. Try picking a post apart on its merit and not
your personal feelings, you might just gain some respect around here.
--Joseph
Bonj
'thing' I would have used, so I advised him how I would have solved the
problem, knowing that the extra overhead of not parsing the tags and
rereading the file would be eliminated. I can't advise him on a technology I
don't like, or even think *is* a technology.
If you want to use XML or even advise others to, fine, but why the need for
the full-scale advertising campaign if you don't profit from the amount of
XML sold?
"Joseph M. Ferris" <joseph...@cox.net> wrote in message
news:uyIaSoIC...@TK2MSFTNGP12.phx.gbl...
Bonj
about VB than he does (and also languages superior to VB) and I know. To
read a file in XML format and for the XML parser to arrange it into a
hierarchy, which is presumably what it does, the file will probably have to
be read and re-read multiple times. If you use your own algorithm for
reading the data sequentially, you will probably only have to only read it
once - as you could also play around with the data storage protocol to see
if less normalization of the data increased the speed of it, depending on
what format the data had to be presented in. You would thus be able to run
it a lot faster. Just my opinion, but listen to others by all means....
"jamie" <n...@spam.com> wrote in message
news:vTo4c.50092$6y1.1...@news20.bellglobal.com...
Jim Carlock
up, to maybe 100000 or 500000. But it's all going to depend
upon the actual amount of processing that is going on.
Simple queries are extraordinarily quick and I wouldn't place
any kind of other processing in a simple query loop.
I've created reports in the past using Microsoft Access, that
have read millions of records and performed a variety of
calculations on the records, and in turn the month end reports
were 1000 pages in print and were AR statements going out
to Home Depot, Ace Hardware, Lowes and a variety of other
smaller hardware stores that bought paint.
I won't put down XML, and I'm sure it can be made to be
processed almost as quickly as Access can process things, so
with the current speed of processors, and even dating back to
100MHz processors... I think it's safe to bump the numbers
up into the 100 thousands.
Also, when dealing with data, it's important to start thinking in
terms of SQL and in terms of Tables, Recordsets and Records.
I didn't add queries into that list because queries are one of two
forms that act upon the items I listed. Queries are used to either
modify sets of data or the presentation of sets of data.
It makes things a little easier to understand. You get a table of
records, or you get a particular record, or you update a set of
records or a subset of the table.
XML is going to be a bit slower than reading from a linked list
of records, because on every read of every record, there is
processing of the XML tags. This extra processing is what makes
it slower. Because in effect, you don't deal with tables or sets
of data anymore, but you deal with elements of data, each element
being represented by whats in a set of tags.
Hope that helps.
--
Jim Carlock
http://www.microcosmotalk.com/
Post replies to the newsgroup.
Jim Carlock
http://www.nsbasic.com/ce/info/nsbce/interview.shtml
It's an interview with Bjarne Stroustrup about C++ and it probably
can extend to XML as well.
XML can be made to do things quickly, but it really depends upon
how the XML parsing machine works and I thank Joseph Ferris
for his help about the details of attributes and such. Really good
information there.
jamie
> Ah now you see, it *isn't* a better solution. Trust me, I know a lot more
> about VB than he does (and also languages superior to VB) and I know.
Bonj, Newsgroups are not a forum for bragging, no one wants to hear it.
> To
> read a file in XML format and for the XML parser to arrange it into a
> hierarchy, which is presumably what it does, the file will probably have to
> be read and re-read multiple times.
Nope, store scientific data...if it is loaded it is loaded once the the
graphing compnent...
>If you use your own algorithm for
> reading the data sequentially, you will probably only have to only read it
> once - as you could also play around with the data storage protocol to see
> if less normalization of the data increased the speed of it, depending on
> what format the data had to be presented in. You would thus be able to run
> it a lot faster. Just my opinion, but listen to others by all means....
Thanks for your opinion, but your approach takes too much development
time, the client will not be clocking the data retrieval time, they just
want it to work. Joseph, has given me tips on the XML approach and
loading the data now is super fast... now this development is sorted
out, I can move on to the next issue.
Thanks for your responses,
Jamie
jamie
Thanks Kim & Rick,
My problem was how I designed the XML layout, Joseph has pointed out a
much more efficient structure for me to be using
Regards,
Jamie
Joseph M. Ferris
> Ah now you see, it *isn't* a better solution. Trust me, I know a lot more
> about VB than he does (and also languages superior to VB) and I know. To
Thanks, Ben... I haven't laughed that hard in years!
Bonj
some concepts such as the preference of a 'neat' code structure that some
people have, and on the reusability score, but I think the article would
probably be a whole lot more believable if applied to Joseph M Ferris and
his "XML"!
It also just goes to illustrate the hidden miseries of these so called
'protocols' and 'technologies' like XML in that the more they are used, the
more project managers we have thrust upon us. (Fortunately, we don't have
any project managers in our dept at work - thank god!)
"Jim Carlock" <anon...@127.0.0.1> wrote in message
news:eWIELBRC...@TK2MSFTNGP12.phx.gbl...
Bonj
> graphing compnent...
Right - then you don't need a particularly complex algorithm to read your
custom compact data structure then do you.
>
> Thanks for your opinion, but your approach takes too much development
> time, the client will not be clocking the data retrieval time, they just
> want it to work.
Right - that's fine, if you want RAD over quality of code (as is often the
case) then bashing together something with as little code as possible, and
sod the overhead, is probably going to keep them happy. I was under the
impression you were building an application to sell - but it sounds like
it's for your 9-5 job, so fudging together something in XML if that's what a
lot of the code that's already been written uses, is probably fine - if
slower. But if you say they don't want speed, then that won't be of a
concern. I suppose this gives you more time in 2 respects - you get time off
when you've finished the development early, and you get time off while
you're waiting for it to finish running.
Joseph, has given me tips on the XML approach and
> loading the data now is super fast... now this development is sorted
> out, I can move on to the next issue.
Yep - that's fine, like I say if you've already built in dependencies on XML
then you'll obviously want to keep on using it. But just beware that he *IS*
probably only promoting it simply to fatten his own reputation, sales, and
thus, wallet. The building of an application is only important if it uses
XML, and then the aim is not for it to work right and be maintainable but
have as much XML as possible, the reliance on XML will then further increase
your dependence on it, causing it to eventually spread.
Joseph M. Ferris
> I quite like that article, even though I think he probably didn't appreciate
> some concepts such as the preference of a 'neat' code structure that some
> people have, and on the reusability score, but I think the article would
> probably be a whole lot more believable if applied to Joseph M Ferris and
> his "XML"!
Actually I read the article. It is another example of someone who can't
accept or apply new concepts and move forward. So are you in the same
boat as this Luddite who thinks object oriented programming and code
reusability are passing fads?
For what it is worth, since you never comment on the facts I present, I
use XML in an Enterprise. You have admitted to never developing
distributed applications, so who in the hell are you to judge technology
that you have never used - or even had a reason to in your limited
exposure to the real world?
I recommend it from *knowledge* gained through *experience*. You have
not had the opportunity to use it, so does that make it a bad
technology? Apparently in your biased little world, it does. If you
don't have the desire to try to stay current with changes in the
industry, you can be left behind in the employment market like so many
others have been. That is your choice. Just try to be an adult and not
berate other people who actually want to expand their knowledge.
> It also just goes to illustrate the hidden miseries of these so called
> 'protocols' and 'technologies' like XML in that the more they are used, the
> more project managers we have thrust upon us. (Fortunately, we don't have
> any project managers in our dept at work - thank god!)
No project managers? That is not surprising.
Consider the real world were computers can be used to talk to each other
in a standardized format. Not all applications are built on the
desktop, and everyone's idea of a good time is not parsing text files.
You need to understand the fact that all of us draw experience from
different facets of the spectrum. I speak from experience. Whether you
like it or not, your dislike of something is not going to make it go
away, and your childish insults and tantrums only look you make like a fool.
Like I have told you time and time again, try to argue an issue on its
merits.
--Joseph
Joseph M. Ferris
> Yep - that's fine, like I say if you've already built in dependencies on XML
> then you'll obviously want to keep on using it. But just beware that he *IS*
> probably only promoting it simply to fatten his own reputation, sales, and
> thus, wallet. The building of an application is only important if it uses
> XML, and then the aim is not for it to work right and be maintainable but
> have as much XML as possible, the reliance on XML will then further increase
> your dependence on it, causing it to eventually spread.
Do you actually read the things you spout off about? How does someone
profit off of using XML when the parser is free and the specs are driven
by the community? Are you really one of those Microsoft insiders who
are afraid of open standards? Definately sounds like it...
Yes, I am sure that the two dozen lines of code that I gave him are
going to bring him into the evil empire. Code so simplistic that can
accomplish that much work must have an underlying agenda. There is just
*so* much XML in there... Judging what Jamie is trying to do, I will
imagine that is less than 2% of his total code, if that.
And migrating away from an XML structure would be just so difficult,
providing that all of the code is localized inside of a single function
and immediately places it into a UDT. Wait! Are UDT's part of another
evil empire, Ben? I should ask you first, since you are such an expert
on everything in your own little world.
Once again, try to argue based upon the merits of the technology. It is
no wonder that people don't take you seriously anymore.
--Joseph
Joseph M. Ferris
> I quite like that article, even though I think he probably didn't appreciate
> some concepts such as the preference of a 'neat' code structure that some
> people have, and on the reusability score, but I think the article would
> probably be a whole lot more believable if applied to Joseph M Ferris and
> his "XML"!
Leave it to Ben to find a level of personal association and
understanding in a piece of satire. Irony is so wonderful. ;-)
--Joseph
Bonj
a.. It's too complex for what it does.
b.. It's too hard for programs to parse and too verbose and unreadable for
humans to write.
c.. The benefits of "everyone is using XML, so we should too" are usually
outweighed by the costs of time, training and mistakes involved in
understanding it.
d.. Because it's increasingly used for data interchange, it is promoted as
a data storage model. XML is only a data encoding format.
e.. Encourages non-relational data structures
f.. Poor OnceAndOnlyOnce syntax factoring
g.. It's a poor copy of EssExpressions
"Joseph M. Ferris" <joseph...@cox.net> wrote in message
news:%23DbkN4R...@TK2MSFTNGP11.phx.gbl...
Joe "Nuke Me Xemu" Foster
> Thanks for your opinion, but your approach takes too much development
> time, the client will not be clocking the data retrieval time, they just
> want it to work. Joseph, has given me tips on the XML approach and
> loading the data now is super fast... now this development is sorted
> out, I can move on to the next issue.
Why are you wedded to XML? Is the code that creates the file(s)
also written in VB, and do you have control over it? If so, you
can always use Get and Put with a Binary file, and you can be as
hierarchical as you want with nested VB Types...
Type Measurement
Time As Double
Temp As Double
Meas(1 To 2) As Double
End Type
Type Measurements
Data() As Measurement
End Type
Sub TestPut(ByVal Path As String, ByVal Count As Long)
Dim M As Measurements
ReDim M.Data(1 To Count)
Dim i As Long
For i = 1 To Count
With M.Data(i)
.Time = i / 10
.Temp = 30 + i / 100
.Meas(1) = i And Not 1
.Meas(2) = -i
End With
Next
Dim Start As Single: Start = Timer
Dim fd As Integer: fd = FreeFile
Open Path For Binary Access Write Lock Write As #fd
Put #fd, , M
Close #fd
Debug.Print Timer - Start
End Sub
Sub TestGet(ByVal Path As String)
Dim M As Measurements
Dim Start As Single: Start = Timer
Dim fd As Integer: fd = FreeFile
Open Path For Binary Access Read Lock Write As #fd
Get #fd, , M
Close #fd
Debug.Print Timer - Start;
Debug.Print LBound(M.Data); UBound(M.Data)
End Sub
TestPut and TestGet take just under 0.5 sec on an ancient P233MMX.
--
Joe Foster <mailto:jlfoster%40znet.com> On the cans? <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above They're coming to
because my cats have apparently learned to type. take me away, ha ha!
Bonj
> use XML in an Enterprise. You have admitted to never developing
> distributed applications,
No, I haven't, I do develop distributed applications.
> so who in the hell are you to judge technology
> that you have never used - or even had a reason to in your limited
> exposure to the real world?
I am someone to judge based on my experience of being someone who is capable
of filtering out good technology from pointless fads, and it is my
recommendations to the appropriate been-counters of where the line between
them is drawn and resulting implementations that get me on in the world,
rather than using a particular technology simply because it exists. But then
again, if I'd invented it , it would be a different story...
>
> I recommend it from *knowledge* gained through *experience*. You have
> not had the opportunity to use it, so does that make it a bad
> technology?
I don't know when you'll learn or accept this, but it's not about me never
having the opportunity to use it - I'm sure I could find plenty of
opportunities to use it if it was useful, it's a matter of never having the
*need* to use it. FWIW, I use a *database*. I don't know whether or not you
know what that is, but it handles large volumes of data efficiently aswell
as being capable of handling hierarchical representation. It also implements
security.
> Apparently in your biased little world, it does. If you
> don't have the desire to try to stay current with changes in the
> industry, you can be left behind in the employment market like so many
> others have been. That is your choice. Just try to be an adult and not
> berate other people who actually want to expand their knowledge.
Well, like I say - I'm not convinced that you didn't *invent* XML as you've
not actually denied it, which would explain your seeming incessance at
trying to get offices 'addicted' to it. Given this, I can perfectly
understand your reasons for trying to make people think that by using it
they will be 'staying current with changes in the industry', as if I'd
invented a technology I'd be doing the same political game - but if I
invented a technology it would just be better than XML....otherwise I
wouldn't bother trying to market it.
>
> > It also just goes to illustrate the hidden miseries of these so called
> > 'protocols' and 'technologies' like XML in that the more they are used,
the
> > more project managers we have thrust upon us. (Fortunately, we don't
have
> > any project managers in our dept at work - thank god!)
>
> No project managers? That is not surprising.
>
> Consider the real world were computers can be used to talk to each other
> in a standardized format.
Is SQL not standard enough for you?
Bonj
> profit off of using XML when the parser is free and the specs are driven
> by the community? Are you really one of those Microsoft insiders who
> are afraid of open standards? Definately sounds like it...
No, definitely not - I'm just as much up for free, standard libraries as I
am for making commercial, proprietary programs and profiting from them as
much as the next man - it's just I would only release it if it was GOOD -
and I would certainly only thrust it upon people if it was *really* good!
>
> Yes, I am sure that the two dozen lines of code that I gave him are
> going to bring him into the evil empire. Code so simplistic that can
> accomplish that much work must have an underlying agenda. There is just
> *so* much XML in there... Judging what Jamie is trying to do, I will
> imagine that is less than 2% of his total code, if that.
Which begs the question that if it's so little code to do so much work, how
much actual control is he having over the process? Or is the structure of
his data all being decided by the whim of the 'XML parser'?
>
> And migrating away from an XML structure would be just so difficult,
> providing that all of the code is localized inside of a single function
> and immediately places it into a UDT. Wait! Are UDT's part of another
> evil empire, Ben? I should ask you first, since you are such an expert
> on everything in your own little world.
Probably not, seeing as they don't require an additional DLL. But if UDTs
are used, then some decision must have been made about how generic the
algorithms for the program are going to be. Therefore, XML doesn't *provide*
the genericity, it only serves to divert effort into a different way of
implementing it...
Joseph M. Ferris
actually presented by you, but are merely copied off of a web site. To
be exact from: http://c2.com/cgi/wiki?XmlSucks
With a page name like that, it hardly came from an objective source, did
it? ;-)
Bonj wrote:
> Perceived problems with XML:
> a.. It's too complex for what it does.
It is hardly complex. HTML is derived from SGML, as is XML. XHTML is
the marriage of HTML and XML. $12/hr "web developers" can handle both
with ease.
The author of the article percieves it as being too complex for what it
does. That is an opinion.
> b.. It's too hard for programs to parse and too verbose and unreadable for
> humans to write.
Look at the sample I provided for Jamie. That code is very, very basic.
To set up a parser to handle the same task with a text file will take
approximately the same amount of code. Granted, you have to learn an
object model to use the parser, but learning an object model is quite
common amongst Visual Basic developers.
Hierarchal structures are hardly unreadable, and even if it were, people
write software to generate data. XML is data, plain and simple.
Verbosity is part of the price that is required to have the ability to
present data in a hierarchal, and even object-driven models.
Like I have said in the past, I have a serialization component that can
save the state of a COM+ component - including all of its attributes.
It serializes it to a text file that mimics the structure of the object.
That XML can be placed on another server and be used to create that
COM+ components state to match the one in memory on the first server.
Originally, this was done without XML. The data file was only about
20%, but it was very hard to follow since it was storing nested
properties in a flat file. But, the code to parse the flat text file
was over twice as big as the same code that now handles the XML. Why?
Because I did not need to write handling code to convert the flat file
into a hierarchal structure. On top of that, I could attach attributes
to a piece of data. It was just like having properties on an object.
> c.. The benefits of "everyone is using XML, so we should too" are usually
> outweighed by the costs of time, training and mistakes involved in
> understanding it.
Training issues? Everyone is using Windows, lets keep on using DOS and
writing batch files... It is to costly and takes too much time to get
our users up on Windows. I remember that argument well.
If you are in a business where you need to sell your services or
products to the public, they demand that you use the most current
techologies. Don't blame the developers or the project managers -
remember that "the customer is always right".
We offer training sessions at work for new technologies as we accept
them into our development practices - which is something that more
companies should do. Of all of the different training sessions that I
have been involved in, I can say that XML was one of the easier concepts
for people to grasp. These are the same people who could not grasp the
fact that the SQL Server was on its own machine and that other machines
"talked to it". ;-)
> d.. Because it's increasingly used for data interchange, it is promoted as
> a data storage model. XML is only a data encoding format.
No. XML is a logical storage structure. What the user does with it is
driven by their needs. SOAP is billed as a data transport model. Does
SOAP use XML? Yes. Are all XML documents SOAP compliant? No.
The author is confusing the application of usage standards with the
standards that govern the structure of XML on a whole.
> e.. Encourages non-relational data structures
And flat files don't? Data structures on their own can not define any
sort of data relationships. It is the responsibility of the person who
defines the data structure, whether it be an analyst, developer, etc. to
correctly define the data structures that are going to be used.
> f.. Poor OnceAndOnlyOnce syntax factoring
See e. Nothing prevents a user from creating a lookup section in an XML
document and using pointers to refer to a single definitive data fragment.
> g.. It's a poor copy of EssExpressions
I have no experience with EssExpressions, but glancing at the text that
the article got this from, I can see that the comparison is weak. Just
because they both deal with hierarchal data does not make one a copy of
another.
But, I am not going to argue this point, since I have no experience. I
prefer to actually back up my arguments with experience, and I can not
do so here. Anyone here actually ever used SymbolicExpressions that can
enlighten us?
--Joseph
Joseph M. Ferris
> I don't know when you'll learn or accept this, but it's not about me never
> having the opportunity to use it - I'm sure I could find plenty of
> opportunities to use it if it was useful, it's a matter of never having the
> *need* to use it. FWIW, I use a *database*. I don't know whether or not you
> know what that is, but it handles large volumes of data efficiently aswell
> as being capable of handling hierarchical representation. It also implements
> security.
Databases are a storage methodology and are not intended to be used to
transport data between logical components and systems. Apples and Oranges.
By the way, don't feel the need to try to talk down to me. I was a
database administrator before I was employed as a software developer.
That should be obvious, since I know the different uses for a database
and an XML document.
> Well, like I say - I'm not convinced that you didn't *invent* XML as you've
> not actually denied it, which would explain your seeming incessance at
> trying to get offices 'addicted' to it. Given this, I can perfectly
> understand your reasons for trying to make people think that by using it
> they will be 'staying current with changes in the industry', as if I'd
> invented a technology I'd be doing the same political game - but if I
> invented a technology it would just be better than XML....otherwise I
> wouldn't bother trying to market it.
You caught me, Ben... I *am* the W3C. Sheesh...
I was in a Delphi shop, but I convinced the people to use Visual Basic.
I didn't invent that either, in case you were wondering.
> Is SQL not standard enough for you?
SQL is used to query data from a database that physically exists to hold
data. XML is used to transport and store data between logical tiers of
the Enterprise. If you can not see the difference, than I don't know
what else to tell you. But once again, you are comparing apples to
oranges. XML and SQL coexist quite nicely. Since you are such a "SQL
Expert" maybe you have seen the XMLRPC capabilities that are built in to
SQL Server 2000?
--Joseph
Joe "Nuke Me Xemu" Foster
> Bonj wrote:
> > I quite like that article, even though I think he probably didn't appreciate
> > some concepts such as the preference of a 'neat' code structure that some
> > people have, and on the reusability score, but I think the article would
> > probably be a whole lot more believable if applied to Joseph M Ferris and
> > his "XML"!
>
> Actually I read the article. It is another example of someone who can't
> accept or apply new concepts and move forward. So are you in the same
> boat as this Luddite who thinks object oriented programming and code
> reusability are passing fads?
You did read the fine print at the very bottom, right?
--
Joe Foster <mailto:jlfoster%40znet.com> KrazyKookKultz! <http://www.xenu.net/>
Joseph M. Ferris
> You did read the fine print at the very bottom, right?
Yep. Which is what made it so much funnier that Ben could associate
with the contet of the article. ;-)
--Joseph
Bonj
between two applications.... right? If that's the case, both sides have to
be programmed - whether listener and sender are the same program or two
different ones, either way - each side has to be programmed to either
translate the data structure into a protocol if it's the sender, or
translate the protocol into a data structure if it's the receiver, or both -
and the notion that using XML can make the programming of this part of the
application easier is the point you're trying to convince me of...right?
Well, OK... in some situations it might - but you'll not convince me that it
completely replaces the *need* to program this part of the application (or
maybe haven't yet...). This is what I meant, I'm just saying XML isn't the
'magic wand' you appear to be making it out to be.
Don't get me wrong, I was only joking when I said you invented it, and I
didn't mean to talk down to you so no offence intended - it's just you
seemed to be talking as if you were on the XML marketing campaign, that's
all.... sorry for any offence.
> Databases are a storage methodology and are not intended to be used to
> transport data between logical components and systems.
This sounds like incredibly vague management speak to me.
(1) Can you give a specific, real world example of how XML actually does
something itself - e.g. actually gives the program the metadata information
it needs to display the data, aswell as the data itself? Is it genuinely
something *more* than just a way of storing and retrieving data from a file
(together with a library to do this)?
(2) Or is it simply that it really is nothing more than that, but it's just
it's got an incredibly neat style and logical generic manner that makes it
quite useful even though it is simply a data storage and retrieval library?
I'm currently cynical that (2) is the truth and not (1), and that it is its
just its neat design and genericity as this type of component that makes it
good. But maybe you'll care to clarify?
And 'communication'? Surely communication relates to the network - when the
rules of minimising data and round trips apply - it's up to the application
to decide what this data is. Are you saying the main advantage of XML is to
transmit data between applications running on different PCs that don't have
access to SQL databases - if so then (1) above springs to mind again.
Bonj
"Joe "Nuke Me Xemu" Foster" <j...@bftsi0.UUCP> wrote in message
news:O8gXGHWC...@TK2MSFTNGP11.phx.gbl...
Bonj
arsed to.
"Joe "Nuke Me Xemu" Foster" <j...@bftsi0.UUCP> wrote in message
news:OlcRXwVC...@TK2MSFTNGP12.phx.gbl...
Bonj
> it? ;-)
Well, someone must have felt strongly enough to have set up a page with that
name...
Joseph M. Ferris
> So XML is a method by which complex data structures can be communicated
> between two applications.... right? If that's the case, both sides have to
> be programmed - whether listener and sender are the same program or two
> different ones, either way - each side has to be programmed to either
> translate the data structure into a protocol if it's the sender, or
> translate the protocol into a data structure if it's the receiver, or both -
> and the notion that using XML can make the programming of this part of the
> application easier is the point you're trying to convince me of...right?
> Well, OK... in some situations it might - but you'll not convince me that it
> completely replaces the *need* to program this part of the application (or
> maybe haven't yet...). This is what I meant, I'm just saying XML isn't the
> 'magic wand' you appear to be making it out to be.
> Don't get me wrong, I was only joking when I said you invented it, and I
> didn't mean to talk down to you so no offence intended - it's just you
> seemed to be talking as if you were on the XML marketing campaign, that's
> all.... sorry for any offence.
Thank you for the apology. Sorry if I came off rather gruff. ;-)
XML is not a method, it is a means. It is just data. XML itself does
not do anything. There are other related technologies, such as XSL,
that do actually act upon the data and translate the data into other
formats. Things like XSL provide additional data, that through a
parser, do something to the XML - whether it is converting it to HTML,
text, RTF, etc.
In the sense you need to program the caller and the callee, that much is
true. Much like you could do with any reusable code, you standardize
the calling methods between the applications and then the code is truly
resusable - deploying a single component that can be called to serialize
and deserialize the data. For arguments sake, call them a reader class
and a writer class. As the first application needs to store values, it
writes them to the properties of the writer class. Once the XML is
requested, you call a method in your class that will create the XML and
return it to the application.
The reader works much the same way. The XML is given to reader class by
the second application, and is stored in a way such that the application
can access the data and store it a format that can be easily accessed by
the application. This allows the application to format it to the
business specific needs of that application. The reader might store the
deserialized XML inside of collection, which the application can access
and store in whatever form it needs.
Once the reader and writer components are written, they don't ever need
to be written again. (It is pretty close to a real world example of a
component that I have written.)
I have never claimed that XML is a magic technology, nor have I implied
that it does anything on its own. If you have taken something that I
have said to mean so, I do apologize. Conversely, I thought that I have
stressed that it is a means to store data and that it provides an
additional means to establish standards for reusability and the
opportunity for application interoperation.
>>Databases are a storage methodology and are not intended to be used to
>>transport data between logical components and systems.
>
>
> This sounds like incredibly vague management speak to me.
> (1) Can you give a specific, real world example of how XML actually does
> something itself - e.g. actually gives the program the metadata information
> it needs to display the data, aswell as the data itself? Is it genuinely
> something *more* than just a way of storing and retrieving data from a file
> (together with a library to do this)?
Actually, I can, as long as you allow me the use of the parser. You
have an XSL template that is used to generate an HTML report. XSL is a
way of using XML to store commands to translate the data into another
format. The same XSL will always work with an XML document that adheres
to a specific schema.
Using the XSL file and the XML file, you can perform a translation
through the parser. I have used it to translate an XML document into a
XHTML document for report generation. Within an application, a request
is made for an XML document contain configuration settings on a
component. The component returns its settings and properties as XML.
The application that requested the XML runs the XSL translation against
it and returns valid XHTML or HTML, which can be stored to disk,
uploaded to a server, or directly displayed in the browser.
> (2) Or is it simply that it really is nothing more than that, but it's just
> it's got an incredibly neat style and logical generic manner that makes it
> quite useful even though it is simply a data storage and retrieval library?
>
> I'm currently cynical that (2) is the truth and not (1), and that it is its
> just its neat design and genericity as this type of component that makes it
> good. But maybe you'll care to clarify?
Much like everything, it is only as much as you apply it to. It doesn't
do anything on its own, but with other technologies like XSL (which is a
specific implementation of XML with a predefined purpose) it is not only
capable of storing data, but it is in a standardized format that other
related technologies can transform and further utilize the data in the XML.
The goal of XML is not just to store data, but to provide a
standardization that other technologies can be written around XML.
Whether it is a way to search through the files, change the data, or
whatever, it is a basic building block that provides a structure that is
expected and can be built off of to perform routine tasks.
> And 'communication'? Surely communication relates to the network - when the
> rules of minimising data and round trips apply - it's up to the application
> to decide what this data is. Are you saying the main advantage of XML is to
> transmit data between applications running on different PCs that don't have
> access to SQL databases - if so then (1) above springs to mind again.
>
> Apples and Oranges.
Not really. File size is the only drawback I have ever had with XML.
The transport is larger, but when designed properly it is also more like
an object representation of the data that is being transported. It is a
matter of transporting only the data that you need. I don't recommend
XML for PC to PC communications. I do, however, recommend it for Server
to Server communications. ;-) Especially when the servers exist on the
same network. If you are sending XML documents through the Ether of the
Internet, you must make sure that you have as small a document as
possible to transport the data. But, in reality, most businesses (which
are the target application uses for XML) have higher bandwidth
connections to the Internet. It is not a matter of 'hogging' the
bandwidth, as much as it is utilizing what you have. Your requirements
need to allow you to provide this as a solution.
I keep coming back to my favorite example usage, which is a real world
example:
Component A is a monitoring and load balancing service on Server A. It
analyzes the performance of Components B, C, D, E, and F. Componenet A
determines that the other components are performing at or near capacity.
Component A wants to take the configuration settings of Components B,
C, D, E, and F and persist them to a stand-by server, which is Server B.
It serializes the properties of the components and sends it to another
Component A, this time on Server B. Server B deserializes the XML into
new instaces of Server A's Components B, C, D, E, and F. Now, when
Server A has a task to run, it can delegate it to Server B and know for
a fact that the components are configured the same way.
Specialized problems require specialized solutions. I don't think XML
is for everything, but I do use it for transporting data between
components, storing and transporting hierarchal data, and storing and
transporting object related data. I do not recommend it for other
purposes, with an allowance for case-by-case exceptions, but that only
relates to me. If someone else asks how they would get a XML to do a
certain thing in a given situation, I would answer the question. It is
not my place to questions a person's usage of it, since I would assume
that it meets their requirements for the task at hand.
--Joseph
Jim Carlock
Just click on the Learn XML tag there.
It is probably the most beautiful explanation of XML that I've ever
seen anywhere. They've done a really good job at explaining things
there. If you know stuff about XML or if you're an not-so-absolute
beginner (I almost qualify as surpassing beginner), it's a great link to
and reference.
Joseph M. Ferris
More than that, there are also good explations of XML-related
technologies there, as well. When I was just learning XML a couple of
years ago, I spent a lot of time there. ;-)
--Joseph
Bonj
> true. Much like you could do with any reusable code, you standardize
> the calling methods between the applications and then the code is truly
> resusable - deploying a single component that can be called to serialize
> and deserialize the data. For arguments sake, call them a reader class
> and a writer class. As the first application needs to store values, it
> writes them to the properties of the writer class. Once the XML is
> requested, you call a method in your class that will create the XML and
> return it to the application.
> Once the reader and writer components are written, they don't ever need
> to be written again. (It is pretty close to a real world example of a
> component that I have written.)
So ...
(1) can it be used as a serialization method for VB classes where the code
to generate the XML for the serializer of a particular class doesn't have to
be redesigned with each class,
or, (2) is an 'XML serializer' not capable of being forward compatible to
any new classes you might create after you wrote the serialization
component?
or, (3) Or is it half way between the two, like you have one piece of code
but a different XML template for each class?
If it's (1) or (3), do you have any examples of this?
>
> Actually, I can, as long as you allow me the use of the parser. You
> have an XSL template that is used to generate an HTML report. XSL is a
> way of using XML to store commands to translate the data into another
> format. The same XSL will always work with an XML document that adheres
> to a specific schema.
What can this XSL template contain, report specifications maybe? Such as
group by headers? column specifications? sub-totalling specifications? Or
just row and column and formatting specifications? Or none of these? (please
be un-vague..!)
> Much like everything, it is only as much as you apply it to. It doesn't
> do anything on its own, but with other technologies like XSL (which is a
> specific implementation of XML with a predefined purpose) it is not only
> capable of storing data, but it is in a standardized format that other
> related technologies can transform and further utilize the data in the
XML.
As I say I would consider it *very* interesting if it was capable of
applying a (series of) predefined, complex formatting standard(s) to an HTML
report to be generated from an SQL database, especially if it was easily
integratable with / or even supported, features such as at least two levels
of genericity for the templates, and client-side caching of the data...any
starters? My boss would probably like something like that!
Rick Rothstein
Thanks for posting the link... this looks like a great website to check out.
Rick
Joseph M. Ferris
> So ...
> (1) can it be used as a serialization method for VB classes where the code
> to generate the XML for the serializer of a particular class doesn't have to
> be redesigned with each class,
> or, (2) is an 'XML serializer' not capable of being forward compatible to
> any new classes you might create after you wrote the serialization
> component?
> or, (3) Or is it half way between the two, like you have one piece of code
> but a different XML template for each class?
It is forward compatible with any future class that implement the
required interface and provide values within two predefined functions.
The component that does the serialization and deserialization is a constant.
I have not gotten the wild hair yet, but I have been considering writing
an Add-In that will write the code in the two functions for me so that I
don't need to even deal with that.
> If it's (1) or (3), do you have any examples of this?
I'll put it up on PlanetSourceCode tommorrow. I will write an example
application to go with it so that you can see how it works.
It is based on the code at:
http://www.xml.com/pub/a/1999/09/serialization/index3.html
I would tell you that you could just download the code that is there,
but it does not work out of the box. I've taken the time to get it
working, cleaned it up, and commented it a bit.
I'll post back to this thread when I have it uploaded.
> What can this XSL template contain, report specifications maybe? Such as
> group by headers? column specifications? sub-totalling specifications? Or
> just row and column and formatting specifications? Or none of these? (please
> be un-vague..!)
XSL provides the abilities to utilize stylesheets, much like how CSS is
to HTML. Specifically, XSL provides the ability to apply conditional
logic to data in the XML, sort data in the XML, and format data in the
XML. XSL evaluates an XPath expression in the XML. For each of the
matches, it can apply one or more templates to the data. The template
contains the logic that will modify the data. The template might write
data to a table, apply HTML formatting attributes, generate VBScript, etc.
The best description of the functionality available would be at:
http://www.w3schools.com/xsl/default.asp
> As I say I would consider it *very* interesting if it was capable of
> applying a (series of) predefined, complex formatting standard(s) to an HTML
> report to be generated from an SQL database, especially if it was easily
> integratable with / or even supported, features such as at least two levels
> of genericity for the templates, and client-side caching of the data...any
> starters? My boss would probably like something like that!
XSL is great for this. Just so I point you in the right direction, what
are we talking about on the back end? Are we just talking a standard
ODBC datasource, or can we specifically say SQL Server 2000? The reason
I ask, is that SQL Server 2000 has XML specific extensions that would
aid you in such reports...
http://www.fawcette.com/archives/premier/mgznarch/vbpj/2001/ENT0109/rj0109ent/rj0109ent-1.asp
Client-side caching is as simple as using ADO to persist a resultset to
XML. You can keep it in memory, or store it to disk - whatever meets
your needs.
--Joseph
Joseph M. Ferris
> Client-side caching is as simple as using ADO to persist a resultset to
> XML. You can keep it in memory, or store it to disk - whatever meets
> your needs.
I meant recordset, not resultset. I was thinking of how the result was
a recordset and made up a new word on the fly. ;-)
--Joseph
Bonj
> required interface and provide values within two predefined functions.
> The component that does the serialization and deserialization is a
constant.
>
> I have not gotten the wild hair yet, but I have been considering writing
> an Add-In that will write the code in the two functions for me so that I
> don't need to even deal with that.
>
> > If it's (1) or (3), do you have any examples of this?
>
> I'll put it up on PlanetSourceCode tommorrow. I will write an example
> application to go with it so that you can see how it works.
OK, excellent, I'll have a look.
> XSL is great for this. Just so I point you in the right direction, what
> are we talking about on the back end? Are we just talking a standard
> ODBC datasource, or can we specifically say SQL Server 2000?
Yes, SQL Server 2000.
> The reason
> I ask, is that SQL Server 2000 has XML specific extensions that would
> aid you in such reports...
>
>
http://www.fawcette.com/archives/premier/mgznarch/vbpj/2001/ENT0109/rj0109ent/rj0109ent-1.asp
Cheers, I'll have a look
Jim Carlock
offer a free download with a 30 day trial. The product is
pretty good. I messed with like a 2 or 3 years ago and was
impressed.
http://www.xmlspy.com/download.html
http://www.xmlspy.com/download/2004/default.asp?product=e&os=xp&server=us
--
Jim Carlock
http://www.microcosmotalk.com/
Post replies to the newsgroup.
"Bonj" <a...@b.com> wrote in message
news:uzsS1ggC...@TK2MSFTNGP12.phx.gbl...
Joseph M. Ferris
> OK, excellent, I'll have a look.
Here it is:
http://www.planetsourcecode.com/vb/scripts/ShowCode.asp?txtCodeId=52397&lngWId=1
--Joseph
Bonj
do you also have any examples of the possibility of XML being used to apply
standard formatting to HTML tables/reports? Sort of a simple as possible
while getting the job done type of example?
Thanks
"Joseph M. Ferris" <joseph...@cox.net> wrote in message
news:eSGK8XsC...@TK2MSFTNGP11.phx.gbl...
Bonj
turn for the worse. There's just too much intertwined early binding. Your
project references 'MSXML2' and when I downloaded MSXML from Microsoft, I
think it installed 'MSXML3', a few of the broken references then disappeared
but then it kicked in majorly when one of your projects in the group
referenced another project in the group which in turn referenced the third
project in the group - I could normally just about solve this myself but
then the fact that it referenced a 'DOMDocument40' when in the XML library
there was only a DOMDocument, DOMDocument26, and DOMDocument30! I can
possibly see that XML could be useful for me if late binding was used but
for VB things I want something that I can be sure will work on my boss's PC
the first time he tries it, which I can't really be if I can't get it
working at all on my own. If you told me where to download the references it
needs and the sequence to set them up, I could probably just about get it to
work on my home PC, but then if it's not going to help me at work, it would
probably only interest me for hobbyist stuff if it could generate plain-GDI
animation algorithms that are optimized for gcc 3.4 (!) :-)
What *would* be useful to me at work though is something more to do with
HTML. Do you know of any more HTML-based demonstrations of the
simple-but-functional type? If you could point me to such a late-binding
example of HTML report templates that would be more than godly.
"Joseph M. Ferris" <joseph...@cox.net> wrote in message
news:eSGK8XsC...@TK2MSFTNGP11.phx.gbl...
Joseph M. Ferris
fully qualified progID for the 4.0 would be MSXML2.DomDocument40 (or
MSXML2.DomDocument.4.0 when using CreateObject). Don't ask me why, but
Microsoft went from the MSXML library name with version three to the
MSXML2 library name with version four.
You should just be able to go to http://www.microsoft.com/xml and it
should redirect you to where you need to go. From there, look on that
page for the Microsoft XML Core Services 4.0 Service Pack 2 link on the
right hand side. Once it is installed, you should have Microsoft XML,
v4.0 available from your references. Otherwise, you should just be able
to reopen the project without messing with the references.
I am cobbling together a XML->HTML via XSL sample for you. I'll see if
I can get it running on the 3.0 parser, too. I'll post back here within
the hour.
--Joseph
Joseph M. Ferris
Bonj wrote:
> Thanks, looks interesting...
> do you also have any examples of the possibility of XML being used to apply
> standard formatting to HTML tables/reports? Sort of a simple as possible
> while getting the job done type of example?
This should do it for you... A very simple XML->HTML "report". I
tested it with the 3.0 version of the parser, and it works fine.
1. First, create a new project in VB. Add a reference to Microsoft
XML, v3.0
2. Paste the following code in:
Option Explicit
Private Function CreateDOM() As DOMDocument30
Dim xdoLocal As DOMDocument30
Set xdoLocal = New DOMDocument30
xdoLocal.async = False
xdoLocal.validateOnParse = False
xdoLocal.resolveExternals = False
Set CreateDOM = xdoLocal
End Function
Private Sub Form_Load()
Dim xdoSource As DOMDocument30
Dim xdoStyleSheet As DOMDocument30
Dim xdoOutput As DOMDocument30
Dim str As String
Set xdoSource = CreateDOM
xdoSource.Load App.Path & "\test.xml"
Set xdoStyleSheet = CreateDOM
xdoStyleSheet.Load App.Path & "\test.xsl"
str = xdoSource.transformNode(xdoStyleSheet)
Debug.Print "xdoSource.transformNode: " & vbNewLine & str
Set xdoOutput = CreateDOM
xdoSource.transformNodeToObject xdoStyleSheet, xdoOutput
xdoSource.save App.Path & "test.html"
End Sub
3. Save it so that the App.Path reference resolves correctly.
4. Paste the following into a file called 'test.xml' in your App.Path:
<?xml version="1.0"?>
<customerlist>
<customeritem>
<name_last>Smith</name_last>
<name_first>Bill</name_first>
<address1>123 Any Lane</address1>
<address2></address2>
<city>New York</city>
<state>NY</state>
<postal>10003</postal>
<phone>917.222.2324</phone>
</customeritem>
<customeritem>
<name_last>Johnson</name_last>
<name_first>Amy</name_first>
<address1>341 Durango Curve</address1>
<address2>Suite 123</address2>
<city>Oakland</city>
<state>CA</state>
<postal>98765</postal>
<phone>512.215.5412</phone>
</customeritem>
<customeritem>
<name_last>Hurtz</name_last>
<name_first>Richard</name_first>
<address1>4923 Viagra Way</address1>
<address2></address2>
<city>Upton</city>
<state>CA</state>
<postal>99999</postal>
<phone>874.654.2541</phone>
</customeritem>
<customeritem>
<name_last>Doe</name_last>
<name_first>Jane</name_first>
<address1>123 Your Street</address1>
<address2></address2>
<city>Your City</city>
<state>AL</state>
<postal>23423</postal>
<phone>976.654.2154</phone>
</customeritem>
<customeritem>
<name_last>Johnson</name_last>
<name_first>Howard</name_first>
<address1>9834 Main St.</address1>
<address2>Box 12</address2>
<city>Fort Lauderdale</city>
<state>FL</state>
<postal>12343</postal>
<phone>984.354.2465</phone>
</customeritem>
</customerlist>
5. Paste the following into a file called 'test.xsl' in your App.Path
(watch for the wrap on this one):
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="/">
<html>
<body>
<table border="2">
<tr>
<td>Name</td>
<td>Address Line 1</td>
<td>Address Line 2</td>
<td>City</td>
<td>State</td>
<td>Postal Code</td>
<td>Phone</td>
</tr>
<xsl:for-each select="customerlist/customeritem">
<tr>
<td><xsl:value-of select="name_last"/>, <xsl:value-of
select="name_first"/></td>
<td><xsl:value-of select="address1"/></td>
<td><xsl:value-of select="address2"/></td>
<td><xsl:value-of select="city"/></td>
<td><xsl:value-of select="state"/></td>
<td><xsl:value-of select="postal"/></td>
<td><xsl:value-of select="phone"/></td>
</tr>
</xsl:for-each>
</table>
</body>
</html>
</xsl:template>
</xsl:stylesheet>
6. Run it. You will get the HTML output in the Debug window, and also
saved out to the App.Path. It is named, appropriately enough, 'test.html'.
Let me know if this was more what you are looking for...
--Joseph
Joseph M. Ferris
>xdoSource.save App.Path & "test.html"
Should be:
xdoOutput.save App.Path & "\test.html"
;-)
--Joseph
Larry Serflaten
>
> >xdoSource.save App.Path & "test.html"
>
> Should be:
>
> xdoOutput.save App.Path & "\test.html"
Doh! (I figured it out when I saw the html file was the source XML)
I also was testing your code and made a few changes to the stylesheet:
<table border="1" cellpadding="4px">
<tr>
<th>Name</th>
<th>Address Line 1</th>
(Added padding and TH elements.)
But the entries that have no data have a space in the Table
instead of an empty cell. Even if I preceed all nodes with a
space character, the space in the table (under Address Line 2)
appears:
<td><xsl:text> </xsl:text><xsl:value-of select="address2"/></td>
... for all nodes ...
Attempting " " did not work either. Might you know how
to make all the cells appear, even if the value is not present?
LFS
Joseph M. Ferris
Larry Serflaten wrote:
> But the entries that have no data have a space in the Table
> instead of an empty cell. Even if I preceed all nodes with a
> space character, the space in the table (under Address Line 2)
> appears:
>
> <td><xsl:text> </xsl:text><xsl:value-of select="address2"/></td>
> ... for all nodes ...
>
> Attempting " " did not work either. Might you know how
> to make all the cells appear, even if the value is not present?
I actually had thought about this after I posted my last message. The
reason that you had problems is that is an HTML entity and XML
does not understand it. I am assuming that when you tried putting in
the XML, the parser threw an error, correct?
There is are two ways to fix it easily.
You could (this is the quick way) just use this to kick out a
non-breaking space:
<xsl:text disable-output-escaping="yes">&nbsp;</xsl:text>
The downside to this is that you need to do this every place you want a
non-breaking space. XML has only five named entities > (>), <
(<), ' ('), " ("), and & (&). The above way is the quick
way to use a non-supported entity. And there is a caveat... When you
save it with the way I provided in the sample, it is going to convert it
to a literal &nbsp; or, as it will be displayed physically on the
web page .
With this you will also need to modify the way that you are saving the
HTML out to disk. The best way is to just drop using the parser to save
it. I am partial to the ADO Stream Object for file i/o, but any way
will work:
Private Sub Form_Load()
Dim stmLocal As ADODB.Stream
Dim xdoSource As DOMDocument30
Dim xdoStyleSheet As DOMDocument30
Dim str As String
Set xdoSource = CreateDOM
xdoSource.Load App.Path & "\test.xml"
Set xdoStyleSheet = CreateDOM
xdoStyleSheet.Load App.Path & "\test.xsl"
str = xdoSource.transformNode(xdoStyleSheet)
Debug.Print "xdoSource.transformNode: " & vbNewLine & str
Set stmLocal = New Stream
stmLocal.Type = adTypeText
stmLocal.Open
stmLocal.WriteText str
stmLocal.SaveToFile App.Path & "\test.html", adSaveCreateOverWrite
stmLocal.Close
End Sub
You can just use standard i/o routines if you don't want the ADO baggage
to go along with the references. ;-)
Otherwise, what you can do, is to define the entity inside of the XSL.
To do this, add the following lines to the beginning of your test.xsl file:
<?xml version="1.0"?>
<!DOCTYPE xsl:stylesheet [
<!ENTITY nbsp " ">
]>
All you are doing is specifying that there is a named entity that you
can call as . You could call it like this:
<td><xsl:value-of select="address2"/><xsl:text> </xsl:text></td>
The downside of this is that it is going to give you a non-breaking
space for the translation and not the physical output. You will not
have the entity in your output, but a literal space. For our
purposes, however, this will work.
Another note... I am not an XSL expert, by any means. Our resident
expert at work is gone for the week, but I am sure he will show me a
better way when he gets back. ;-) If he does, I'll share it.
Let me know if that is what you were looking for, Larry.
Thanks,
--Joseph
Joseph M. Ferris
> I actually had thought about this after I posted my last message. The
> reason that you had problems is that is an HTML entity and XML
> does not understand it. I am assuming that when you tried putting in
> the XML, the parser threw an error, correct?
That should be you "tried putting it in the XSL...". One of these days,
I am going to start proofreading before I post. <g>
--Joseph
Jim Carlock
>Attempting " " did not work either. Might you know how
>to make all the cells appear, even if the value is not present?
Change to   and try that. That works for me.
  is the XML equivalent of and doesn't (??)
exist in XML.
Larry Serflaten
> Otherwise, what you can do, is to define the entity inside of the XSL.
> To do this, add the following lines to the beginning of your test.xsl file:
>
> <?xml version="1.0"?>
> <!DOCTYPE xsl:stylesheet [
> <!ENTITY nbsp " ">
> ]>
>
> All you are doing is specifying that there is a named entity that you
> can call as . You could call it like this:
>
> <td><xsl:value-of select="address2"/><xsl:text> </xsl:text></td>
I tried that....
> The downside of this is that it is going to give you a non-breaking
> space for the translation and not the physical output. You will not
> have the entity in your output, but a literal space. For our
> purposes, however, this will work.
How is that different than the space I had already tried?
In any case, I got an XML error, the XSL file would not work.
This line simply would not be accepted:
<td><xsl:value-of select="address2"/><xsl:text> </xsl:text></td>
I tried
<td><xsl:value-of select="address2"/>&<xsl:text>nbsp;</xsl:text></td>
And
<td><xsl:value-of select="address2"/><xsl:text>&nbsp;</xsl:text></td>
But they both gave me an output of:
<td>Box 12&nbsp;</td>
Nothing I tried would turn that into:
<td>Box 12 </td>
Which is what I would want to make those cells appear....
LFS
Joseph M. Ferris
>><?xml version="1.0"?>
>><!DOCTYPE xsl:stylesheet [
>><!ENTITY nbsp " ">
>>]>
>>
>>All you are doing is specifying that there is a named entity that you
>>can call as . You could call it like this:
>>
>><td><xsl:value-of select="address2"/><xsl:text> </xsl:text></td>
>
>
> I tried that....
Did you add the entity declaration at the beginning of the quoted text?
I have this same XSL working on my machine:
<?xml version="1.0"?>
<!DOCTYPE xsl:stylesheet [
<!ENTITY nbsp " ">
]>
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="/">
<html>
<body>
<table border="2">
<tr>
<td>Name</td>
<td>Address Line 1</td>
<td>Address Line 2</td>
<td>City</td>
<td>State</td>
<td>Postal Code</td>
<td>Phone</td>
</tr>
<xsl:for-each select="customerlist/customeritem">
<tr>
<td><xsl:value-of select="name_last"/>,
<xsl:value-of
select="name_first"/> </td>
<td><xsl:value-of select="address1"/> </td>
<td><xsl:value-of select="address2"/> </td>
<td><xsl:value-of select="city"/> </td>
<td><xsl:value-of select="state"/> </td>
<td><xsl:value-of select="postal"/> </td>
<td><xsl:value-of select="phone"/> </td>
</tr>
</xsl:for-each>
</table>
</body>
</html>
</xsl:template>
</xsl:stylesheet>
When I run this XSL I get the following result:
<html>
<body>
<table border="2">
<tr>
<td>Name</td>
<td>Address Line 1</td>
<td>Address Line 2</td>
<td>City</td>
<td>State</td>
<td>Postal Code</td>
<td>Phone</td>
</tr>
<tr>
<td>Smith, Bill </td>
<td>123 Any Lane </td>
<td> </td>
<td>New York </td>
<td>NY </td>
<td>10003 </td>
<td>917.222.2324 </td>
</tr>
<tr>
<td>Johnson, Amy </td>
<td>341 Durango Curve </td>
<td>Suite 123 </td>
<td>Oakland </td>
<td>CA </td>
<td>98765 </td>
<td>512.215.5412 </td>
</tr>
<tr>
<td>Hurtz, Richard </td>
<td>4923 Viagra Way </td>
<td> </td>
<td>Upton </td>
<td>CA </td>
<td>99999 </td>
<td>874.654.2541 </td>
</tr>
<tr>
<td>Doe, Jane </td>
<td>123 Your Street </td>
<td> </td>
<td>Your City </td>
<td>AL </td>
<td>23423 </td>
<td>976.654.2154 </td>
</tr>
<tr>
<td>Johnson, Howard </td>
<td>9834 Main St. </td>
<td>Box 12 </td>
<td>Fort Lauderdale </td>
<td>FL </td>
<td>12343 </td>
<td>984.354.2465 </td>
</tr>
</table>
</body>
</html>
I can't see why you are still getting something different... Hmmm.
I'll look at all this again in the morning and see if I am missing
something.
--Joseph
Larry Serflaten
"Jim Carlock" <anon...@127.0.0.1> wrote
> "Larry Serflaten" wrote:
> >Attempting " " did not work either. Might you know how
> >to make all the cells appear, even if the value is not present?
>
> Change to   and try that. That works for me.
>
>   is the XML equivalent of and doesn't (??)
> exist in XML.
Thanks, I tried that inside and outside of a xsl text object, but
they both showed  (Capital A with circumflex)
eg:
<td><xsl:value-of select="address2"/><xsl:text> </xsl:text></td>
<td><xsl:value-of select="address2"/> </td>
The character in the .html file was Chr(160), but in IE the  [Chr(194)]
was shown in the cell. Which is a bit hard to understand, because the
font IE is using (Arial) has 160 listed as nbsp. If I put   in the
html file, then IE displays it as a normal space; chr(32).
I think this is getting a little deeper than I wanted to go! <g>
LFS
Larry Serflaten
"Joseph M. Ferris" <joseph...@cox.net> wrote
> I can't see why you are still getting something different... Hmmm.
> I'll look at all this again in the morning and see if I am missing
> something.
Thanks for your efforts, if it worked on your machine then,
let's stop there. I think there may be a problem with the version of
IE I am using (5.00.3502.1000) as I stated in my message to Jim,
the #160 character is being displayed as #194.
Let's just leave it at that for now, I will probably do an upgrade
some time in the near future. When I first got W2K I had planned
to be able to re-install the OS on occasion, and have done so
several times, but the #!&$# service packs are putting a damper
on that activity. They take hours to d/l and install, and the last
time I did it, I wanted to get SP2, but all that was offered was SP3!
(Including wording in the new EULA that I did *not* want to agree to!)
Some may think dancing on shifting sand is their idea of fun, but
I don't, I want to be on solid cement! I never did like the idea of
software upgrades that overwrite older versions. But that is a
topic of a different sort....
Thanks for the samples!
LFS
Jim Carlock
<meta http-equiv="Content-type" content="text/html; charset=windows-1252" />
--
Jim Carlock
http://www.microcosmotalk.com/
Post replies to the newsgroup.
"Larry Serflaten" <serf...@usinternet.com> wrote in message
news:edYO3Y%23CEH...@TK2MSFTNGP11.phx.gbl...
"Jim Carlock" <anon...@127.0.0.1> wrote
> "Larry Serflaten" wrote:
> >Attempting " " did not work either. Might you know how
> >to make all the cells appear, even if the value is not present?
>
> Change to   and try that. That works for me.
>
>   is the XML equivalent of and doesn't (??)
> exist in XML.
Thanks, I tried that inside and outside of a xsl text object, but
they both showed Ā (Capital A with circumflex)
eg:
<td><xsl:value-of select="address2"/><xsl:text> </xsl:text></td>
<td><xsl:value-of select="address2"/> </td>
The character in the .html file was Chr(160), but in IE the Ā [Chr(194)]
Larry Serflaten
"Jim Carlock" <anon...@127.0.0.1> wrote in message news:eB6Z#D$CEHA...@TK2MSFTNGP11.phx.gbl...
> What about specifying a default character set in a <head></head> section?
>
> <meta http-equiv="Content-type" content="text/html; charset=windows-1252" />
Yes, that made the cells show up correctly and FWIW the #160 characters in
the .html file were shown as #032 (normal space) in IE....
Thanks for sticking with it, it just may matter down the road.... ;-)
LFS
Jim Carlock
Encode the white-space as follows:
<pre> </pre>
The <pre> tag is used to make sure all white space is displayed as
white space in all character sets. CRLF appear as CRLF, a tab is
a tab, a blank space is " ". <g>
I'd rather use the   by specifying a default character set. But
that means you're depending upon the browser to display the item,
and if the browser is set to another character set, I'm not sure what
will happen. I messed with the browser settings for making fonts
smaller and forgot I changed it once, and reported someone's
website as having a bug. She knew my browser setting was incorrect
though and told me to fix my browser settings. I felt like a dummy
reporting that her website was malfunctioning. I did learn one thing
from it though. That whenever you set up a website, you should
specify a default pitch size for your fonts, so people that play with
their browser settings won't make your website look screwy ('cause
I sure don't want to hear people yapping about my messy website
that needs bigger fonts, when in actuality it's their browser settings
causing the problems).
I don't think it's the font that determines which character is displayed.
Your statement that chr(194) is the A when inside an HTML file,
seems odd. I can't duplicate that. Even with no character-set
declaration within IE. You might want to check your character-set
settings for IE. Click on View, then Encoding and see what's listed
there. Mine is set for Auto-Select, Western European (Windows).
That setting might change depending upon what the default charset
is as defined in the <meta> tag in the <head> section.
--
Jim Carlock
http://www.microcosmotalk.com/
Post replies to the newsgroup.
"Larry Serflaten" <serf...@usinternet.com> wrote in message
news:edYO3Y%23CEH...@TK2MSFTNGP11.phx.gbl...
"Jim Carlock" <anon...@127.0.0.1> wrote
> "Larry Serflaten" wrote:
> >Attempting " " did not work either. Might you know how
> >to make all the cells appear, even if the value is not present?
>
> Change to   and try that. That works for me.
>
>   is the XML equivalent of and doesn't (??)
> exist in XML.
Thanks, I tried that inside and outside of a xsl text object, but
they both showed Ā (Capital A with circumflex)
eg:
<td><xsl:value-of select="address2"/><xsl:text> </xsl:text></td>
<td><xsl:value-of select="address2"/> </td>
The character in the .html file was Chr(160), but in IE the Ā [Chr(194)]
Jim Carlock
tell you if your document is valid.
There are several requirements for any XML file to be a valid XML
file. Mostly these are just opening and closing tag rules, but the XML
type needs to be declared, all XHTML documents must have a
<!DOCTYPE specified. And I'm thinking that all XHTML documents
require the character set to be declared. That validator is great help
when figuring out what you need.
--
Jim Carlock
http://www.microcosmotalk.com/
Post replies to the newsgroup.
"Larry Serflaten" <serf...@usinternet.com> wrote in message
news:eGkbeM$CEHA...@TK2MSFTNGP10.phx.gbl...
Larry Serflaten
"Jim Carlock" <anon...@127.0.0.1> wrote
Actually I can't get it to accept the windows font from the xsl file.
If I add an empty <head> section to the xsl file, then it adds a default
charset:
<META http-equiv="Content-Type" content="text/html; charset=UTF-16">
If I include the windows line, then that is included after the above, but
it will not produce an output as written. The file ends up empty.
I had added the windows line to the html file when I replied earlier
and that did fix the cells problem. Also the str variable in the routine
is properly filled (so I could save that to a file) but, as written, it
does not complete the task as it did at the start, I just get an empty file.
> That whenever you set up a website, you should specify a default
> pitch size for your fonts, ...
That has always bothered me about some sites. How can they know
what size I want the font to be at? I really have to move close to the
monitor for some sites that have locked fonts sizes set so small as to
be nearly un-readable. I *want* to be able to adjust the text settings,
(in fact I have a button set up for it on my toolbar, right beside the
printer icon) and those sites that lock their fonts to a specific size are
usually always way too small to be read comfortably! That could mean
I have a small monitor (17"), or I am using too large of dimensions for
the screen (1024 X 768), but that is what I want for development. Sure
menus are small, but for browsing I want to adjust the page text size....
Examples:
NY Times does it right:
http://www.nytimes.com/2004/03/17/national/17SUSP.html
FoxNews does not: (They do use ample whitespace and that helps)
http://www.foxnews.com/story/0,2933,114290,00.html
<Oh well!>
LFS
Bonj
fully qualified progID for the 4.0 would be MSXML2.DomDocument40 (or
MSXML2.DomDocument.4.0 when using CreateObject). Don't ask me why, but
Microsoft went from the MSXML library name with version three to the
MSXML2 library name with version four.
Unfortunately the fact that DLL hell exists at all with it is enough to put me off - it doesn't make it any better that it's capable of being cured. The fact is if I go down this route I'm likely to end up having produced something that works beautifully and then my boss will just look at me like an idiot because it doesn't work on his PC because he hasn't got the right version of the library. DLL-hell puts it in a whole different ball-park really - if you are competing with things that have to accept that DLL-hell may exist, well it's a whole different area of competition. Learn the simple golden rule - *early binding sucks*!!!!
You should just be able to go to http://www.microsoft.com/xml and it
should redirect you to where you need to go.
Should, should, should. If everything that 'should' happen did happen, just think what a magnificently perfect situation we'd be in.
I am cobbling together a XML->HTML via XSL sample for you. I'll see if
I can get it running on the 3.0 parser, too. I'll post back here within
the hour.
If you can get it working with late-binding that'd be amazing. Thanks.
--Joseph
Joseph M. Ferris
Jim Carlock wrote:
> I don't think it's the font that determines which character is displayed.
> Your statement that chr(194) is the A when inside an HTML file,
> seems odd. I can't duplicate that.
I was able to get it to show up, like Larry did. It happened when I
saved the output HTML with the DOM again (xdoOutput). When I saved it
directly to disk with the Stream object, it went away. It appears that
the parser was "reinterpretting" the character when it saved it to disk.
Seeing it happen and knowing why are two different things, though. I
guess I give up too easily. ;-)
--Joseph
Joseph M. Ferris
Larry Serflaten wrote:
> If I include the windows line, then that is included after the above, but
> it will not produce an output as written. The file ends up empty.
> I had added the windows line to the html file when I replied earlier
> and that did fix the cells problem. Also the str variable in the routine
> is properly filled (so I could save that to a file) but, as written, it
> does not complete the task as it did at the start, I just get an empty file.
That is my fault. In my one post last night, I recommended dumping that
last DOM (xdoOutput) and replacing it with other file operations. The
sample code that I provided last night uses the stream object.
Normally, I don't use the DOM to save an HTML file to disk. For
brevity, I thought that I would use the source code that Microsoft
provides for an example on performing a translation. Since when I
started trusting Microsoft, I have no idea... <g>
--Joseph
Joseph M. Ferris
> Unfortunately the fact that DLL hell exists at all with it is enough to put me off - it doesn't make it any better that it's capable of being cured.
The fact is if I go down this route I'm likely to end up having produced
something that works beautifully and then my boss will just look at me
like an idiot because it doesn't work on his PC because he hasn't got
the right version of the library. DLL-hell puts it in a whole different
ball-park really - if you are competing with things that have to accept
that DLL-hell may exist, well it's a whole different area of
competition. Learn the simple golden rule - *early binding sucks*!!!!
It is just a dependency, like other dependencies that exist within an
application. You can't really expect every user to have every component
at any given time. If you build it with the 3.0 version of the parser,
it will work on your boss's machine. If you build it with 4.0, you will
most likely have to distribute a dependancy with the build. Of course,
if you build an install package, the dependencies will be resolved and
included with the distribution.
Your golden rule does not cut it for me, though. It is definitely an
opinion that I don't share. Early binding is faster since it does not
need to determine which object to create at runtime, provides
Intellisense, and captures syntax errors at compile-time instead of at
run-time. I only use late binding when I absolutely need to. I will
use it when creating objects in ASP, when working with COM+ (although it
is not always required), and when creating an unknown object that
implements a known interface.
> Should, should, should. If everything that 'should' happen did happen, just think what a magnificently perfect situation we'd be in.
Granted. I am a realist, so I use 'should' wherever appropriate.
Ironically, 'should' is used a lot more often when talking about
Microsoft products than it *should* be. <g>
> If you can get it working with late-binding that'd be amazing. Thanks.
I believe that this should work for you, then:
Option Explicit
Private Function CreateDOM() As Object
Dim xdoLocal As Object
Set xdoLocal = CreateObject("MSXML.DOMDocument")
xdoLocal.async = False
xdoLocal.validateOnParse = False
xdoLocal.resolveExternals = False
Set CreateDOM = xdoLocal
End Function
Private Sub Form_Load()
Dim xdoSource As Object
Dim xdoStyleSheet As Object
Dim xdoOutput As Object
Dim lngFree As Long
Dim str As String
Set xdoSource = CreateDOM
xdoSource.Load App.Path & "\test.xml"
Set xdoStyleSheet = CreateDOM
xdoStyleSheet.Load App.Path & "\test.xsl"
str = xdoSource.transformNode(xdoStyleSheet)
Debug.Print "xdoSource.transformNode: " & vbNewLine & str
lngFree = FreeFile
Open App.Path & "\test.html" For Output As #lngFree
Print #lngFree, str
Close #lngFree
End Sub
Additionally, let me give you the new XSL that I worked out to support
the non-breaking spaces that Larry was looking for:
<?xml version="1.0"?>
<!DOCTYPE xsl:stylesheet [
<!ENTITY nbsp " ">
]>
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="/">
<html>
<body>
<table border="2">
<tr>
<td>Name</td>
<td>Address Line 1</td>
<td>Address Line 2</td>
<td>City</td>
<td>State</td>
<td>Postal Code</td>
<td>Phone</td>
</tr>
<xsl:for-each select="customerlist/customeritem">
<tr>
<td><xsl:value-of select="name_last"/>,
<xsl:value-of select="name_first"/> </td>
<td><xsl:value-of select="address1"/> </td>
<td><xsl:value-of select="address2"/> </td>
<td><xsl:value-of select="city"/> </td>
<td><xsl:value-of select="state"/> </td>
<td><xsl:value-of select="postal"/> </td>
<td><xsl:value-of select="phone"/> </td>
</tr>
</xsl:for-each>
</table>
</body>
</html>
</xsl:template>
</xsl:stylesheet>
And so you don't need to look for it in the other post, here is the XML
again:
That should get you started. ;-)
--Joseph
Larry Serflaten
"Joseph M. Ferris" <joseph...@cox.net> wrote
> Additionally, let me give you the new XSL that I worked out to support
> the non-breaking spaces that Larry was looking for:
I was doing that to make the output look better, but you didn't include
my other adjustments to complete the job! :-(
<table border="2" cellpadding="4px">
<tr bgcolor="#99CCFF">
<th>Name</th>
<th>Address Line 1</th>
<th>Address Line 2</th>
<th>City</th>
<th>State</th>
<th>Postal Code</th>
<th>Phone</th>
</tr>
<g>
LFS
Joseph M. Ferris
> I was doing that to make the output look better, but you didn't include
> my other adjustments to complete the job! :-(
Sincerest of all apologies, Larry. ;-)
<?xml version="1.0"?>
<!DOCTYPE xsl:stylesheet [
<!ENTITY nbsp " ">
]>
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="/">
<html>
<body>
<table border="2" cellpadding="4px">
<tr bgcolor="#99CCFF">
--Joseph
Jim Carlock
Wasn't messing with anything inside of VB. The things you've
stated indicate that the code written to the HTML document
through VB must have changed what was saved to the
document.
I just hand-typed the following HTML document and added
the two lines that Larry was having a problem with and thus
I couldn't duplicate the HTML issue he had. It's plain ASCII
text, no tricks with the ALT and Numeric keypad. <g>
If you copy and the paste the code below and to a .htm file,
you won't see the problem Larry stated. So, you'll have to
look at the HTML document that VB wrote and compare
the two line by line. There has to be something different.
<html>
<head>
<title>Test</title>
</head>
<body>
<table>
<tbody>
<tr>
<td><xsl:value-of select="address2"/><xsl:text> </xsl:text></td>
<td><xsl:value-of select="address2"/> </td>
</tr>
</tbody>
</table>
</body>
</html>
I could have missed something. Was skimming over things when I
noticed Larry was talking about white-space inside an HTML
document, and I jumped in on that. I've not been following the
details of how VB writes the documents into an HTML format.
Any HTML coding that I need to do is all handcoded, making
use of CSS if needed. I can only guess at what XSL is, it
sounds like CSS but obviously there is something different.
Another thing for me to have to learn ? Or can I get CSS to
do what needs to be done?
--
Jim Carlock
http://www.microcosmotalk.com/
Post replies to the newsgroup.
"Joseph M. Ferris" <joseph...@cox.net> wrote in message
news:uuKEpOCD...@TK2MSFTNGP10.phx.gbl...
Joseph M. Ferris
Jim Carlock wrote:
> I was testing using a plain old HTML document handwritten.
> Wasn't messing with anything inside of VB. The things you've
> stated indicate that the code written to the HTML document
> through VB must have changed what was saved to the
> document.
Yes. When I was transforming the document and then saved the results to
the xdoOutput DOM, the characters would show up if I saved the XML via
xdoOutput.save. I can only assume that the output was marked up for
some reason when saving to disk. What I had in the Immediate Windows
from the debug.print statement was not what I ended up with inside of
the final html file.
> I just hand-typed the following HTML document and added
> the two lines that Larry was having a problem with and thus
> I couldn't duplicate the HTML issue he had. It's plain ASCII
> text, no tricks with the ALT and Numeric keypad. <g>
Same here. I did this too, making sure that it was not a browser issue,
as well. Normally I use Mozilla, but I blew the dust off the IE icon on
the Quicklaunch for a side-by side. ;-)
Like I mentioned in another post. Once I stoped having the DOM save the
HTML to disk, the problem went away. It would be nice to have someone
from Microsoft chime in as to the reason behind the character
interpretation, but I won't hold my breath. Switching to VB's native
file access or to the ADO Stream object eliminated the problem for me.
> Any HTML coding that I need to do is all handcoded, making
> use of CSS if needed. I can only guess at what XSL is, it
> sounds like CSS but obviously there is something different.
There is. I would say the difference is in the way the two perform.
While they are both Stylesheet Languages, XSL is best suited for modify
structure, and CSS is best suited for modifying presentation.
> Another thing for me to have to learn ? Or can I get CSS to
> do what needs to be done?
We often include the reference to the CSS stylesheets through the output
derived from the XSL translation (currently we are driving the creation
of XHTML documents from XML datasets). This allows us to get the
structure correct, but we can modify the presentation attributes without
altering the XSL.
--Joseph
Larry Serflaten
> Any HTML coding that I need to do is all handcoded, making
> use of CSS if needed. I can only guess at what XSL is, it
> sounds like CSS but obviously there is something different.
>
Same here, for the most part. This was the first (short and simple)
example of XSL that I saw that did the transform from XML to
HTML.
As you might know, these newsgroups are a great place to pick
up these types of samples. I actually do try a lot of them that are
in areas I am less familiar with....
LFS
Bonj
> application. You can't really expect every user to have every component
> at any given time. If you build it with the 3.0 version of the parser,
> it will work on your boss's machine. If you build it with 4.0, you will
> most likely have to distribute a dependancy with the build. Of course,
> if you build an install package, the dependencies will be resolved and
> included with the distribution.
It is not 'a' depdency, but many dependencies. I noticed at least 3
'Microsoft XML' entries in the references list. I don't really know how you
can say that if I build it with version 3 then it will work on my boss's
machine, when my home PC is XP pro like my boss's at work, and your example
didn't work on this machine. (Good though it looked). I can't build an
install package as if it was to be used in an application
>
> Your golden rule does not cut it for me, though. It is definitely an
> opinion that I don't share. Early binding is faster since it does not
> need to determine which object to create at runtime, provides
> Intellisense, and captures syntax errors at compile-time instead of at
> run-time.
We experienced the same problem with ADO a while back and now any programs I
write that use ADO use late binding. It's really that simple - experience a
problem, find a way to write code that solves the problem, implement the new
way. And stick to it. The problem won't reoccur. And that way at our office
is late binding. There was no questionning it. As regards the speed
improvement, in our particular environment it is not even in the slightest
bit near to being a bottleneck, so that aspect of it doesn't matter in the
slightest. No one would ever notice in a million years the degradation in
performance due to late binding, especially when most of the time spent is
doing SQL server database queries - but they would notice (and care about)
an 'ActiveX component can't create object' error. However, I can understand
perfectly your reasons for early binding - in a situation such as an OLTP
application (and probably many more) then it's possible that it could be a
bottleneck, and the intellisense is definitely good for things you don't
know off by heart.
Yes, an installer package would be nice, but the environment at our office
is so RAD-intensive we don't often have time to create installer packages,
things are expected to be just put on the network and 'work'. But now we've
got ASP.NET we'll not really have to bother about that anyway - if anything
crops up that requires application-style functionality to select what report
to show etc. then I'll just bung it on a web server to save the hassle of
re-updating it, and for the CV (resume?) of course...:-) Once I've written
the generic library, well.....(!)
I've decided I'm going to create my own generic routines for the HTML
reports, which will probably consist of either a VB COM DLL with VBScript to
access it, in case we need any old-style ASP pages, and a set of equivalent
C# classes and routines for the mainstream ASP.NET stuff. But you've
definitely convinced me that XML *could* be useful, rather than just some
nonsense file format.
Joseph M. Ferris
> It is not 'a' depdency, but many dependencies. I noticed at least 3
> 'Microsoft XML' entries in the references list. I don't really know how you
> can say that if I build it with version 3 then it will work on my boss's
> machine, when my home PC is XP pro like my boss's at work, and your example
> didn't work on this machine. (Good though it looked). I can't build an
> install package as if it was to be used in an application
If you install the 4.0 SDK, all three of those will appear (2.6, 3.0,
and 4.0). They are all part of the package. Without 4.0, you will have
3.0 and 2.6 installed already. IE should install 2.6 and 3.0, so they
should be on every machine that has IE 5.0 and higher. I have to check,
but I am pretty sure that IE 6.0 installs 4.0 - but I am not 100%.
The reason that I built against 4.0 and recommended it in the Dependency
section of my comments on the source code sample is that 4.0 is closer
to being standards compliant than any previous version. Once 4.0 is
distributed, it can not only run 4.0 code, but can also still run 2.6
and 3.0 code. Maybe sometime this weekend I can try cobbling a 3.0
version together and see if you can get that to work.
It really is a handy program. One of the most common uses I have for it
is saving the state of components on a desktop application (WYSIWYG
XHTML Editor) that I have written for internal use at work. If I run
the application in "debug" mode, I can serialize and dump my ActiveX
DLLs to watch for bad data, or just to get a feeling of what the
application looked like. Also, I write them out to a cache directory
periodically. On a clean application exit, the cache directory is
cleaned out. In the event of a crash, the files are still there, so on
the next startup I can ask the user if they want to try to restore their
session.
> We experienced the same problem with ADO a while back and now any programs I
> write that use ADO use late binding. It's really that simple - experience a
> problem, find a way to write code that solves the problem, implement the new
> way. And stick to it. The problem won't reoccur. And that way at our office
> is late binding. There was no questionning it. As regards the speed
> improvement, in our particular environment it is not even in the slightest
> bit near to being a bottleneck, so that aspect of it doesn't matter in the
> slightest. No one would ever notice in a million years the degradation in
> performance due to late binding, especially when most of the time spent is
> doing SQL server database queries - but they would notice (and care about)
> an 'ActiveX component can't create object' error. However, I can understand
> perfectly your reasons for early binding - in a situation such as an OLTP
> application (and probably many more) then it's possible that it could be a
> bottleneck, and the intellisense is definitely good for things you don't
> know off by heart.
It is going to come down to in-house policies and personal preferences.
ADO was a nightmare for a while when we were moving people from
Windows 95 to Windows 2000. Needless to say, the developers were the
first on to Windows 2000, and there were some sticky situations with
MDAC in the builds that originated from Windows 2000.
As for the Intellisense... The main reason I care to have it not the
methods and properties as much as it is remember all the parameters that
I have to provide to functions and methods. ;-)
> I've decided I'm going to create my own generic routines for the HTML
> reports, which will probably consist of either a VB COM DLL with VBScript to
> access it, in case we need any old-style ASP pages, and a set of equivalent
> C# classes and routines for the mainstream ASP.NET stuff. But you've
> definitely convinced me that XML *could* be useful, rather than just some
> nonsense file format.
Were you able to get the XSL sample with late binding working? Just
curious. I would still like for you to be able to get the serialization
project working. Like I said, if you are game, I'll work on making it
3.0 dependent with late binding for you to test out.
--Joseph
Bonj
Thanks. I will take a serious look at that and possibly even be able to
implement it.
Nice work.
I may even finally dare to click that 'configure SQL XML support in SQL
server with IIS ' button that's been teasing me for ages....any tips on what
to do when I do, and best practices for proceeding down that rocky
road...??! :-)
"Joseph M. Ferris" <joseph...@cox.net> wrote in message
news:euAPVn6...@TK2MSFTNGP12.phx.gbl...
> Ben-
>
> Bonj wrote:
>
> > Thanks, looks interesting...
> > do you also have any examples of the possibility of XML being used to
apply
> > standard formatting to HTML tables/reports? Sort of a simple as possible
> > while getting the job done type of example?
>
> This should do it for you... A very simple XML->HTML "report". I
> tested it with the 3.0 version of the parser, and it works fine.
>
> 1. First, create a new project in VB. Add a reference to Microsoft
> XML, v3.0
>
> 2. Paste the following code in:
>
> Option Explicit
>
> Private Function CreateDOM() As DOMDocument30
>
> Dim xdoLocal As DOMDocument30
>
> Set xdoLocal = New DOMDocument30
> xdoLocal.async = False
> xdoLocal.validateOnParse = False
> xdoLocal.resolveExternals = False
> Set CreateDOM = xdoLocal
>
> End Function
>
> Private Sub Form_Load()
>
> Dim xdoSource As DOMDocument30
> Dim xdoStyleSheet As DOMDocument30
> Dim xdoOutput As DOMDocument30
> Dim str As String
>
> Set xdoSource = CreateDOM
> xdoSource.Load App.Path & "\test.xml"
>
> Set xdoStyleSheet = CreateDOM
> xdoStyleSheet.Load App.Path & "\test.xsl"
>
> str = xdoSource.transformNode(xdoStyleSheet)
> Debug.Print "xdoSource.transformNode: " & vbNewLine & str
>
> Set xdoOutput = CreateDOM
> xdoSource.transformNodeToObject xdoStyleSheet, xdoOutput
> xdoSource.save App.Path & "test.html"
>
> End Sub
>
> 3. Save it so that the App.Path reference resolves correctly.
>
> 4. Paste the following into a file called 'test.xml' in your App.Path:
> 5. Paste the following into a file called 'test.xsl' in your App.Path
> (watch for the wrap on this one):
>
> <xsl:stylesheet version="1.0"
> xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
> <xsl:template match="/">
> <html>
> <body>
> <table border="2">
> <tr>
> <td>Name</td>
> <td>Address Line 1</td>
> <td>Address Line 2</td>
> <td>City</td>
> <td>State</td>
> <td>Postal Code</td>
> <td>Phone</td>
> </tr>
> <xsl:for-each select="customerlist/customeritem">
> <tr>
> <td><xsl:value-of select="name_last"/>, <xsl:value-of
> select="name_first"/></td>
> <td><xsl:value-of select="address1"/></td>
> <td><xsl:value-of select="address2"/></td>
> <td><xsl:value-of select="city"/></td>
> <td><xsl:value-of select="state"/></td>
> <td><xsl:value-of select="postal"/></td>
> <td><xsl:value-of select="phone"/></td>
> </tr>
> </xsl:for-each>
> </table>
> </body>
> </html>
> </xsl:template>
> </xsl:stylesheet>
>
> 6. Run it. You will get the HTML output in the Debug window, and also
> saved out to the App.Path. It is named, appropriately enough,
'test.html'.
>
> Let me know if this was more what you are looking for...
>
> --Joseph
Bonj
formatting and style options...OK, just a couple of questions:
a) presumably now then, I can fairly easily enough generate a routine that
will programatically generate an XML file for whatever data I want that is
in the form of an SQL-generated recordset (also see my other post - does SQL
server do this automatically if I set it up right maybe?)
b) Can I do something similar for the XSL file, in a similar way in which if
I wanted to generate some HTML I might use FrontPage?
c) I notice that you use the save method of the DOMDocument30 - if I wanted
to use such methods in an ASP-style system, would I write to a temporary
file on the web server, or does it have some other method for generating the
text?
Joseph M. Ferris
Bonj wrote:
> That looks a LOT more like what I am looking for...!
> Thanks. I will take a serious look at that and possibly even be able to
> implement it.
Very cool. I tried to keep it clean and short.
> Nice work.
Thanks!
> I may even finally dare to click that 'configure SQL XML support in SQL
> server with IIS ' button that's been teasing me for ages....any tips on what
> to do when I do, and best practices for proceeding down that rocky
> road...??! :-)
I actually have not played with it much. We have a SQL Server 7 Cluster
right now and we have not migrated yet. (Why change it if it isn't
broken? <g>) I have a local SQL Server 2000 Server to develop against,
but I have not played with any of the XML goodies yet. Once we deploy
our next project, we should hopefully be moving on to there.
The article that I sent you the link to is probably going to be my first
foray into Microsft SQLXML world. It is just another one of those
things that they don't put enough time in the day for. ;-)
--Joseph
Bonj
> It is going to come down to in-house policies and personal preferences.
> ADO was a nightmare for a while when we were moving people from
> Windows 95 to Windows 2000. Needless to say, the developers were the
> first on to Windows 2000, and there were some sticky situations with
> MDAC in the builds that originated from Windows 2000.
That was more or less *exactly* our situation - now we've upgraded and are
mainly writing against 2.8 (those systems that are early-bound) nothing will
work on 95, I think even with the current version of MDAC.
> I would still like for you to be able to get the serialization
> project working.
I'll have another bash at it at the weekend, now I'm aware that there's only
one package (4.0) that doesn't get installed with IE5, and that's because
it's a more conformant SDK.
I'll probably end up using early binding against 3.0 in the first few XSL
projects, if that is definitely the case, but for the serialization it'll
simply be a matter of installing the 4.0 version from the MS web site
presumably...?
Joseph M. Ferris
> Right, so the XML file contains the data, the XSL file contains the
> formatting and style options...OK, just a couple of questions:
> a) presumably now then, I can fairly easily enough generate a routine that
> will programatically generate an XML file for whatever data I want that is
> in the form of an SQL-generated recordset (also see my other post - does SQL
> server do this automatically if I set it up right maybe?)
SQL Server currently can do this without any configuration changes.
Actually, it is ADO that does it. ;-) ADO can persist a recordset
directly to XML since version 2.5, I believe.
Once you retrieve a recordset, you can save it via:
rstMyRecordset.save "myxmldocument.xml", adPersistXML
or
rstMyRecordset.save stmLocalStream, adPersistXML
It will treat a string as the first argument as a physical location to
save a file to and an ADO Stream object as a place to write the XML to
directly.
> b) Can I do something similar for the XSL file, in a similar way in which if
> I wanted to generate some HTML I might use FrontPage?
Sorry, I am not sure what you mean here. I have not used FrontPage or
FrontPage Extensions. If you are asking if you can generate an XSL on
the fly, the answer would be yes. An XSL is a well-formed XML document,
so you can build and load it directly into the parser.
> c) I notice that you use the save method of the DOMDocument30 - if I wanted
> to use such methods in an ASP-style system, would I write to a temporary
> file on the web server, or does it have some other method for generating the
> text?
Actually, this sample is the first one I posted. I made a couple of
revisions to it since then. As opposed to saving the result with the
parser, I would recommend either using an ADO Stream object or regular
disk i/o, since the parser was not friendly to Larry's HTML results with
non-breaking spaces. FWIW, if you would use the save method of the
parser on the server, it would save the file locally to the server.
The full listing with all of the current code is in this post (made just
for you - it uses late binding <g>):
--Joseph
Joseph M. Ferris
> I'll have another bash at it at the weekend, now I'm aware that there's only
> one package (4.0) that doesn't get installed with IE5, and that's because
> it's a more conformant SDK.
> I'll probably end up using early binding against 3.0 in the first few XSL
> projects, if that is definitely the case, but for the serialization it'll
> simply be a matter of installing the 4.0 version from the MS web site
> presumably...?
That is all that should be required. <g>
Seriously, yes. That is the only dependancy I have in there, as far as
references go.
Let me know if you are able to get it working. If you aren't, I'll work
on making it a little more backwards compatable so that you can give it
a test drive with the 3.0 series.
--Joseph
Joseph M. Ferris
> b) Can I do something similar for the XSL file, in a similar way in which if
> I wanted to generate some HTML I might use FrontPage?
XSL is just a scripting language that works within the bounds of its
language definition and is, in itself, a well-formed XML document. A
quick, bring you up to speed type of tutorial would be
http://www.w3schools.com/xsl
As far as automated tools for XSL generation, there are a few. XML Spy
(http://www.xmlspy.com) is an all around tool that will not only edit
the XML and XSL, but allow you to design reports. I used it for a bit
and really liked it.
But I generally tend to use TextPad for editing, since I just like a
good ol' text editor. (I actually have a Widows build of vi on my
machine, too... <g>) But I do have some more XML/XSL geared editor
links in my bookmarks that I have not evaluated yet:
http://www.syntext.com/products/serna/illustrated.htm
http://www.tagfree.com/english/product/product01-1.asp?menu=0
http://www.xmlsoftware.com/xsleditors.html
The last link is just a list of editors.
--Joseph
Bonj
> right now and we have not migrated yet. (Why change it if it isn't
> broken? <g>) I have a local SQL Server 2000 Server to develop against,
> but I have not played with any of the XML goodies yet. Once we deploy
> our next project, we should hopefully be moving on to there.
That's interesting... I was banging on and on to my boss that we should
cluster our servers a while ago but now I'm not so sure - because the type
of stuff we use SQL servers for (large extracts and long-running
transformations) it is heavily bottlenecked on disk-IO rather than processor
activity - there is not that many concurrent users trying to access small
data often - rather just a few with big jobs.
>
> The article that I sent you the link to is probably going to be my first
> foray into Microsft SQLXML world. It is just another one of those
> things that they don't put enough time in the day for. ;-)
Tell me about it.... I'm in the annoying predicament of not being able to
rest with myself until I've managed to bootstrap gcc3.4 for mingw32... :-)
which takes about an hour and then falls over due to not having bison and
flex, and it's not much consolation that there was a messages on the
newsgroups saying there is a computer that can build it in under 2 minutes,
with SIX processors!! <g>
Whilst at the same time now learning XML ! Nice really though, to never be
bored and all that...
I clicked the 'configure XML support' button and it simply fired up IIS,
which i've now got installed on my PC at work, which although I wouldn't
want to productionalise anything on a non-server is useful for giving those
in power some demonstrations! I think I'll be going down the route of using
ADO to save XML, it seems the perfect integration.
Bonj
I presume it's freeware license is it? Might think about putting it on my
box at work you see..
"Joseph M. Ferris" <joseph...@cox.net> wrote in message
news:u2sTnsS...@TK2MSFTNGP10.phx.gbl...
Joseph M. Ferris
> That's interesting... I was banging on and on to my boss that we should
> cluster our servers a while ago but now I'm not so sure - because the type
> of stuff we use SQL servers for (large extracts and long-running
> transformations) it is heavily bottlenecked on disk-IO rather than processor
> activity - there is not that many concurrent users trying to access small
> data often - rather just a few with big jobs.
We use ours as a central repository for data fragments. There is a high
volume of small requests. I inherited the configuration when I started
here. Lucky me, I was the first full-time VB developer after a
truckload of consultants finished a project.
It has actually worked fairly well so far. The sample scalability tests
that we have run on moving to SQL Server 2000 with the current codebase
have actually shown an improved performance over the cluster. Of
course, the front end that was inherited from the consultants is less
than scalable and will need to be brought up to snuff prior to switching
off on the back end.
> Whilst at the same time now learning XML ! Nice really though, to never be
> bored and all that...
Amen to that... I am always either trying to keep ahead of the
managerial curve here at work, or trying to keep my resume up to snuff.
You know it is bad when your personal reading collection is nothing
but IT related books and magazines.
> I clicked the 'configure XML support' button and it simply fired up IIS,
> which i've now got installed on my PC at work, which although I wouldn't
> want to productionalise anything on a non-server is useful for giving those
> in power some demonstrations! I think I'll be going down the route of using
> ADO to save XML, it seems the perfect integration.
That is pretty painless... We have a couple of IIS boxes, but we don't
allow anything outside of the firewall to connect to those machines on
any port. It is nice having a mixed environment, though. We can put
the business logic and data access code in handy DLL files that the web
developers have no access to (or knowledge of how to use, even if they
had the access). We are working toward implementing a straight web
service approach where all tasks on the Linux boxes will need to
originate in a SOAP request (another XML document) and will be
communicated to the IIS machines. That is actually the point I sold
everyone on here - we can separate the presentation layer out and not
have to worry about anyone having access to the business logic.
--Joseph
Joseph M. Ferris
> I'm downloading xmlspy, it looks like all I want and more.
> I presume it's freeware license is it? Might think about putting it on my
> box at work you see..
Its only a trial unfortunately. We have a five license seat at work for
it. You can get the home edition for $59, professional for $499, and
enterprise for $999. The cost of the liscense is the reason that we
have not upgraded. It has gone up considerably in the past two years.
The addition of the home edition was nice, but it is a little thin for
what we would need it for.
There are a couple of projects on SourceForge that I am watching with
interest. Things like Jaxe (http://jaxe.sourceforge.net/), but nothing
that approaches the toolset of XMLSpy.
I know that IBM had an editor called Alphaworks, or something similar,
but I don't know whatever happened to it.
--Joseph
Bonj
hope you'll employ them again!
"Joseph M. Ferris" <joseph...@cox.net> wrote in message
news:%23qqxaXT...@TK2MSFTNGP09.phx.gbl...
Jim Carlock
> That's the problem with consultants ... they'll make it unscalable
> in the hope you'll employ them again!
I resemble that remark. :-P
Bonj
that case don't - just make so it's only unscalable by someone else other
than you.
"Jim Carlock" <anon...@127.0.0.1> wrote in message
news:%23bsqQfw...@TK2MSFTNGP10.phx.gbl...
Jim Carlock
If I catch them, you scale them. You like trout?
--
Jim Carlock
http://www.microcosmotalk.com/
Post replies to the newsgroup.
"Bonj" <a...@b.com> thought a little too loudly:
You mean YOU make things unscalable, so people will employ you
again? In that case don't - just make so it's only unscalable by
someone else other than you.
"Jim Carlock" mused upon "Bonj"'s musings of:
Bonj
I suppose
"Jim Carlock" <anon...@127.0.0.1> wrote in message
news:eZz7vd4E...@TK2MSFTNGP12.phx.gbl...