| [Thread Prev]
| [Thread Next]
| [Date Next]
| [Thread Index]
Re: [xml-dev] Is "Hand Authoring" XML still a critical use case ?
- From: "Pete Cordell" <email@example.com>
- To: "Michael Sokolov" <firstname.lastname@example.org>,"B Tommie Usdin" <email@example.com>
- Date: Fri, 10 Dec 2010 13:07:31 -0000
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).
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.
> 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
>> * subject matter experts -- whose real job is writing about some
>> * 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
>> metadata, and prepare publications for typesetting and/or electronic
>> * 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
>>> 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
>>> 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
>>> 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
| [Thread Prev]
| [Thread Next]
| [Date Next]
| [Thread Index]