[whatwg] External document subset support
Section 10.1, "Writing XHTML documents" observes: "According to the XML specification, XML processors are not guaranteed to process the external DTD subset referenced in the DOCTYPE." While this is true, since no doubt the majority of web browsers are already able to process external stylesheets or scripts, might the very useful feature of external entity files, be employed by XHTML 5 as a stricter subset of XML (similar to how XML Namespaces re-annexed the colon character) in order to allow this useful feature to work for XHTML (to have access to HTML entities or other useful entities for one, as well as enable a poor man's localization, etc.)? If you wish to give power to the average user (as well as perhaps, as a side effect, encourage implementation of parsing mechanisms for pure XML over the web which enable the many "non-web" textual documents out there which already use external DTDs to be shared and styled over the web), I believe requiring support for (non-validating) external DTD subsets would provide a very useful feature to many web users, regardless of the laxity of the original XML specification on this matter. While some might argue that causing a fatal error in XML parsers will be unacceptable, use of a colon in an XML name, while technically allowable by XML, will also produce such a fatal error in latter (namespace-aware) parsers. While some XML parsers might not yet support external DTD parsing, I would hope that the bar could be raised higher with a new version of XHTML, especially if new features are being introduced anyways, and especially given all of the benefits this could bring to both XHTML as well indirectly to XML users. True XHTML is still more of an experimental field anyways, so I don't think the world will collapse if an old XML parser breaks on visiting such a page (HTML will still be fine), while failing to allow it now may delay or prevent future XML parsers from ever supporting this very reasonable functionality. thank you, Brett Zamir
Re: [whatwg] Link rot is not dangerous
Geoffrey Sneddon On 09-05-16 21.38: On 16 May 2009, at 07:08, Leif Halvard Silli wrote: Geoffrey Sneddon Fri May 15 14:27:03 PDT 2009 On 15 May 2009, at 18:25, Shelley Powers wrote: > One of the very first uses of RDF, in RSS 1.0, for feeds, is still > in existence, still viable. You don't have to take my word, check it > out yourselves: > > http://purl.org/rss/1.0/ Who actually treats RSS 1.0 as RDF? Every major feed reader just uses a generic XML parser for it (quite frequently a non-namespace aware one) and just totally ignores any RDF-ness of it. What does it mean to "treat as RDF"? [ ... snip ... ] I mean using an RDF processor, and treating it as an RDF graph. Everything just creates from an XML stream (or object model) a bunch of items with a certain title, date, and description, and acts on that (and parses it out in a format specific manner, so it creates the same sort of item for, e.g., Atom) — it doesn't actually use an RDF graph for it. If you can find any widely used software that actually treats it as an RDF graph I'd be interested to know. "OpenLink Data Explorer" [1] treats the W3 stream[2] as RDF. [1] https://addons.mozilla.org/en-US/firefox/search?q=openlink [2] http://www.w3.org/2000/08/w3c-synd/home.rss -- leif halvard silli
Re: [whatwg] Annotating structured data that HTML has no semantics
On Sat, May 16, 2009 at 10:02 AM, Leif Halvard Silli wrote: > [...] > But may be, after all, it ain't so bad. It is good to have the opportunity. > :-) This is the exactly the point (at least, IMO): RDFa may be quite good at embedding inline metadata, but can't deal at all with describing the semantics that are inherent to the structure. OTOH, EASE does quite the latter, but can't handle the former at all. That's why I was advocating for a solution that allows either approach, and even mixing both when appropriate. On a side note, about the idea of mixing CSS+EASE or CSS+CRDF or CSS+whatever: my PoV is that these *should* not be mixed; but any CSS-like semantic description would benefit from some foolproofing, ensuring that if an author puts CRDF this would get ignored by CSS parsers (and viceversa). In addition, CSS's error-handling rules make this kind of shielding relatively easy. OTOH, adding the semantic code as part of the CSS styling, or trying to consider this as part (or even as an extension) of the CSS language is wrong by definition: semantics is not styling; and we should try to make authors aware enough of the difference. Regards, Eduard Pascual
Re: [whatwg] A Selector-based metadata proposal (was: Annotating structured data that HTML has no semantics for)
First of all, thanks for the time taken to review the document and to post your feedback. I truly appreciate it. On Sat, May 16, 2009 at 2:12 PM, Toby A Inkster wrote: > In part 0.1 you include some HTML and some RDF triples that you'd like to > mark up in the HTML and conclude that RDFa is incapable of doing that > without adding extra wrapper elements. > > While adding redundant wrapper elements and empty elements is occasionally > needed in RDFa (and from what I can tell, the microdata approach is even > worse at this), the example you give doesn't require any. I think I already stated this somewhere, but it never hurts to state it again: as any human, I can make mistakes; and my knowledge about RDF, RDFa, and even CSS, is definitely far from perfect. So, thanks for your post that has actually improved it a little, with the "revelation" that @property can take multiple values. My apologies for that wrong example, then, I'll try to fix that part ASAP. Trying to think about which cases would then require wrappers in RDFa, the only situation I've come up with is when the value should be reused for properties about different subjects. And, to my surprise, just realized that CRDF in embedded form didn't handle those case neither! So, my most sincere thanks for highlighting this, since you have revealed a serious issue on CRDF that will get fixed on the next iteration of the document (hopefully due for late tuesday or early wednesday). > Part 0.3 of your document claims that RDFa is designed for XHTML > "exclusively". This is not the case - the designers of RDFa went out of > their way to make its use feasible in *any* XML or XML-like language. SVG > Tiny 1.2 includes the RDFa attributes, so RDFa can be used in SVG. My apologies here for such a bad wording, although your reply confirms the idea behind the wording: RDFa was part of the "the future is XML" dream, thus not taking into propper account non-X HTML. Not to say that it was the RDFa's fault, since that was a quite widespread belief (I shared it myself for a long while). But RDFa's XMLish approach is the root of many issues for tag-soup HTML; perfectly illustrated by the ammount of controversy generated on these lists by the "xmlns:prefix" syntax. I'll make sure to change that wording to better describe the idea behind it; and I'd like to thank you for highlighting the issue. > Part 0.3 also states that "both Microformats and RDFa require the > human-readable values to be reused as the machine- > readable ones.". Actually, RDFa provides @content and @resource which, > respectively, over-ride human-readable text and human-intended link targets. Again, my limited knowledge of RDFa has betrayed me. This, added to Microformats missuse of abbr as a workaround, means that the issue itself doesn't exist, at least not as initially percevied. I'm not sure whether I'll remove that one entirely, or just briefly mention on the "Issues with Microformats" section, due to the accessibility issues with the abbr approach. > Lastly, and most seriously, CRDF doesn't seem to distinguish between > literals and resources. This is definitely an important issue, which Tab already made me aware of. Fortunately, it's easy to fix; and Tab himself provided a possible solution, which is very likely to be part of the next version of the document. Until I add the fixes to the document, it's only left to reiterate my thanks for your feedback. Regards, Eduard Pascual
