Re: [whatwg] Geographic hyperlinks
Dated June 2010... It appears someone raced me! I look forward to seeing this implemented. Only... One weakness in the existing document that might be addressed as an upgrade to this specification at a later date: there appears to be scant reference to methods of specifying date and time as part of GEO hyperlinks. For some GIS applications, this might be important. (I grant that this could be a nightmare to implement on geological time-scales where it's hard to decide upon a fixed longitudinal reference point, but on shorter time-scales of hundreds or even thousands of years, this feature might be a boon to the publication of historical maps and data.) What say you? How might I suggest this to the relevant people, if not here? -- Matthew Slyman, M.A. Computer Science (Camb) Quoting Tantek Çelik tan...@cs.stanford.edu: See RFC 5870[1] for a proposed standard geo URI scheme for geo: hyperlinks. - Tantek [1] http://tools.ietf.org/html/rfc5870 On Mon, Oct 10, 2011 at 10:27, Matthew Slyman wha...@aaabit.com wrote: http://forums.whatwg.org/bb3/viewtopic.php?f=3t=4725 [Topic has been on forum for 2 weeks without reply. Now posting to mailing list.] -- Hyperlinks for geographic coordinates are a mess. Designers of web applications are being forced to design their own solutions to make geographic links more user-friendly... http://en.wikipedia.org/wiki/Wikipedia:WikiProject_Geographical_coordinates http://toolserver.org/~geohack/geohack.php?pagename=Londonparams=51_30_26_N_0_7_39_W_type:city(7825200)_region:GB There's a relatively simple solution to all of this that could easily be upgraded over time. We already have mailto:; hyperlinks, for example, that accept certain fields and map those to certain parameters within a user-definable (or system-specific) mail client application. The same could be done for geographic data. The user might install certain geographic information systems on their viewing device, specify their favourite for geo: links, and then when they follow a hyperlink with geographic content, any relevant information fields present might be transferred over to the geographic information system (GIS) as coordinates. I suggest for the HTML standards people to simply talk to Wikipedia or Google and copy their system, as a starting-point for discussion at least. Maybe their format could be tidied up slightly, but generally I think they've done a good job and that their work should be adopted as a standard, so that you don't end up seeing pages with dozens of hyperlinks (one for each GIS) as we do on Wikipedia. -- Matthew Slyman, M.A. Computer Science (Camb) -- http://tantek.com/ - I made an HTML5 tutorial! http://tantek.com/html5
[whatwg] Geographic hyperlinks
http://forums.whatwg.org/bb3/viewtopic.php?f=3t=4725 [Topic has been on forum for 2 weeks without reply. Now posting to mailing list.] -- Hyperlinks for geographic coordinates are a mess. Designers of web applications are being forced to design their own solutions to make geographic links more user-friendly... http://en.wikipedia.org/wiki/Wikipedia:WikiProject_Geographical_coordinates http://toolserver.org/~geohack/geohack.php?pagename=Londonparams=51_30_26_N_0_7_39_W_type:city(7825200)_region:GB There's a relatively simple solution to all of this that could easily be upgraded over time. We already have mailto:; hyperlinks, for example, that accept certain fields and map those to certain parameters within a user-definable (or system-specific) mail client application. The same could be done for geographic data. The user might install certain geographic information systems on their viewing device, specify their favourite for geo: links, and then when they follow a hyperlink with geographic content, any relevant information fields present might be transferred over to the geographic information system (GIS) as coordinates. I suggest for the HTML standards people to simply talk to Wikipedia or Google and copy their system, as a starting-point for discussion at least. Maybe their format could be tidied up slightly, but generally I think they've done a good job and that their work should be adopted as a standard, so that you don't end up seeing pages with dozens of hyperlinks (one for each GIS) as we do on Wikipedia. -- Matthew Slyman, M.A. Computer Science (Camb)
Re: [whatwg] Web Forms 2 Repetition Model?please reinstate on specification
Matthew Slyman, M.A. Computer Science (Camb) -- Quoting Ian Hickson i...@hixie.ch: We took it out because it was just far too complicated a solution to solve far too narrow a set of use cases. However, there is a lot of ongoing work in this area of research, especially currently in the public-weba...@w3.org group. I encourage you to bring up the suggestion there. Unfortunately, coming up with a declarative solution whose cost-to-usefulness ratio is good enough has proven over the years to be a rather elusive goal. I find this surprising. Unless of course you're trying to create a tool to do everything (in which case you're diving head-first down a rabbit-warren), or otherwise, have already tried that and decided it doesn't work, and therefore decided that it's not worth attempting a solution to any part of this problem. Let's address another potential misconception at the same time. I recently dug up an old archive message from 2004/2005 in which some fellow was talking the repetition model down on the basis that repetition would be programming and declarative models aren't meant to do programming or something to that effect. Repetition isn't truly programming if it isn't Turing-complete. But I get the point, and I would NEVER ask for a declarative solution that would be Turing-complete. Let's look at a case study or two: ===Chemical formulae===: These have had a repetition model for a long time now, which is very simple but very powerful. Like so: Ca(OH)2 [subscript 2 - put superscript figures in for charge if you want.] Nobody has a problem with this. It does the job and it's very powerful. Just powerful enough, yet not so powerful that you end up with 20 different ways to write the same chemical formula (the system is sufficiently restrictive to enforce a common system of notation). It strikes the balance perfectly, and forms a perfect demonstration of the relative advancement of chemistry as compared with many other sciences. The combination of power and simplicity in this system of chemical notation (which closely resembles the basic HTML5 Repetition Model) enables the world of chemistry to get on with their real work without worrying too much about the art of notation, and enable chemists to find prior art easily. ===Linear equations===: A similar case could be made for these. They're a separate class of problems from the much larger set of problems that can be tackled with mathematics in general. You shouldn't put the folks that need real power and freedom in a strait-jacket by forcing them to work with a system designed for linear equations only. Likewise, you shouldn't burden and befuddle the novices and the folks that just need to get a quick linear equation job done, by forcing them to work with a generalised mathematical tool that they're just not trained to handle, and will never be confident using. ===Classes of problems===: For many problems, there is such a thing as too much power. Let's please recognise that we're dealing with two distinct classes of problems here. There is a class of problems that requires a similar approach/solution to what we see in chemical notation (where one only requires a contiguous repetition of a block of HTML, which may or may not include repeatable subgroups), and another separate and much larger class of problems that requires the greater power available in a programming language. The correct solution for the former is a declarative solution like the basic HTML5 Repetition Model. The correct solution for the latter is Javascript or something similar. ===CONCLUSIONS===: We need a declarative solution for HTML repetition, the same way Chemists need a declarative solution for repetition of chemical formulae. Please reinstate the basic HTML5 Repetition Model. The system design as it stood just a few months ago was excellent in my opinion, and not at all in need of major revision if any. -- Matthew Slyman, M.A. Computer Science (Camb)
