Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: UTF-8+names
 Bill de h?ra scripsit: > I'd love to know what SOAP-oriented folks think about it. I should think they'd think it's totally useless, just like the original proposal for infoset-level names. Machine-generated XML would have no use for UTF-8+names. > It also potentially hurts interop - there are costs and benefits to > be weighed up. Flexibility and interoperability are always opposed. If we all had just one kind of computer and just one set of software, we'd all have perfect interoperability. (Hmm.) > see the encoding name changed to "UTF-8+entities", the current > name is rather vague. The whole point of "names" is that they are not entities. In fact, we go to some lengths to make sure they can be used with entities without interfering with them. > see examples of escaped whitespace. If you mean strictly XML whitespace, I think the last thing we want is to have names like "space", "cr", "lf", or "tab". These would make hideous uglifications like <foo&space;bar="baz"&space;/> possible, and who wants that? > know whether <wóoops/> is a legal element name in this > proposal. Yes. To XML, it's an empty-tag whose name contains six characters, all of them legal in names. > hear a rationale, other than use outside XML, for choosing a new > encoding to solve this problem, ie why not xml:entities="yes" or > some other approach? Because there are already zillions of encodings, and what's one more? But getting XML changed in any particular cannot be done without immense pain, as no one knows better than I. > know whether the current MathML/HTML4 sets are sufficient; ie > are we going to need to reversion this in couple of years to cater > for ogham? A very good question. My sense is that they are not sufficient, but that Ogham isn't going to be an issue either. > like elharo and Alessandro, I'm unconvinced about treatment of > &, specifically, that it isn't being overloaded in some > clever/sneaky way. Indeed, I'll claim that & /is/ being overloaded > in some clever/sneaky until the next draft shows me otherwise. What *concrete* action would it take to convince you? Proving a negative (that there is nothing underhanded here) is notoriously difficult to impossible: the unconvincee can always retort "But there still *could* be something wrong!" -- I marvel at the creature: so secret and John Cowan so sly as he is, to come sporting in the pool jcowan@r... before our very window. Does he think that http://www.reutershealth.com Men sleep without watch all night? --Faramir http://www.ccil.org/~cowan 
|
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
|
|||||||||
