Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Enlightenment via avoiding the T-word
 > Did you want to repost this to the whole group? or is this private? Well in fact I messed up with the reply button... But I'm going to reply to your mail on the list. >> only, because the name element would be locally defined >within the person >> global type. This way you could define a stylesheet for the >"stuff" document >> that imports a stylesheet for the "person" content-model. A >local element >> gets its semantic from its context, which by definition is the global >> element in which it is defined (since a global element has no other >> context). > >Potentially it could be local all the way up. Well, the definition of a local element is that it is an element defined in a schema in the context of a global element. A local element cannot be local "all the way up". It can be buried deep inside a global element, but it must have a context, which is the global element. The fully qualified name of the global element <i>could</i> be considered as a namespace for the local element (but here, we're entering another difficult subject which relates to the qualified or unqualified form of local elements). >> As for your third template, you write in the comment "our >code is written to >> just use the markup". This is the problem. Writing code >without taking the >> context into account doesn't scale up. >> >> Suppose that you have two persons in your order, the >purchaser and the >> seller. What will you do, just add new elements named >> "purchaser-person-name" and "buyer-person-name" ? What if >you want to write >> an XSLT stylesheet with the same behaviour for both ? Or >with different >> behaviours for both ? > >Since the two name elements have the same general semantics, there is >in fact no impact of context. Well, if it REALLY had the same semantic, I would have made it a global element, wouldn't I ? Just suppose the example I forged is meaningful, please, though it's not easy :). >> I would create a document like this : >> >> <purchase xmlns="..."> >> <buyer> >> <person> >> <name>Mr Smith</name> >> </person> >> </buyer> >> <seller> >> <person> >> <name>Mr Johnson</name> >> </person> >> </seller> >> </purchase> >> >> And if I want the same processing to occur I can write this >template : >> >> <xsl:template match="person/name"> >> >> that can even be imported from another XSLT stylesheet >without having to >> know anything about the purchase structure >> >> Whereas if I want different processing to occur I can write this : >> >> <xsl:template match="buyer/person/name"> >> >> But you would never, NEVER write a template that matches a >local element >> wihout its context, because you would not be able to scale up. > >By eliminating the class "local elements" we make "would never" be >"could never". Nope. I can forge any example where a carefully defined global element name within a particular namespace would require context inspection to disambiguate its semantic. If I give you a "person-name" element, do you know what to do with it immediatly ? No, you'll ask me for the context. Okay, the context is a bill. This does not give you any information. Another part of the context, is the "buyer". This gives you a lot more information. You could then tell me "okay, so in order not to depend on the context, I'll name the element buyer-person-name". In this case, let's imagine a phony example where you are writing a bill that compensates (and mentions) other bills. What's the buyer's person name ? You have to take the context into account, unless you want to drop reusability and reinvent new element names each time you try to compose two schemas. >> >In any case, if you are saying that schema-processing a document to >> >produce a PSVI requires no processing, I don't believe it. >> >> A PSVI does requires some processing. But if you already >validate your >> documents before processing them, I don't think the overhead >would be so >> big. I think validating a document, then throwing away all >informations >> gathered during validation, to then process the document, is >a great waste >> of energy. *If* you validate your documents, why not have >the validator give >> us the information it had to gather anyway ? > >You are assuming validation at recipient. I do not believe this is how >most XML is used. Validation is used for outgoing QC and >debugging, and rarely >for incoming QA. Can someone confirm this ? I would precisely say the contrary. >> I am not saying that building a PSVI should be mandatory. > >But given that the push programming practise I mentioned is >ubiquitous, you are. No I'm not, see the other posts I made, push programming is easily done even with context-sensitive data. >If the sender of a document decides to make a local element >type (that is not >a restriction of the global type) then it creates fragility in >user systems. It only reveal fragility on fragile systems. It won't on robust systems. >> I think the model you describe is not quite realistic. If you pass >> information back to an element's parent, that means that you >have built a >> context (which is the stack of parent elements). In this >case you can easily >> select the right process to apply to your local element, the >selection table >> being changed depending on the context. Building a context >AND applying >> context-independent processes is not the thing I would do. > >Of course you can change your program, if you are notified >that the schema >has changed. But there is no system for notifying and >blocking that the schema >has changed (unless the new documents fail). If the new >document does not >fail validation, then the program keeps on working, sticking >spurious data in >unexpected places. Both failure and spurious data are signs >of the fragility I >am talking about. Same as above, see my other posts. >Whether you like it or not, if you look at most >XSLT/OmniMark/Perl push scripts, >they are written with the assumption that there is a >particular order and semantics >to an element name that will not change. A system written on >the assumption that >there are no local types is fragile when local types are introduced. I agree at 100%. But we're not *introducing* local types here ; they are already in use in the real world. As I've said before I don't think assuming that an element name has a unique, context-insensitive meaning make writing programs really simpler, because data processing is 90% of the time context-dependent (regardless of the name of the elements). >Cheers >Rick 
|
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
|
|||||||||
