RE: EMBED and validation
At 6:14 AM -0000 11/29/97, Simon St.Laurent wrote: >>It's a quotation. One thing you could do is put an embedded scrollable >>window in the linking document, so that he reader sould read the entire >>linked-to document in context. > >Yes, it is effectively a quotation. Long quotations, however, often have >more >structure and require more formatting than a short quotation in a print >document, and I would like somehow to preserve that structure. Providing an >embedded scrollable window is a good idea for things you COULD do, but is not >something that can be counted on. We don't plan to create applications >specific to this document set at present; though we may do so in the future, >this document set would still be likely to cross into foreign applications. I also listed several other things you could do with the link, such as formatting it inline. My point was that the _presentation_ of the linked data is a matter for the application and/or stylesheet -- not the XML document. Do stylesheets need to be able to process such stuff -- yes, that was the point I was trying to make. I chose the nested window as a main example because I think it's a good idea that is _not_ supported by current software, but that could be enabled by the this type of link. And it's a grewatr example of how you could instantly take your old-fashoned "long quotes" and turn them into "Browsers, Inc's Web-o-Namic Nested Dcouments (tm)" without changing your markup at all. >>As with most generic markup, how it is to be displayed or processed is >>something that information providers and users must be free to change as >>supporting technology and the use of the document evolve. > >While freedom to change is certainly valuable, freedom to work consistently >with a variety of applications is of considerably more importance on this >project. Communicating more clearly the way in which these documents should >be treated by applications appears to be a necessity, as XML itself >appears to >provide no such support, nor does it sound like the readership of this list >(with a few exceptions, of course) is particularly interested in providing >such support at this time. No, you need to make an appropriate decision about stylesheets if you are providing documents. Any requirements that you have for XSL would be well made public, as input to that standardization process, now underway. If you will be delivering your documents before the stylesheet work is complete you will have to work with prerelease software or roll your own, or use CSS or compile to HTML, or something else. The lack of such presentational details in XML itself is still a good thing. You are free to create content today that will work with XSL -- even when XSL does not exist yet -- and can design your own processor if you need to. On the other hand if you invent a bunch of "conventions" that import presentation details into your documents you will simply be doing work that you will at best have to throw away, and that at worst may lead to bad encodings of your document semantics and send you back to square one to re-markup your documents. XML is the content part of the equation, and that's what it's for. XSL and its possible competitors (there _will be competitors_, because formatting is a place the people will want to compete) will be the way to realize the presentations you prefer (whatever they are) using the same technology-independent source files. > >>However, there's nothing to prevent a resonable formatting >>script from being provided as part of the format specifiation for the >>linking document that can properly format the EMBEDed data. > >Formatting script? I think we were hoping to use something more in the order >of CSS or eventually XSL. While XSL will provide scripting capabilities, it >seems like we're piling on additional complexity and new problems for >applications. Though I haven't tried it yet, it seems like it will be an odd >challenge to create a specification for the linking document that will >contain >styles for linked information that isn't included as part of the parser tree >for the linking document, particularly if the type of information to be >linked >isn't known at the time the styles for the linking document are established. >It can be done; I just don't look forward to it. I used the term script to emphasize that any programmatic trasnformation for viewing is usable -- some people have been confused by my use of the term stylesheets for link-rendering, so I've tried to avoid using _only_ that term. Sorry for the confusion. CSS or XSL are _exactly_ where this whole problem belongs. >>if you are providing such documents as part of a publication process, you >>are well-served by providing stylesheets that will format the link _as you >>want_. if you are creating some form of repository, you need to document >>the intended meaning of such links so that future creators of presentation >>and interaction specifications can provide appropriate implementations for >>them. > >What I would like to be able to do is provide stylesheets and documentation >that can be understood by a variety of processing applications that will work >in a consistent manner with linked material. The paragraph above describes >quite neatly what I want; the rest of this conversation, however, has >indicated that you can't get there from here. No, it's indicated that without stylesheets or some other programmatic process, you can't get there. This is not a big surprise, as that's the point of content markup. Yes, stylesheets are going to have to handle links. In some cases you may have to write scripts to perform interactions you want, and embed them into stylesheets. That's just part of the work of document delivery. >>>My instinct is to be as conservative as possible and make sure that all XML >>>chunks EMBEDded by a link could be folded into the linking document without >>>making it invalid, but this is a more radical constraint than I expect most > >>This is not consevative, but radical, sit it imposes an ad-hoc constrain on >>linking, based on a limited processing model. > >Radical? Radically practical, or so I thought. I'm hardly saying that >developers _should_ obey this, or that application developers should >implement >a limited processing model. Being conservative in this instance means >accepting a reasonably loose set of rules designed to make certain that >documents can still be processed in a wide variety of application processing >contexts. As I'm developing document sets here, and not applications per se, >I'm not sure this ad-hoc constraint is anything but a simple concession to >the >vagaries of the standard. If you're just talking about a rule that you want to adopt as part of your authoring process, there's no problem. You posed a question about software, and so I answered in terms of how the software should work. If you're a document provider, you will need to specify how to format linked material if you want it formatted inline. If you want it to just show up pre-scrolled in another window, I expect that XSL will have away to do that -- then you'll lose some context, but gain by having simpler stylesheets. This is a tradeoff that is independent of linking strategy. If you intend to use inline formatting, and are writing the stylesheets as well as the documents, such a discipline may well make your documents cleaner, and your stylesheets simpler The question is what these presentation details have to do with XML? >I had hoped the standard would be clearer on these issues, but the wide >latitude given applications will have a dramatic, though not especially >painful, impact on this document set and others I may create. Paul Prescod >pointed out that yes, of course, applications CAN follow several of the >models >I proposed, but that this behavior cannot be counted upon. CAN is not good >enough in many situations, so I'll develop the document set so that it WILL >work regardless of the processing model applied. Seems simple enough, though >it requires some extra effort. Paul is right, but applications that purport to implement XSL, however, will not have so much latitude when the are processing a document according to a stylesheet. In fact, they will be constrained by the XSL standard in exactly what liberties may be taken. So I think you're worrying about a non-problem, as long as you will be providing stylesheets for your documents. >Sooner or later I'll write some applications, and maybe I'll be able to take >advantage of the freedom given application developers. In the meantime, I'll >explore the constraints set upon document developers that are imposed by that >freedom. The discipline will probably produce better DTDs and documents >anyway. I don't really know what this last means, but certainly we all look forward to imporved and richer displays once the semantics of documents and the format for displaying them can be separated. -- David _________________________________________ David Durand dgd@c... \ david@d... Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://www.dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format