[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Enlightenment via avoiding the T-word
Ooops, sorry for the previous empty mail. ><address> is not a problem. Both of the addresses are, in fact, >addresses, with no syntactic or semantic difference. But wait, >you argue -- the delivery address must be treated differently than >the customer address. I would claim that the <customer> element >should be treated differently than the <delivery> element; the ><address> elements, for software that only understands those, do >not need to be treated differently. OK I get it. In fact, what you advocate here is to use context-sensitive processing of global elements ; adress could be a global element, but you would use it for charging or shipping depending on the enclosing global elements. >Why have a context at all if names are prefixed (or otherwise modified) >based on their context? Simply for encapsulation and >modularity, exactly >as Nicolas argues. The fact of structure is still useful even if the >(mere) syntactic sugar of shortening names based on context is >not present. >Java packages would still be useful even if there were no abbreviation >facility. > >Nicolas believes using multiple namespaces as a way of providing >extensibility is flawed. I would argue that this is a defect in >the available tools. There is nothing conceptually, or even >practically, difficult about using multiple namespaces in a >well-formed XML document. There is no price to pay for building >new namespaces if existing, published, micro-reusable elements >can be employed. After all, namespaces are simply more syntactic >sugar for abbreviating universally-unique names. Actually, we agree on this point : I do believe the namespace option is the best one, but apart from the tool problem, I think replacing context sensitivity by namespaces is not going to make things any simpler nor work at all. In the solutions you presented above (for address and name), you don't remove the context sensitivity : it is removed from elements names, but not from element interpretation, especially for address. So my position here is that you can't do without context sensitivity, but still use namespace to obtain unique global names (that's what a namespace is made for, anyway). >Nicolas also argues that XSLT can handle context-sensitive naming, >so it is likely that other processing systems will be able to do >so as well. I claim that this is so only within a restricted domain >where structures are predefined and immutable. For example, let us >say that we want to write an XSLT transform that will modify every >mailing address, and only mailing addresses, in a set of *arbitrary* >documents. If the documents use context-sensitive names, a list of >all possible contexts for mailing addresses will have to be provided >to the transform. If the documents use globally meaningful names, >a much smaller list of the names corresponding to mailing addresses >(potentially even as small as one name) is all that would need to be >provided. If you have only one name for a mailing adress content model, then you'll rely on context sensitivity to know what to do with the various addresses you encounter (even in presentation, you don't handle shipping and billing address the same way on a bill). We DO need context-sensitivity for content. Removing it from names won't remove it from the semantic meaning of the document. >It can be argued that this use case is spurious, but context-sensitive >names fundamentally are more difficult to deal with, because all >processing must be context-sensitive at some level. (It's possible >to confine all the context-sensitive processing to one level, if that >level transforms all such names into non-context-sensitive ones, like >NUNs.) What I wanted to show in my previous mail is that writing structured content in an XML document is a way to answer our needs for context sensitivity. If we didn't needed it, we would not have to write structured content, and simple CSV files would suffice. Contrary to you, I think that context-independant processing of structured data is VERY rare. We all have been writing programs manipulating structures or object for decades now. Try to remember when you last wrote a program that would handle separate pieces of data independantly, for example without taking care of where this Address instance is coming from - the billing field or the shipping field of my Order instance ? Regards, Nicolas >-- >Kian-Tat Lim, ktl@k..., UTF-7: +Z5de+pBU- > >----------------------------------------------------------------- >The xml-dev list is sponsored by XML.org <http://www.xml.org>, an >initiative of OASIS <http://www.oasis-open.org> > >The list archives are at http://lists.xml.org/archives/xml-dev/ > >To subscribe or unsubscribe from this elist use the subscription >manager: <http://lists.xml.org/ob/adm.pl> >
|
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
|