OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] Is "Hand Authoring" XML still a critical use case ?

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

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS