Dreadfully tedious questions

[David Megginson]

Joshua E. Smith writes:

 > 0) What FAQ did I miss which answered these must-be-frequently-asked
 > quesions?!?!

That one that you can write and distribute when you've finished
collecting the answers (??).

 > 1) What case do I use?
 > 
 > Judging from MathML and SVG documents I've read, it looks like the
 > trend is toward all lower case tags.  Is this the consensus style
 > out there?  What if my tag is two words?  Would:
 > 
 > <twowords/>
 > <twoWords/>
 > <two_words/>
 > <two-words/>
 > 
 > or some other style be the preferred approach?  I know this may
 > seem unimportant to you, but believe me, programmers care about
 > case A LOT!  I want to be consistent with what everyone else is
 > doing.

I rarely see <two_words>, but both <twoWords> and <two-words> seem
fairly common, and <twowords> shows up occasionally.

 > ] The next question *was* going to be:
 > ]
 > ]2) How the heck do I decide whether to use an attribute or an element?
 > ]
 > ] But after reading about 100 messages on the subject in the Oasis
 > ] archives, I've concluded there is no answer to this question!

Correct.

 > ] I'll rephrase...
 > 
 > 2) Will the forthcoming very smart XML editors do better with one
 > of these over another?  [attributes/elements that is; this question
 > derives from a common answer that the editor you are using is a big
 > determiner of what is a better design, which struck me as a bizarre
 > way to choose]

Although this will not necessarily be the case (especially with smart
stylesheets), the general trend is for element content to be visible
on the screen and attribute values to be visible only when you call up 
a dialog box.  From an editing perspective, I tend to use elements for 
most of the important information, and attributes for stuff that I
don't need always to see (such as ID's).

 > 3) Is expat the best choice for embedding an XML parser in my plug-in (the
 > plug-in is written in C++, of course)?

Expat's been well tested.  SP has been even better tested, and unlike
Expat, it supports DTD validation; however, SP has a basically
undocumented and extremely complicated interface, and it's really a
full SGML parser.

IBM has a brand-new parser, xml4c++ (I think), at alphaworks.ibm.com.
This hasn't had the field testing that Expat and SP have had, but it
looks promising.

 > 4) Should I use one of the schema contenders to define my DTD?

Sure, if it's helpful.  One nice thing about most of the contenders is
that you can mix the schema and its documentation in a single document
for easier maintenance (as you mention below).  Be prepared, though,
to write a program to generate a DTD from your schema, and eventually,
to write a transformation tool to convert the schema to whatever the
XML Schema group chooses.

 > I have a lot more to say about my elements and attributes than just their
 > syntax.  At a minimum I'd like to document each of them with a little
 > comment-size blurb.

 > If there's a good chance I could capture this together with the syntax
 > using one of the XML schema approaches, run that through a program to
 > produce the DTD, and later have the schema ready to provide to a very smart
 > XML editor (which could pop up tips based on my embedded documentation),
 > I'd rather invest the time to do that now.
 > 
 > Is one of the schema approaches winning the standards battle?  Do
 > schema->DTD translator tools exist?  Do the XML editor writing companies
 > realize how cool this capability would be?

You'll know what's happening when the Schema WG releases its working
draft.  Personally, I expect to see something completely different,
with individual features chosen from each of the contenders.

 > 5) Have the browser guys figured out how they're going to farm out
 > individual elements to plug-ins?

I'm sure that Microsoft has, but don't count on the Web community
marching in step.

 > It's kind of obvious that XML is a really good way to fix the headache of
 > plugin/ActiveX/applet incompatibilities in HTML.  Isn't it?

Yeah, well, maybe.  At least, you can keep the data for your
plugin/ActiveX/applet in the same format -- otherwise, the
incompatibilities are still there.

 > Thanks in advance.  I promise future questions won't be so basic! ;)

Nothing too basic here -- you proved yourself by looking up the FAQ on 
elements and attributes before posting.


All the best,


David

-- 
David Megginson                 david at megginson.com
           http://www.megginson.com/

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)