Re: [xml-dev] Is "Hand Authoring" XML still a critical use case ?

["Pete Cordell" <petexmldev@codalogic.com>]

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