|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Not quite an I-D announcement
keith@w... (Keith W. Boone) writes: >Granted: Your names are clearer, and URI polution is not necessarily >a good thing. > >Your argument is that the fundamental pattern is: >MyBeastie(setting1,...) > >However, my argument is that the fundamental pattern is: >SetProperty(myBeastie, setting1, value) > : >. I believe that you've gone up an extra and unnecesary level of abstraction. I don't believe that your pattern is any more fundamental than the pattern already established by the XPointer framework in creating schemes. We could, of course, make all of the schemes into similarly abstract patterns, using a single whatever() scheme and letting its contents determine how >As you have already demonstrated by creating three different specs >that do essentially the same thing. They do not do the same thing. You can abstract it to "they all set context", but they all do so quite differently. You might note, for instance, that xmlns-local() doesn't even provide a setting or a value. And if you want to go all the way, we should likely add xmlns to the list. How comfortable are people really going to be with: pragma(http://www.w3.org/ns/xmlns/, xyz, http://example.com/ns/xyz) > And we can assume that others >will do the same. So now we have 10, 20 or even more different schemes >to recall, each with potentially different rules for use. All to >communicate some setting/property to the XPointer processor in some >way. I'd much prefer one way to accomplish the same capability, with >rules that I can remember and which don't change between properties. I don't find remembering URIs to be any easier than remembering scheme names. I don't typically write code of the form: function(functionName, value, value) I'd much prefer to write: functionName(value, value) >The semantics of the properties are perhaps unclear, but if you have >10 or 20 difference schemes to recall, I can make the same argument: >The semantics of the arguments for each scheme is not regular, and is >therefore unclear. That doesn't justify an extra layer of abstraction. Schemes are already a substantial abstraction step up from prior practice. >XML Parsers already use the URI mess to handle property naming, and it >seems that the method works, ugly as it may be. If there was another >way to handle it without URIs, would you be amenable? No. This goes too far up the abstraction tree with or without URIs. >Perhaps, we could agree upon an uber-specification for pragma-like >schemes instead? You're welcome to write one, but I would not plan to use it. ------------- Simon St.Laurent - SSL is my TLA http://simonstl.com may be my URI http://monasticxml.org may be my ascetic URI urn:oid:1.3.6.1.4.1.6320 is another possibility altogether
|
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
|
|||||||||

Cart








