[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Suggested guidelines for using local types. (was Re: Enlightenment viaav
From: "Fuchs, Matthew" <matthew.fuchs@c...> I wrote > > 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.... --> > > > > Why would anyone write such ugly, unextendable code when you can write > "match=x:person/x:name"? That was already in the line before (except I got carried away and went all the way up the chain, as I think Nicolas pointed out). > With the "if" statement, you need to go into the > body of existing code every time some new elements are added and insert > pieces all over the place. With the two level match, you just append > templates to the end. Aarggh. The point of the example is when we start off with a schema in which all names are known to have global or local types: we can for these make match="x:person/x:name" for the local case and then match="x:name" for the global case. But when someone adds a new local name, bang, it causes the fragility problem. The new local name is matched by the global template. The fact that I can go and add some code (whether I do so by using ifs or longer paths is irrevelent) and make fix things up. The issue is robustness in the face of change. I have always thought that the X in XML was extensibility: we can extend existing document types and if our processing software has been written correctly, our loosely-coupled clients will continue to work correctly. XS even gives us the nice restriction and extension mechanism to help us if we want to make sure that when we change something any processing scripts (not relying on position-from-the-end data) will still work. But local types using existing global names white-ant extensibility, for the fragility reason above. The only way to overcome this using the current generation of software is to get everyone to enumerate every context in which a name can appear. match="x:person/x:name | x:tedious/x:name | x:pathetic/x:name | x:unworkable/x:name" In other words, by treating _every_ name as local. Of course, then when we add any new element we have to also add it as an allowed context on the matches for its children. > Multilevel matching handles locally scoped names quite handily. You are talking about redesigning XSLT because is doesn't fit in with XS' PSVI. I am trying to figure out what best practise are for schemas, for developers who are deploying the current range of non-PSVI software, who have to use the current designs. In any case, scoped matching does not solve the fragility problem. The reason the fragility problem is important, b.t.w., is because on the web we may have thousands of clients, and it is infeasible to up-grade them whenever we change our document type. For a start, because the installation may involve new libraries or system administration, etc. The advantage of extensibility should be this robustness in loosely-coupled systems. If a change in the schema causes a failure or bad data, then we have tightly-coupled system: and if we are in a situation where tight-coupling is feasible, why are we using XML instead of CORBA or COM or RMI etc? > If they're unqualified, and the rule to catch the > global element has a prefix, then it won't match the local names, once again > demonstrating why local names should be unqualified. So lets attempt to formulate a best practise rule. Q=qualified, U=unqualified G=global binding of a name to a type, L=local binding of a name to a type L' - local binding of a name to a type which is an extension of restriction of a G using the same name Some combinations of these are fragile. In particular using all of them: QG + QL + QL' + UG + UL + UL' A robust combination is QG + UL + QL' And the simplest formulation of this is merely QC + UL and the whole issue disappears if everyone uses just QC where possible (or QC and QL' to get slightly stronger typing without compromising robustnes). 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
|