From: Gavin Nicol <firstname.lastname@example.org> Date: Fri, 9 Aug 1996 19:06:44 GMT Message-Id: <199608091906.TAA12357@wiley.EBT.COM> To: email@example.com CC: firstname.lastname@example.org, email@example.com In-reply-to: <9608081549.ZM7155@gaia.ckm.ucsf.edu> (firstname.lastname@example.org) Subject: Re: Generic Markup [was:Re: deprecated tags in Wilbur & Cougar] >Because at this time its easier for indexers to read data in THE >well-known DTD, HTML, and derive any structural information (mapped >from an arbitrary rich DTD into HTML's generic structural elements) >through a (hopefully) standard set of structural attribute values. If they can parse HTML and derive structure from attribute values, and actually make use of that structure, they can do the same for GI's. In fact, for indexing purposes, you'd probably get better indexes built (you can search by containment and attribute values). >How can you establish structural context amongst objects encoded in various >DTDs, and how can you do this earlier than six months after Cougar is >finalized? Using <META> (though this requires a bit more work), or some external mapping specification (perhaps bring back <RENDER> for the external mapping file). I should note that your question is actually fundamentally deeper than just HTML. The problem of DTD equivalency is a very difficult one, though architectural forms can help. >|4) Given the interaction between GI and attribute selectors, doesn't CLASS >| complicate stylesheet writing as compared to pure GI's? > >I haven't written a style processing language, so I can't say for >sure, but powerful functionality usually implies a higher level of >complexity. When the content provider$ demand functionality, they >usually get what they want first... In this case, it's the opposite. The complexity is generally not useful at all. Qualifying styles based on ancestry is useful, and using attributes as selectors for the leafs is, but once you combined them together, you need a quite sophisticated engine (ie. just checking a tag stack vs checking a tag stack, and gi + attribute values on all contained elements). >|How many attributes did you propose? > >The debate earlier on STYLE attributes proposed one. CLASS proposed a second. >Both of these attributes are included in the Cougar DTD. ROLE that I propose >would be a third. Your example used COLOR... >For now, store richer, serve poor(er). Use complex structural markup >behind the server and serve for maximum interoperability using a >common subset such as HTML enriched with structural hints alongside >the style hints. This is pretty much what DynaWeb does today. My real point is this: I can understand the desireability to map to HTML for some purposes. However, the use of the mechanisms you are talking about would head to HTML that looks like this: <BODY CLASS=BOOK> <H1 CLASS=TITLE>My Book</> <DIV CLASS=CHAPTER> <H2 CLASS=TITLE>My first Chapter</> <P CLASS=QUOTE>They were the best...</> <P>This is some text... </DIV> </BODY> or perhaps <P CLASS=CHAPTER> <P CLASS=TITLE>...</> <P CLASS=QUOTE>...</> </> In both cases, I cannot see why anything that can actually *use* the structure shown by the CLASS attribute for anything beyond style selection, cannot also use a form that uses GI's. Internally, the application would need to be quite sophisticated to make good use of attributes like CLASS, so they would more than likely contain more than enough functionality to handle arbitrary GI's.