Re: Is "Hand Authoring" XML still a critical use case ?
Thanks for putting your reply together Tommie. I totally agree with Mike here. DTDs would still be used as a form of light-weight schema (I hope). Thanks, Pete Cordell Original Message From: "Michael Sokolov" > I'm glad you chimed in, because content producers' interests clearly > aren't strongly represented in this list. Also, since I'm on record with > all kinds of anti-DTD statements now, let me just clarify a bit: I don't > want to see DTDs go away. Believe me, we're waaay happier when we get XML > (of the sort you describe - prosy) from folks who use a DTD than when we > get XML from folks who don't know what one is or care about validation. > And we *read* the DTD's - they are an incredibly useful tool for > understanding new content structures. What my position is, and I think it > represents a sub-consensus among the programmer camp at least, is that > DTDs should be like other schemas - used in the ways you described; for > validation; for informing editing tools, and for documenting document > structure, but not to have the special normative status that they have now > as part of the XML specification. > > In particular the unique requirements enforced on parsers and XML document > structure aren't really absolutely necessary: entity resolution in > particular, and maybe if we could have xml:id instead of needing to > validate in order to generate ID-ness, and I just learned about something > called attribute default values - umm it's those things - basically I > *think* if we can strip down XML to a state where validation is separated > from the document (but it will still be ok to have a hint in a PI or > something so long as it isn't *required* to be hunted down at parse time) > and essentially the key part of the document is the stuff inside the root > element, then I think we can *all* have what we need with considerably > less sweat. > > I think a lot of the things we've been talking about are painful for > content producers as well as consumers: often our pain gets reflected back > up the chain anyway. I bet editors just love it when we tell them - well > we can't do anything with that document you just sent us - it isn't even > XML! Just because there's an extra blank line at the beginning of the > document, or - the DOCTYPE declaration lacks a proper sequence of > identifiers (when we're basically going to ignore it anyway), or - we > can't resolve the entities (which are bog-standard ISO entities, anyway, > but have to be redefined or reimported in every DTD) because the DTD isn't > structured properly, or didn't come with the content. That's the kind of > conversation I'd like to eliminate. > > -Mike > > > On 12/9/2010 5:54 PM, B Tommie Usdin wrote: >> At 9:23 PM +0000 12/9/10, Pete Cordell wrote: >>> Original Message From: "B Tommie Usdin" >>> >>>> Are there people who hand author XML? Yes. And more often there are >>>> people who fix XML by hand. Are all of these people XML Geeks? No! Many >>>> of them are content experts, and some of them are clerical/support >>>> staff with no programming skills at all. >>> >>> To better understand how your people use XML, could you describe the >>> skill sets of your users, and how that relates to how they use XML? (For >>> example I wouldn't expect an abstract modern artist to immediately take >>> to hand crafting XML, whereas a mechanical engine might more readily.) >> >> What they have in common is that they work in prose publishing. They >> include: >> >> * subject matter experts -- whose real job is writing about some >> (non-XML) >> topic >> * editors -- whose real job is making prose clear, readable, and in >> conformance with their employer's house style >> * copyeditors and publishing production staff -- whose real job is to >> tidy documents, check and correct references, create or correct >> document >> metadata, and prepare publications for typesetting and/or electronic >> publishing >> * typesetters and electronic publishing technicians -- who create >> presentation versions (paper and electronic) of publications >> >> On the whole, their primary expertise is in the subject matter they are >> working with (it could be anything people write about, which means >> anything) and secondarily they know about the publishing process. Most >> have no programming experience at all. >> >>> >>>> I work in a world in which XML users find entities and mixed content >>>> essential, make effective use of DTDs, and find clarity more important >>>> than terseness. >>> >>> Could you describe some use-cases of how they use DTDs and entities? (I >>> completely understand how mixed is useful.) >> >> DTDs are used to validate documents, drive context-sensitive editing >> tools, and to tell the maintainers of down-stream processes when to >> expect changes in documents and what changes to accommodate. Pretty much >> the same things that many other uses do with XSD or RNG. My point is that >> DTDs are sufficient for many users and are: >> * known, at least to these users >> * compact and easy to read (once the syntax is learned) >> * consistently interpreted by a wide variety of tools >> * implemented by the tools they have and in which they have >> significant >> investments >> >> >>> >>> Hypothetically, if XML didn't use DTDs to parse a file, could you come >>> up with some other solution that your users could work with? >> >> Sure. I didn't say they needed to use DTDs, I said DTDs meet their needs >> pretty well, and they have no motivation to make a change that would cost >> them time and money and bring few benefits. >> >>> >>>> In this world document models and document processing infrastructure >>>> are stable for years while content changes constantly, so it is >>>> important to optimize for content creation and use, not for modeling >>>> and support programming. (Making life easier for XSLT programmers is >>>> insignificant compared to making it easier for document authors, for >>>> example.) >>> >>> I don't think XML 1.0 is going away anytime soon. >> >> Well, I don't think XML 1.0 is going away either. >> >> However, my users would like some improvements, too. We at Mulberry spend >> a significant amount of time explaining namespaces and solving XSLT and >> Schematron problems that were caused by misunderstandings about >> namespaces, and a not insignificant amount of time being bitten by >> namespace problems ourselves. >> >> I would like better XML, too. I don't want the smaller better >> more-understandable XML to work only for the cool kids; I want it to work >> for me, too. >> >> -- Tommie >> >> >>> >>> Thanks, >>> >>> Pete Cordell >>> Codalogic Ltd >>> Interface XML to C++ the easy way using C++ XML >>> data binding to convert XSD schemas to C++ classes. >>> Visit http://codalogic.com/lmx/ or http://www.xml2cpp.com >>> for more info >> >> > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
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