Re: [whatwg] Annotating structured data that HTML has no semanticsfor
On Tue, 9 Jun 2009, Kristof Zelechovski wrote: * Let a COLOR element have a value DOM property in the DOM that returns a color. .value already does so. * Let a NUMBER element has a value DOM property that returns a number. .valueAsNumber already does so. Actually, the latter use case is one I have bumped into: * The DOM does not provide a numeric value, As noted, it now does. * JavaScript support for parsing localized properties is poor; you have to reverse engineer the result of toLocaleString, The localised properties aren't exposed. * VBScript support is better but inconsistent as it depends on the system locale and not on the document locale as desired. Then don't use VBScript; it's a vendor-specific technology anyway. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Annotating structured data that HTML has no semanticsfor
* Let a COLOR element have a value DOM property in the DOM that returns a color. * Let a NUMBER element has a value DOM property that returns a number. Actually, the latter use case is one I have bumped into: * The DOM does not provide a numeric value, * JavaScript support for parsing localized properties is poor; you have to reverse engineer the result of toLocaleString, * VBScript support is better but inconsistent as it depends on the system locale and not on the document locale as desired. IMHO, Chris
Re: [whatwg] Annotating structured data that HTML has no semanticsfor
Being unable to deal with all use cases sometimes is a feature. For example, regular expressions are unable to recognize all recursive languages; it is a feature. As a compensation for that loss, they do not suffer from the halting problem. HTH, Chris
Re: [whatwg] Annotating structured data that HTML has no semanticsfor
I do not think anybody in WHATWG hates the CURIE tool; however, the following problems have been put forward: Copy-Paste The CURIE mechanism is considered inconvenient because is not copy-paste-resilient, and the associated risk is that semantic elements would randomly change their meaning. Link rot CURIE definitions can only be looked up while the CURIE server is providing them; the chance of the URL becoming broken is high for home-brewed vocabularies. While the vocabularies can be moved elsewhere, it will not always be possible to create a redirect. Chris
Re: [whatwg] Annotating structured data that HTML has no semanticsfor
On 15/5/09 14:11, Shelley Powers wrote: Kristof Zelechovski wrote: I do not think anybody in WHATWG hates the CURIE tool; however, the following problems have been put forward: Copy-Paste The CURIE mechanism is considered inconvenient because is not copy-paste-resilient, and the associated risk is that semantic elements would randomly change their meaning. Well, no, the elements won't randomly change their meaning. The only risk is copying and pasting them into a document that doesn't provide namespace definitions for the prefixes. Are you thinking that someone will be using different namespaces but the same prefix? Come on -- do you really think that will happen? The most likely case is with Dublin Core, but DC data varies enough already that this isn't too destructive... Dan
Re: [whatwg] Annotating structured data that HTML has no semanticsfor
On Fri, May 15, 2009 at 1:44 PM, Kristof Zelechovski giecr...@stegny.2a.pl wrote: I do not think anybody in WHATWG hates the CURIE tool; however, the following problems have been put forward: Copy-Paste The CURIE mechanism is considered inconvenient because is not copy-paste-resilient, and the associated risk is that semantic elements would randomly change their meaning. Copy-paste issues with RDFa and similar syntaxes can take two forms: The first is horfaned prefixes: when metadata with a given prefix is copied, but then it's pasted in a context where the prefix is not defined. If the user that is copy-pasting this stuff really cares about metadata, s/he would review the code and make the relevant fixes and/or copy the prefix declarations; the same way when an author is copy-pasting content and wants to preserve formatting s/he would copy the CSS stuff. If the user doesn't actually care about the metadata, then there is no harm, because properties relying on an unmapped prefix should yield no RDF output at all. The second form is prefix clashes: this is actually extremely rare. For example, someone copies code with FOAF metadata, and then pastes it on another page: which are the chances that user will be using a foaf: prefix for something else than FOAF? Sure, there are cases where a clash might happen but, again, these are only likely to appear on pages by authors who have some idea about metadata, and hence the author is more than likely to review the code being pasted to prevent these and other clashes (such as classes that would mean something completelly different under the new page's CSS code, element id clashes, etc). A last possibility is that the author doesn't have any idea about metadata at all, but is using a CMS that relies on metadata. In such case, it would be wise on the CMS's part to pre-process code fragments and either map the prefix to what they mean (if it's obvious) or remove the invalid data (if the CMS can't figure out what it should mean). Link rot CURIE definitions can only be looked up while the CURIE server is providing them; the chance of the URL becoming broken is high for home-brewed vocabularies. While the vocabularies can be moved elsewhere, it will not always be possible to create a redirect. Oh, and do reversed domains help at all with this? Ok, with CURIEs there is a (relatively small) chance for the CURIE to not be resolvable at a given time; reversed domains have a 100% chance to not be resolvable at any time: there is always, at least, ambiguity: does org.example.foo map to foo.example.org, example.org/foo, or example.org#foo? Even better: what if, under example.org we find a vocabulary at example.org/foo and another at foo.example.org? (Ok, that'd be quite unwise, although it might be a legitimate way to keep deployed and test versions of a vocabulary online at a time; but anyway CURIEs can cope with it, while reversed domains can't). Wherever there are links, there is a chance for broken links: that's part of the nature of links, and the evolving nature of the web. But, just because the chance of links being broken, would you deny the utility of elements such as a and link? Reversed domains don't face broken links because they are simply uncapable to link to anything. Now, please, I'd appreciate if you reviewed your arguments before posting them: while the copy-paste issue is a legitimate argument, and now we can consider whether this copy-paste-resilience is worth the costs of microdata, that link rot argument is just a waste of everyone's time, including yours. Anyway, thanks for that first argument: that's exactly what I was asking for in the hope of letting this discussion advance somewhere. So, before we start comparing benefits against costs, can someone post anymore benefits or does the copy-paste-resilience point stand alone against all the costs and possible issues? Regards, Eduard Pascual
Re: [whatwg] Annotating structured data that HTML has no semanticsfor
On Fri, May 15, 2009 at 9:17 AM, Eduard Pascual herenva...@gmail.com wrote: On Fri, May 15, 2009 at 1:44 PM, Kristof Zelechovski Link rot CURIE definitions can only be looked up while the CURIE server is providing them; the chance of the URL becoming broken is high for home-brewed vocabularies. While the vocabularies can be moved elsewhere, it will not always be possible to create a redirect. Oh, and do reversed domains help at all with this? Ok, with CURIEs there is a (relatively small) chance for the CURIE to not be resolvable at a given time; reversed domains have a 100% chance to not be resolvable at any time: there is always, at least, ambiguity: does org.example.foo map to foo.example.org, example.org/foo, or example.org#foo? Even better: what if, under example.org we find a vocabulary at example.org/foo and another at foo.example.org? (Ok, that'd be quite unwise, although it might be a legitimate way to keep deployed and test versions of a vocabulary online at a time; but anyway CURIEs can cope with it, while reversed domains can't). Wherever there are links, there is a chance for broken links: that's part of the nature of links, and the evolving nature of the web. But, just because the chance of links being broken, would you deny the utility of elements such as a and link? Reversed domains don't face broken links because they are simply uncapable to link to anything. Reversed domains aren't *meant* to link to anything. They shouldn't be parsed at all. They're a uniquifier so that multiple vocabularies can use the same terms without clashing or ambiguity. The Microdata proposal also allows normal urls, but they are similarly nothing more than a uniquifier. CURIEs, at least theoretically, *rely* on the prefix lookup. After all, how else can you tell that a given relation is really the same as, say, foaf:name? If the domain isn't available, the data will be parsed incorrectly. That's why link rot is an issue. ~TJ
