Associating DSSSL style sheets with documents
cbullard at hiwaay.net
Sat Mar 15 04:11:02 GMT 1997
Tim Bray wrote:
> Well, a DTD, considered as metadata, is pretty thin. It doesn't
> contain any semantic information, nor much in the way of strong
> data typing. I can't think of much that is useful for downstream
> processing that would naturally live inside a DTD.
You must not do much conversion work. It is awfully handy the
first time one sees the document instance. It sure is the
cheap way (say, non-programming) to figure out what the
intended structure is.
> The problem of
> packaging, of tying the things that you *do* need (stylesheets,
> topical metadata, typing rules) to documents is a real one and worth
> spending time on. But there is no reason to believe that a DTD
> is a very important part of such a solution.
Tieing stylesheets, no you are right. Topical metadata, typing rules,
I'm not so sure. Most of SGML practice to date works something
> Secondly, the distinction between data and metadata is, at a deep
> level, bogus; totally in the eye of the beholder.
To some extent, that is true.
> For this reason,
> it is always good and never bad to make what the author may
> consider metadata available along with what the author
> considers data. Because the author is usually wrong.
If the source system/author is wrong, this whole XML thing
is suddenly bogus. It is a matter of how one wants to
package the data. I think using #FIXED attributes works
pretty well. There are some awfully good HyTime browsers
out there. Ask Fujitsu about the one they have. The CaPH
folks and Biezunski might disagree as well.
> >[re PI's:] I'm wondering why they are suddenly a preferred
> >practice when they were formerly a deprecated practice? What is
> >worse, a DTD I send once and might be very small, or PIs I send
> >every time?
> Reasonable people may disagree.
We are all reasonable people.
That doesn't answer the second question. Why send PIs every
time if what I need to know is in a public specification,
eg, a DTD?
> I have no trouble in saying that
> I think that PIs are a useful thing, and a necessary part of real-world
> document processing. Thus, yes (gasp) I disagree with the language
> in the SGML standard deprecating PIs, and I see no reason for us
> to consider ourselves bound by it.
Oh, that part I agree with. We've used PIs quite a bit
even before they were cool. So does Arbortext. Only
the religious among us don't.
> As for once vs. many, I think that it is in general A Good Thing
> for documents on the web to be self-contained whenever possible.
Sure. And when not possible, it's nice to validate.
> And while I think it is indeed smart to try to avoid retransmitting
> fixed ancillary files (metadata, stylesheets, whatever), I don't
> think that this class of files includes DTDs that often for the
> downstream processing tasks I've seen. - Tim
I like to have a generalized editor that works first time and
every time. I hate having to keep fifteen of them for chores
that overlap. They are easier to write than parsers, even
Anyway, the DTD is easier to explain than the PIs, and I
get to build them as I need when I need. A set of XML
PIs and a set of ArborText PIs work out to be the same
thing: fized process flags.
<?xml att="" > or <xmlElement att="" >
are both value-pair lists. I don't see the
difference except that for <xmlElement att="">
I can always build
<!ELEMENT xmlElement EMPTY>
<!ATTLIST xmlElement att NUMBER #REQUIRED
turn on a free parser and find out what I have
without hiring a CS grad to find out for me.
When the data is ten years old, that has
advantages... waaaaaay downstream
xml-dev: A list for W3C XML Developers
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To unsubscribe, send to majordomo at ic.ac.uk the following message;
List coordinator, Henry Rzepa (rzepa at ic.ac.uk)
More information about the Xml-dev