[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Enlightenment via avoiding the T-word
----- Original Message ----- From: "Nicolas LEHUEN" <nicolas.lehuen@u...> To: "'Rick Jelliffe'" <ricko@a...>; <xml-dev@l...> Sent: Wednesday, August 29, 2001 5:44 PM Subject: RE: Enlightenment via avoiding the T-word > Rick wrote : > > >Why is it more efficient to make the receiver of your tables > >disambiguate the > >names (by using a PSVI or XPath) than doing it when the data > >is serialized? > > > >It is nice that every table is a separate namespace. But why > >is there any need > >to complicate XML with all this extra levels of processing to > >support that? > > There is no extra level of processing. As I wrote before, in the first case > you have XPath expressions like /stuff/person/name/text(), and in the second > case you have /stuff/person/person-name/text(). No, you have <xsl:template match="x:person-name"> rather than <xsl:template match="/x:stuff/x:person/x:name"> or, more likely, you have <xsl:template match="x:name"> <xsl:if select="parent::x:person"> <!-- oops I need this extra test because name is reused-- those darned people at x:: namespace keep on adding new local elements and our code is written to just use the markup. Why cannot they just use vanilla XML.... --> In any case, if you are saying that schema-processing a document to produce a PSVI requires no processing, I don't believe it. Why make work for ourselves by requiring a layer that a modicom of discipline will obviate (is that right: are modicoms obviated?) Obviously there are filesize issues for XML Schemas, and obviously there are comprehension and overkill issues: XML Schemas pay a lot of attention to allowing efficient storage in objects or databases but it also introduce this name fragility problem. > I may be dense, but I don't think there are so many applications out there > that care about the person-name without caring about the person itself. > Context-independent processing may exist, but I think it is not as important > as all the context-sensitive processing that is done out there. See above. > If you want to stick with the table/column metaphor, I don't know of any > relational data processing that care about a column without taking care of > the table it belongs to. But, as I have said, the table acts as a namespace. So SELECT X FROM Y acts as <xsl:template match="Y:X" > You don't have global names in that kind of DBMS per se. So mapping a set of tables into the same namespace can cause clashes. > When processing a document, you can hardcode the processing path followed by > your program : "I first process the person, then the product, then the > delivery info". Push programming and pull programming are both common methods with XML. Pull programming does as you say. You process an element and explicitly pull in specific child data as needed. But in push programming you code each element separately: elements are processed individually and pass information back to its parent or caller (or stream). You use your expectation that the document has been validated as a precondition for working on the document, which factors out the need for lots of tests. But if people re-use names for different types, push programs become fragile. A push program can be robust in the face of new names, but if you re-use existing names then you strongly couple the document to its specific schema and to the generating process. And loose coupling of distributed processing is one of the big reasons for XML. Cheers Rick Jelliffe
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|