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

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   RE: [xml-dev] Re: Are the publishing users happy? Why not?

[ Lists Home | Date Index | Thread Index ]

Agreed.  

Should one design the XML (not the editor; 
that is a different topic) to enable the author 
to edit either the pieces they need to edit at 
that time, or all of it at once?

DO namespaces help?  Should the editor 
be namespace-aware?

I used to put giant OR groups at the tops of 
SGML DTDs to make it clear to the author that they 
could choose a part of the document type to 
work on.  Cheezy, but it did work.  Remember, 
that this was for a document in which the 
types of information are spec'd in advance: 
techical manuals, so the author does not have 
a much freedom to choose the content types,
the content structures, or the order of entry. 

I agree that thinking of any XML in the same 
terms as one builds for a technical manual is 
flawed thinking.  The doc type can determine aspects 
of the task and vice versa.  No size fits all. 
That aspect made it difficult to build decent 
SGML editors, and I suspect, XML editors as 
well although XML sanctions well-formedness and 
in SGML editors, well, we cheated. ;-)

A point Rick has brought up in the past that 
deserves attention:  one must be able to turn off 
the XML validity checking and edit freely. 

One of the things XML-Dev has helped with, IMO, 
that has been beneficial is Roger Costello's 
Best Practices Guide.  I review that every time 
I have to do a schema.  While I assert it is 
also important to have this list as a steam valve, 
it is at it's best when it is assembling what it 
agrees to and making that available in concise 
packages.
 

len

-----Original Message-----
From: Simon St.Laurent [mailto:simonstl@simonstl.com]

A lot of developers see XML editing as
filling structured containers with appropriate content, and the
containers should more or less guide you as to the content.  This can
mean that a huge amount of detail needs to be dealt with at one pass,
and it often has meant that developers create interfaces which are
actually more difficult to use than paper forms.  Leaving markup for
later lets people focus on the information as they see it rather than
forcing them from the outset into someone else's preferred boxes.




 

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

Copyright 2001 XML.org. This site is hosted by OASIS