tag:blogger.com,1999:blog-3191291.post1784033964442036182..comments2024-02-05T22:23:32.443-08:00Comments on Coding In Paradise: Straw Man Proposal for Purple Include Spec (Version 0.1)Brad Neuberghttp://www.blogger.com/profile/03274020042497854648noreply@blogger.comBlogger5125tag:blogger.com,1999:blog-3191291.post-43562822565024241602008-01-05T21:23:00.000-08:002008-01-05T21:23:00.000-08:00@kevin: Hey Kevin, good to hear from you. You don'...@kevin: Hey Kevin, good to hear from you. <BR/><BR/>You don't have to use DOM for a robot; I just suggested that because it makes implementation much easier. If you use SAX I'm very interested to hear how you would approach the problem. Is there SAX Range support?<BR/><BR/>Also, for the 'cite' attribute, the value might not be URL encoded since users will be creating their HTML by hand and might not know they need to URL encode things (plus its much easier to read this stuff in the source when its not URL encoded). So expect that this attribute might or might not be URL encoded, and that there might be real spaces (I believe that URLs in HTML all share this issue, such as the A or LINK tags).<BR/><BR/>Best,<BR/> BradBrad Neuberghttps://www.blogger.com/profile/03274020042497854648noreply@blogger.comtag:blogger.com,1999:blog-3191291.post-39551522517544214132008-01-05T18:03:00.000-08:002008-01-05T18:03:00.000-08:00A couple of nodes. A robot might not actually have...A couple of nodes. <BR/><BR/>A robot might not actually have a DOM parser. <BR/><BR/>This is one of the reasons I don't like microformats for robots because they could become too fragile. :-/<BR/><BR/>Also, does quote() need to be URL encoded?<BR/><BR/>Good stuff!<BR/><BR/>KevinAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-3191291.post-35029779997465737642008-01-02T08:59:00.000-08:002008-01-02T08:59:00.000-08:00One of the inspirations for me for using A is micr...One of the inspirations for me for using A is microformats, which as a general principle use HTML as-is without adding new tags or attributes, and using links for links. (In fact, with that in mind, why META and not [link rel="purple.include.server" href="..."]? -- OpenID also uses LINK I think)Ian Bickinghttps://www.blogger.com/profile/10921115783730718101noreply@blogger.comtag:blogger.com,1999:blog-3191291.post-4805516688390593332007-12-31T15:26:00.000-08:002007-12-31T15:26:00.000-08:00@ian: Hi Ian, good to see your comments. I'll give...@ian: Hi Ian, good to see your comments. I'll give a longer reply soon, but I just wanted to touch on the approach I'm trying to take. <BR/><BR/>In general, the history of hypertext technologies, and the ones on the web, have not been very succesful. The tech field is literally sprinkled with hypertext technologies that have not been adopted, including Ted Nelson's work, much of Engelbart's, XLink, XPointer, and more. In general, I am trying to take a much more pragmatic, piece-meal evolution on this stuff, very similar to the way that blog technologies evolved. Using the quote() scheme rather than the unwieldy XPointer scheme; not trying to get everything perfect when it comes to validity of bringing in remote documents; not trying to be so general that the use-cases for this stuff become hard to figure out; and not getting lost by perfectly aligning with the rest of the standards world around XHTML and registering 'rel' tags. The approach I've been trying to take is similar to Alex Russell's which he blogs about here (http://alex.dojotoolkit.org/?p=642) as well as Ian Hixie's with the HTML 5 work (http://www.whatwg.org/specs/web-apps/current-work/).<BR/><BR/>With that said, you provide many good ideas that I'll respond to in length in a bit. I have to run out the door and go grab some lunch right now :) Thanks for your feedback and the cool stuff you have also been doing around transclusions. I look forward to collaborating. <BR/><BR/>Best,<BR/> BradBrad Neuberghttps://www.blogger.com/profile/03274020042497854648noreply@blogger.comtag:blogger.com,1999:blog-3191291.post-11322409303119570832007-12-31T14:49:00.000-08:002007-12-31T14:49:00.000-08:00Some comments:Q and BLOCKQUOTE fit the quotation u...Some comments:<BR/><BR/>Q and BLOCKQUOTE fit the quotation use case, but don't fit other use cases well. For instance, a common kind of transclusion currently done is to include statistics in a sidebar. It could potentially be used for server-side page composition. Using these semantically weighty elements seems restrictive.<BR/><BR/>Potentially the notion of letting any element have a src attribute, as in XHTML, would be equivalent to what you are thinking? I always see that referred to in terms of images, but there's no reason why you couldn't include HTML. That this overlaps with the XHTML specification is a bit annoying, and might make it hard to reconcile.<BR/><BR/>For XHTML, are the cite/embed attributes allowed? If not, a namespace will have to be used.<BR/><BR/>This doesn't talk about relative links. Ideally those links should be resolved. Doing this in Javascript sucks, probably another server-side task.<BR/><BR/>Generally #fragment URLs that refer to an id refer to a specific element suitable to be included. But when the fragment refers to a named anchor your technique is likely necessary. Though the difference between [a name=foo][h1]...[/h1][/a] and [h1][a name=foo]...[/a][/h1] will be hard to explain. That said, it think it's a useful feature, and fits non-quotation use cases better than #quote(). #xpath() serves a similar use case when there are formal relationships between pages (typical users may only be able to get these URLs by copying them, but that's a reasonable and already common use case for permalinks).<BR/><BR/>I like using the A tag for this, as it (mostly) fits with HTML's model already, and degrades quite gracefully. But it's not a perfect degradation; it would be better if you could include a quote, include a citation, and then have the citation load the live quote from the destination. But that feels really hard to compose as an author. Ugh. Redundancy makes the quote more reliable; I'm not sure how well this can work when you don't have services that are specifically intended to be used this way. What about when the other server goes down? Are you letting people change history too much? For quotations I'm unlikely to want a live quote.<BR/><BR/>Anyway, that was an aside. Using an A fits well with WYSIWYG editors; there just has to be an addition to mark the A as something suitable to be included. In my own code I've used rel="include". In theory that's wrong, as it's not a registered relation.<BR/><BR/>For #quote(), I believe there's already work on extending fragments in several ways. This seems compatible with that, but some attention to that would be useful, and seeing if there is useful overlap with existing work.<BR/><BR/>For #quote() there's more than just well-formedness, but also validity. I don't know if that should be addressed at all. But the case is if, say, you get a TD element, and transclude it somewhere that's invalid. Usually browsers handle this somewhat gracefully at least.<BR/><BR/>XSS concerns are greater than what you list. I'm not sure there's any single canonical list of things you have to do to ensure safety. There's weird ironies here too, e.g., EMBED is possible to handle but technically deprecated. OBJECT is infeasible to clean well or allow any opt-ins (like embedded youtube videos), but in theory is supposed to replace EMBED. Now everyone uses EMBED because of cleaners.<BR/><BR/>Failure cases for fragments would probably be good. Should you just give an error, or try to return an only partially valid response? <BR/><BR/>Should the subrequests use the same cookies, etc., as the original request? When they are on the same domain? Probably not; subrequests should probably be generic and not tied to the user. But I'm not sure; there are some useful cases to making subrequests with cookies and whatnot (when it's possible).<BR/><BR/>You might want to refer to the recent proposed extensions to Cache-Control (http://www.mnot.net/blog/2007/12/12/stale) as they are useful for this case.<BR/><BR/>I'm -1 on converting to XHTML. It doesn't feel useful, and could be anti-useful.<BR/><BR/>One thing we've done is try to merge the HEAD tags when transcluding. I'm not sure this is a good idea. But it's hard, because some content is really dependent on external stylesheets or scripts. Of course, scripts have XSS concerns, and that only makes any sense with trusted links. Stylesheets unfortunately frequently have conflicts. Maybe inline STYLE tags are the only reasonable way to address this. It would also be possible to make all the styles inline as part of the server transformation. This may or may not be desired by the person doing the transclusion; certainly both cases are reasonable. Possibly even class names could be munged to avoid unintentional overlap; though again this may or may not be desirable; there's no general rule. CSS classes kind of suck.<BR/><BR/>Anyway, that's my thoughts so far.Ian Bickinghttps://www.blogger.com/profile/10921115783730718101noreply@blogger.com