[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Tags and Types (was Re: Re: maps)
Rick Jelliffe wrote: [[ 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. ]] As I've said, this is a great example of where something like Simon's regular fragmentations provides a nice solution. The point is, is that XML ++ is better able to deal with XML than text patterns, surprise surprise. Luckily we have regular expressions and software that knows how to deal with them ... and we also have software that knows how to take a piece of text _and_ a regular expression and emit a piece of XML. This seems like a good clean solution. [[ 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.) ]] Agreed. see above. [[ "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. ]] Hardly. All I am saying is that XML specifications, and much XML software (e.g. XSLT) are naturally able to deal with XML structures/patterns rather than text structures/patterns -- witness RELAXNG, XSLT, etc. - Is this really a surprise? [[ <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? ]] This example proves exactly what? a) that use of lists of numbers and tokens in attributes is a _good thing_ ? b) that humans should magically understand this? c) that sometimes we need to make compromises? Compromises are fine, but realize that you do give something up, for example the ability to easily define subsets of such patterns, or to restrict specific ranges inside of such patterns etc. Now markup is not the only way to define structure, EBNF is often an acceptable option -- and we expect that SVG will come with specific tools, and largely not be processed with entirely generic XML tools. That tells me something about when such compromises are indicated. Jonathan
|
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
|