Associating DSSSL style sheets with documents

[len bullard]

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 
like that.
 
> 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 
XML parsers.

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

len

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;
unsubscribe xml-dev
List coordinator, Henry Rzepa (rzepa at ic.ac.uk)