OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   RE: [xml-dev] Re: XML and Complex Systems (was Re: [xml-dev] Re: An Arc

[ Lists Home | Date Index | Thread Index ]

XSLT is often advertised as document to document for 
some n of document.  He picked the boundary cases we know are 
there and are difficult.   He made the complaint we hear 
over and over again ("I need procedural constructs") and 
that is a lot like what I hear when it is claimed XML 
concepts don't match mainstream computing.  Maybe 
mainstream computing is *behind the times*.  It is easy 
to be elegant and out of step with the tools on the desk. 
That's the dicey bet we make in this business.  To an 
OOPMan, XML is a throwback to a data object.  To a 
DataMan, XML is a step up from CSV. BTW:  the XML SIG 
did have these arguments more than once.  Tim Bray 
said it best with, it hits a good compromise for 
enabling interoperability.  To which I add, Thou 
Mayest Not PROGRAM in XML, just with it.

What I am asking per the original posts is did any of that 
happen as a result of choosing bottom-up design over 
top-down design in XSLT?  Hmmm.  Did that choice ever really 
get made?  Or was it a case of "we have all these nice 
notions from DSSSL and we'll simplify that and see what 
is left, toss it out there, see how it is used and what 
is complained about by whom, and wait for the next release"? 

Is it realistic to retrofit complex systems concepts to 
a human process (non-linear humans, remember) and then 
inquire of the output if it is broken?  I don't think 
it is.  It is completely legitimate to take a test case 
and see if one can test a clearly stated requirement.  
In too many cases, such tests cannot be made because the 
requirements are stated at a level that make it easy for 
the human process to declare a minimal victory at some 
point, but not to determine if the feature set of the 
product is complete.  No one is right or wrong here; 
he says it won't easily do what he has in mind, and 
unless one cites chapter and verse of the design 
requirement, no one can say he is wrong.  We expect 
requirements-as-controls to emerge from use.   If 
that is so, XSLT fails by his example.   If we question 
his example, we have to prove it is out of scope.

len

-----Original Message-----
From: Elliotte Rusty Harold [mailto:elharo@metalab.unc.edu]

He is completely confused about what the intended purpose of XSLT 
actually is. It was never intended to do what he wants it to do. It 
shouldn't be a surprise he has trouble. Nor should this be considered 
a knock on XSLT, since none of his use cases are something XSLT was 
ever intended to handle.

This article is the rough equivalent of a review of giving a toaster 
oven a bad review because it won't wash dishes.




 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS