[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: EMBED and validation
My postings keep bouncing form the list, sorry if this is a duplicate. On Dec 1, 3:36pm, Simon St.Laurent wrote: > Subject: RE: EMBED and validation > >From a DOM perspective, EMBEDded material will almost certainly not be > >considered part of the document tree containing the EMBED element. > > I very much look forward to seeing what the DOM does (or doesn't do) with the > EMBEDded material. But is this an issue for the DOM in particular, or should > the XML-Link spec give clearer direction about the nature of EMBEDded > material? Especially as some of the replies so far have said that an > application _could_ include the EMBEDded material in the document tree _if_ > the developer so chose - which opens the door to multiple interpretations in a > large way. You're getting closer. The document, itself, contains no embedded material: it contains an "EMBED" (quitation) link to other material. It will not be a requirement for any XML application to do anything other than include the XLL attributes in it output for applications that want them. This attribute information is part of the proper domain of the DOM, as I can understand it. XLL applications will be required to interpret the link as a _connection_ between two points, with "default semantics" of "include as quotation". Whether than is most convenietly implemented boy combing document data structures, as you and Peter assume, or by some other method that preserves two structures, and renders them in a particular style is an application implementation decision. Regardless of that implementation strategy, XSL stylesheets for XLL constructs, will have to specify how to choose display options for such links. Those construct _will_ have to deal with the fact that XLL links _need not_ be to "well-formed subtrees" of the linked-to document. This is of critical inportance for implementing external markup and arbitrary quotation. So, any implementations strategy that depends on WFST (Well Formed SubTrees) will fail for some legal imnput documents. That's fine, depending on the goals and limitations of the application. It is concievable that XSL will not give any method for formatting non-WFST EMBED links. That would also be OK, as people who require the more complex linking can still create their own (more complex) applications. However, purely in the form that you've asked the question (i.e. XML parsing rules), there is no inherent relation between EMBED linking and document validation -- and this is not an oversight, but a planned strategyu to enhance the reusability of hyperdocuments in the same way that XML enhances the reusability of single documents -- by late-binding all formatting and display issues via a stylesheet or toerh form of processing specification. The confusion over "application flexibility" is occuring because people are used to early-binding models like HTML, where the format of documents is explicitly encoded in the document. To judge application compatibility you require not only the knowledge of the XML input, but the stylesheet language (processing model) being apllied to the document. I've seen nothing so far in the XDEV proposals that is not more properly an issue for XSL. One way to see that this flexibility is required to is to imagine in what sense there can be interoperability between a web-mapping, or web-indexing application and a browser display application. They might have very different strategies for when to do many things (such as expand entities) and attach very different semantics to those operations (a map might represent entities as a special type of link, a browser would silently expand them, or perhaps use a stretchtext view where the entities were buttons that would trigger textual expansion when clicked). Formatters would selsect such options based on their stylesheets. Analysis application might more often do the same thing via hard-wired code or configuration files. > And, of course, I can think of a considerable number of applications where it > might be useful to be apply to apply the DOM to EMBEDded content without > having to cope with a separate document tree. That is fine, but that is a decision on processing model that, if taken, will not handle certain legal XLL-linked documents... You can pick your processing model, but then you have to live with the consequences. > Sounds like fun. For the applications I'm proposing, I'd like them in the > document tree, but of course that isn't appropriate for many situations. I'd > really rather not see this prohibited, either - it would chop off an entire > branch of XML development I'm working on. Could be the price of progress. > We'll see. I think the price will be some options in XSL (entity expansion rules) that may seem mysterious at first and second glance, but will enable much more sophisticated (and controllable) hypertext interaction. > I guess what I'd love to see is another XML-Link attribute specifying whether > to include an EMBED in the document tree or not - it seems to be the central > issue around which this discussion has focused. Failing that, I'll look into > Peter's proposals for XDEV, since they seem to address the challenges of > multiple application behaviors directly - if they get implemented by > application developers, of course. This is: 1. not XLL's job, as explained above. Whether a processing models includes the tree is relevant only to that processing model, not the document itself. 2. That attribute would only be legal for the subset of XLL links that select WFSTs of the destination document -- this is an unreasonable limitation that removes some useful applications of such links. For an interesting example of the scholarly use of such markup, the MULTEXT project may be of interest ( http://www.cogsci.ed.ac.uk/~ht/nsldoc/nsldoc.html ). 3. If 2 is deemed a minority view, XSL will support _only_ what you ware requresting, but other processing languages will be able to process such linking structures. ------------------------------------------+---------------------------- David Durand dgd@c...| david@d... Boston University Computer Science | Dynamic Diagrams http://www.cs.bu.edu/students/grads/dgd/ | http://dynamicDiagrams.com 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
|