[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Is "Hand Authoring" XML still a critical use case ?

  • From: "Pete Cordell" <petexmldev@codalogic.com>
  • To: "Michael Sokolov" <sokolov@ifactory.com>,"B Tommie Usdin" <btusdin@m...>
  • Date: Fri, 10 Dec 2010 13:07:31 -0000

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).


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]


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.

Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.