[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Tags and Types (was Re: Re: maps)
From: "Jonathan Borden" <jborden@a...> > I am all for pluggable type libraries. Aside from that, any fact that XML > is verbose is not something that we've been too concerned with. (we've all > heard this before). And, as a result, it is very hard to make tools for XML. Take that <position> example. A way to declare the rules to go from a lexical space to a value space (e.g. using grammars, picturess or whatever) would allow a nice user interface where the user types an idiomatic entry and the GUI converts it to markup. Just as much, it would allow someone with a simple text editor to enter the values and validate. (In some cases, the rules might be reverseable and help rendering too.) No losers, as far as I can see. That XML removed out SGML's facilities for parsing text and implying tags, does not mean that it is not appropriate or practical functionality for some other layer to have some system of declarations. (As XML Schemas found out with their derivation by lists and unions.) > Yes and the corrollary I'd add is that any short term benefits one might get > with compact syntaxes is usually lost on the long term problem of dealing > with such syntaxes. Time to move onto the harder problems of assigning > semantics to the syntax (e.g. business rules). Would you include COBOL pictures in that? They seem to have been one of the most successful and long term syntax-defining techniques. "Let's get on to business rules" is irrelevent to people in publishing who do not have business rules in their data in that way. Otherwise, we will be left with complex tools but no data, because the stage of getting from what people want to read and write and the particular types that committees have decided on has a standards gap. In the data capture world, GOMS and low-training are still king. Complex data values should not be sniffed at. Here is an example from http://www.w3.org/TR/SVG11/paths.html <?xml version="1.0" standalone="no"?> <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd"> <svg width="12cm" height="5.25cm" viewBox="0 0 1200 400" xmlns="http://www.w3.org/2000/svg" version="1.1"> <title>Example arcs01 - arc commands in path data</title> <desc>Picture of a pie chart with two pie wedges and a picture of a line with arc blips</desc> <rect x="1" y="1" width="1198" height="398" fill="none" stroke="blue" stroke-width="1" /> <path d="M300,200 h-150 a150,150 0 1,0 150,-150 z" fill="red" stroke="blue" stroke-width="5" /> <path d="M275,175 v-150 a150,150 0 0,0 -150,150 z" fill="yellow" stroke="blue" stroke-width="5" /> <path d="M600,350 l 50,-25 a25,25 -30 0,1 50,-25 l 50,-25 a25,50 -30 0,1 50,-25 l 50,-25 a25,75 -30 0,1 50,-25 l 50,-25 a25,100 -30 0,1 50,-25 l 50,-25" fill="none" stroke="red" stroke-width="5" /> </svg> Oops, did someone forget to tell them that terseness is of minimal importance? Or is it that there is a sweet spot at which point specialist and idiomatic notations (paths, URLs, dates, positions, Xpaths, styles, measurements, etc) are appropriate? Indeed, is it positively bad for readability (and therefore maintainability, comprehensability, cheap-tool-ability) to have no embedded notations for complex values? No one (except maybe the YAML people :-) would be saying you must never use XML! But I don't believe that most people buy into the idea that all structures should be marked up regardless of idiom or verbosity. 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
|