On Wed, 05 Jan 2005 23:25:28 -0500, Donald Firesmith
<donald_firesmith@h...> wrote:

>Okay.  Then what are you supposed to do in the following situation? 

There are two levels at which you have to think.

First of all is a project management level. You're putting a big new
system together and you're doing it with a wide range of new tools.
You need to understand these tools before using them - otherwise your
chosen design might be rather less than ideal....

Of course, a budget would allow you to hire in some help at this
point. I can tell you that a few days of my consultancy rates are
_much_ cheaper than a few months of my grunt coder rates trying to fix
it afterwards. Not that any project manager ever listens, oh no.

The second level is that of the design itself. Much of this is based
around toolsets or platforms, both those that are appropriate and
those particularly familiar from past experience.  XLink is probably
relevant to you, XSL:FO isn't.  Are you a Java & Unix shop, or a M$oft
gulag ?

It's typical of XML that the tools chosen aren't particularly
problem-specific. I can sketch out a rough architecture for you, and
the tools you need to look at, and this will be the same whether
you're describing your knowledge-based virtual product, or tins of
beans in a supermarket.  It's a bottom-up design process - the tools
are chosen by your need to publish in HTML, and your entities' need to
represent their inter-linkage, not what the entity itself is about.

>Assume that you have  over 1000 items that you want to document using 
>XML instead of HTML.  For the foreseeable future, you will use them to 
>generate webpages primarily for human consumption.  You are mainly 
>converting from HTML to XML so that you can build tools that help you 
>select and tailor the contents of these 1000 items.

Been there, done that, have an entire wardrobe of conference t-shirts
on the subject.

Ditch the HTML fixation. HTML has three good things about it; it's the
thing to use for final-stage publishing because it gives you
web/intranet access at very low cost. It's familiar to many people for
authoring, so you can use it as an internal lightweight text editing
format and capitalise on much existing experience. It also has some
features for representation of text formatting and some _minimal_
features for representing links.

On the other hand, it's not what you need for the internal
representation of abstract data. There are uses for it in the external
interface, but no needs for it in the internal representation. In
patrticular, choosing HTML as the basis for your link representation
is going to be a whole world of pain. Forget using HTML to represent
your links. Look at XLink instead (a bunch of properties you'd place
on one of your other elements).

For HTML, use XHTML.  Trust me.  You can always make it into HTML 4.01
at the last moment, but keeping your internal data stream as XML-clean
not HTML or SGML is a big saving of effort.

I'd suggest Schema over DTD, and possibly looking at OWL.

In general, don't invent a new schema but assemble one from
pre-existing and widespread standards. Namespacing is useful here.
You will probably need to invent _some_ schema, but this can be very
minimal - just a container for properties that are described by
pre-existing schemas.

Look into Dublin Core, particularly the qualified form. You can do an
awful lot with just this much, and it gives you useful benefits to
external publishing in a vaguely communicable format.

For representing text markup, then you can use either HTML or DocBook.
I don't particularly like either, but not using one of them is a brave
decision that would require some real justification. Both are bloated
by legacy features (especially DocBook), neither are particularly
powerful in a general sense.

XSLT can do nearly everything you need here, including the
construction of all the linkage in external HTML that you might ever
wish. XSLT isn't the general solution to everything that is often
claimed, but it'll do you here.


If it were me, I'd use RDF instead of XML.  It has advantages for this
sort of meta-description problem.  These are mainly in the ability to
build such a system and then exchange its data with external systems
in a fairly easy manner. 

XML is _very_ low-level. You have no implied data model to it. until
you build one with schema. RDF gives you a little more than this, and
it gives it to everyone in a consistent and commonly shared manner.
There are objects (with implied notions of identity) and they can have
properties. these properties can in turn have type, which may be
shared between different properties. Type in turn may be used to imply
values being members of a controlled vocabulary.

A controlled vocabulary for your properties is an excellent thing to
have, and OWL is a useful way to express them.




As to publishing in HTML, then this is easy but also trivial.  Your
original question of how to publish structured content in the
attributes of a <meta> element is well-intentioned but somewhat
misguided. You can publish here, but there's nothing that will look at
it to try and read it.

HTML, as an output authoring medium is for human readable use only.
(this sucks, but make the most of it). Forget trying to publish really
complex machine-processable metadata by it.

If you really wish to, look at the well-desciribed techniques for
embedding Dublin Core within HTML  (this is as far as one can
practically go these days).  To push things further, even though it's
still optimism rather than consumer demand that's driving it, use
XHTML and embed some RDF within it by namespacing.


You might find it useful to read up on the Semantic Web techniques,
for which I'd suggest Passin's "Explorer's Guide to the Semantic Web"
<http://www.amazon.com/exec/obidos/tg/detail/-/1932394206/codesmiths-20>
-- 
Smert' spamionam