2011/12/9 Tom Hacohen <t...@stosb.com>: > On 09/12/11 04:18, David Seikel wrote: >> As I understand it, text tags are entirely up to the developer using >> the API to define for themselves. They are completely free to use what >> ever works for them. They are opaque tags, and could be any damn thing >> the developer wants. >> >> XML should not be encouraged, it's a solution in search of a problem >> that has yet to find any problems it's actually a good match for. In >> the mean time, it's been applied to many things it should never have >> been used for, coz people think it solves the most important, top >> priority, bugger anything else "problem" of being "human readable". >> Most XML data never has humans read it. Lots of XML is not human >> readable anyway. Most XML just takes up more space, takes more time >> and resources for computers to parse, takes more time and uses more >> bandwidth travelling from one computer to the next, and generally just >> wasting every ones resources. >> >> On the other hand, being somewhat similar to HTML might be a good thing >> for text tags. It's a similar sort of thing that lots of people are >> familiar with for a similar sort of job. HTML is not XML. It looks a >> lot like XML, there is a subset that tries to be XML compatible, but >> HTML is not XML. >> >> In the end though, it's up to developers using the API to decide for >> themselves what text tags they will use in their own projects, isn't >> it? They may choose to use completely human unreadable symbols, with >> zero similarity to XML, for their text tags, for their own reasons, >> secure in the knowledge that for their own app, their odd choice of >> symbols is of no consequence. That's certainly the way I read the >> documentation when I was using the edje API that wraps evas for my own >> application. Then again, that documentation left me guessing a few >> things. >> >> I certainly don't think XML should be forced on people. Or HTML for >> that matter. I didn't mean to bring up a XML discussion here ;-) Didn't want to imply our text markup uses XML. Just that </foo> is an (in the world of XML terminology) "empty tag", which is also valid XML. This does not mean it isn't a "dog" in parallel universe. So please don't discuss the pros and cons of dogs ;-) > > I completely agree with everything you said, and I also dislike shoving > XML everywhere. > > This patch adjusts textblock's markup to support "empty" tags. Why is it > supported? because of the way that textblock works, that you can insert > formats without tags (legacy syntax) using direct function calls, thing > got a bit to ambiguous. For example, the format \n if inserted through > format_append would have caused a <\n> tag to be created when markup was > retrieved. Thus, when re-inserted, it would have been interpreted as "+ > \n" i.e open a new format, newline, which is incorrect (esp. since it > was an empty tag before). > One way of solving it, could have been, just matching against all the > formats we know to be the empty and handle those as such, but that > didn't feel as correct as doing what everyone know and use. > > Generally, this makes the markup more strict which in turn will let us > handle markup in a faster, more defined, and nicer way. :) > > Thanks a lot for your comments, and I hope you share my opinion. > > Daniel: Leif is right, it's an empty tag and should be used as such. > > -- > Tom. > > ------------------------------------------------------------------------------ > Cloud Services Checklist: Pricing and Packaging Optimization > This white paper is intended to serve as a reference, checklist and point of > discussion for anyone considering optimizing the pricing and packaging model > of a cloud services business. Read Now! > http://www.accelacomm.com/jaw/sfnl/114/51491232/ > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
-- Leif ------------------------------------------------------------------------------ Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
