> Not knowing the complete design or the system requirements or 
> what XML is used for within this system makes it difficult to 
> draw sweeping generalizes about a design.

I would say that being detached from it and seeing it from a distance
makes it much easier. You don't have to take my advice but I would
strongly recommend it: you are building your house on quicksand.

I have seen a £5m project delayed by three months because it exploited a
feature in a Microsoft XML parser that allowed </> as a shorthand for
XML closing tags. When Microsoft fixed this non-conformance to the XML
standard, the project had to negotiate changes with half-a-dozen
subcontractors. Standards matter, and you ignore them at your peril.

Michael Kay
Software AG
home: Michael.H.Kay@xxxxxxxxxxxx
work: Michael.Kay@xxxxxxxxxxxxxx 




> 
> Worrying about whether MS will no longer preserve document 
> order in attributes in their next release is of far less 
> concern then worrying if they are going to quietly change the 
> way events are handled in IE.  They have done the later, but 
> not the former.  Yes, it is not garneted that MS will not 
> make such a change, but there are no guarantees in life.
> 
> The performance hit that would impact this system to move to 
> referencing attributes in a DOM by name instead of by index 
> is tremendous.  The performance hit is in Dll and script 
> files.  Such a decrease in performance is viewed by the 
> global user base for this application as unacceptable.  The 
> only location there is any concern in the system is two 
> transformations (soon to be down to 1).  In all other cases 
> the information flows directly from database stored 
> procedures.  Unless there is going to be a radical change to 
> the way queries are run to no longer enforce field order to 
> be what the query stated, then there is no concern there.  
> The impact of that kind of a change is far reaching and would 
> require all kinds of changes to SQL standards.  The 
> transformations are an easier way to get the data pre-built 
> and avoid a number of string concatenation events in a dll.  
> They are by no means a cornerstone of the application.  This 
> was not a decision made lightly, it was one made on 
> probabilities.  It is unlikely that MS will make a change to 
> randomize the order of attributes output by a transformation, 
> so that makes the work effort involved in coding around a 
> remote possibility extremely difficult to justify.  Simply 
> because it would be preferable does not make the cut when the 
> bottom line is cost.
> 
> Along those same lines are some of the properties available 
> in MSXML, these are not part of a standard, but does that 
> mean you should not use them? MSXML is a tool, using what the 
> tool provides and knowing what the tool does allows best use 
> of that tool for a given situation.  That doesn't mean the 
> tool won't change over time, but it does mean that you have 
> to be aware of the pluses and minuses of using any aspect of any tool.
> 
> 
> -----Original Message-----
> From: owner-xsl-list@xxxxxxxxxxxxxxxxxxxxxx
> [mailto:owner-xsl-list@xxxxxxxxxxxxxxxxxxxxxx]On Behalf Of Michael Kay
> Sent: 6. august 2002 11:50
> To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
> Subject: RE:  Stuck on Name() and variable
> 
> 
> > I know that this does not follow standards set for XML.  
> The order of 
> > attributes in this case is well defined.  This is an 
> internal process 
> > handling internally generated data.  The processes that handle 
> > externally generated data do not make any assumptions on attribute 
> > order.  To the external world the standards are generally 
> followed.  
> > Internally, to handle data population and display, 
> attribute order is 
> > very tightly controlled.  It was a design decision made roughly 2 
> > years ago.  I have no worries about attribute order, SQL Server and
> > MSXML don't alter attribute order.  I try to make sure all
> > developers on staff are aware that we are making use of a
> > behavior that is not part of a standard.
> 
> You should also be aware that no vendor will make a 
> commitment to maintain such behavior across releases. I think 
> this is an appallingly bad design decision.
> 
> Michael Kay
> Software AG
> home: Michael.H.Kay@xxxxxxxxxxxx
> work: Michael.Kay@xxxxxxxxxxxxxx
> 
> 
>  XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
> 
> 
>  XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
> 


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list