RE: EMBED and validation
>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. >Asd 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. >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. >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. >>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. 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. 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. Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer (January) / Cookies (February) 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