| 01:07 | <takkaria> | things I don't get: people saying that html5:property conflicts with rdfa:property |
| 01:07 | <takkaria> | it explicitly doesn't afaics |
| 01:08 | <Hixie> | takkaria: if anyone can think of a better attribute name, i'm happy to change it, just to avoid the argument |
| 01:08 | <Hixie> | takkaria: but i agree that it's a bit weird for the rdfa guys to be complaining that html5 conflicts with their future plans |
| 01:08 | <Hixie> | it's just like when i complained that rdfa conflicted with our future plans :-) |
| 01:11 | <takkaria> | I mean, I get that RDFa people want to use RDFa |
| 01:12 | <takkaria> | but you can tell RDFa:property and html5:property apart using strchr(content, ":") |
| 01:12 | takkaria | shrugs and goes off to do other things |
| 01:14 | <Hixie> | takkaria: RDFa property is not in their own namespace |
| 01:14 | <Hixie> | oh, i misunderstood |
| 01:15 | <Hixie> | takkaria: they're saying they want to add new features that remove that distinction |
| 06:54 | <MikeSmith> | what does the spec say about a case where a form has two controls with the same name? |
| 06:55 | <MikeSmith> | as far as I can see, it does not disallow a form to have multiple name instances |
| 06:56 | <MikeSmith> | parts of a form to have the same name |
| 06:59 | <MikeSmith> | ah, ignore me |
| 07:00 | <MikeSmith> | I realize there are of course cases where certain controls need to have the same name |
| 07:18 | <erlehmann> | MikeSmith, i think name is obsolete? |
| 07:45 | <MikeSmith> | erlehmann: I was meaning to refer to the name attribute on various form controls |
| 08:17 | <Philip`> | Hixie: You're not allowed to rename property now, there's already two legacy implementations! |
| 08:18 | <Hixie> | hah |
| 08:19 | Philip` | can't think of any names other than "key" |
| 08:20 | <zcorpan_> | Hixie: the microdata solution and the <dl> example gives more reason to introduce <di> (you duplicate the <dt> content in <dd><meta>) |
| 08:21 | <Hixie> | zcorpan_: yeah, i did notice that this made <di> have a reason for being |
| 08:21 | <Hixie> | was hoping no-one else would notice too :-P |
| 08:21 | zcorpan_ | replies :) |
| 08:37 | <zcorpan_> | Hixie: will <link rel="alternate stylesheet" ...> and <link rel="alternate-stylesheet"> produce the same RDF output? |
| 08:38 | <zcorpan_> | s/">/" ...>/ |
| 08:39 | <zcorpan_> | <p property="com.damowmow.desc">Siamese color-point. |
| 08:39 | <zcorpan_> | <img property="com.damowmow.img" alt="" src="/images/erwin.jpeg"> |
| 08:39 | <zcorpan_> | Hixie: was the img intended to be a child of the p? |
| 08:49 | <zcorpan_> | Philip`: item=" " generates two types in your impl (both empty string) |
| 08:57 | <Philip`> | zcorpan_: Possibly fixed now |
| 08:59 | <Hixie> | zcorpan_: yes, they'll produce the same output. |
| 08:59 | <jgraham> | Ah so, unsurprisingly, "I cannot live with" has become a magic phrase |
| 08:59 | <Hixie> | zcorpan_: not sure what to do about it. (so will <link rel="http://..../#alternate-stylesheet">) |
| 09:00 | <zcorpan_> | Hixie: (true) |
| 09:01 | <zcorpan_> | maybe it's not a problem |
| 09:01 | <Hixie> | i think it is |
| 09:01 | <zcorpan_> | Philip`: yep, cool |
| 09:01 | <Hixie> | but i don't know what to do about it |
| 09:01 | <Hixie> | short of making those explicitly non-conforming, but even then |
| 09:02 | <zcorpan_> | can you produce a URL that cannot be produced otherwise? |
| 09:02 | <Hixie> | not as far as i can tell |
| 09:02 | <zcorpan_> | #alternate stylesheet |
| 09:02 | <zcorpan_> | with a space :) |
| 09:04 | <Philip`> | #ALTERNATE-STYLESHEET |
| 09:04 | <Hixie> | zcorpan_: heh |
| 09:04 | <Hixie> | Philip`: you can still do that as a url, right? |
| 09:05 | <Philip`> | Hixie: No, because they're lowercased first |
| 09:05 | <Philip`> | (I think) |
| 09:06 | <Hixie> | Philip`: urls are? that's a problem if so |
| 09:06 | <Hixie> | i don't intend urls to be lowercased |
| 09:07 | <Philip`> | "split the value of the element's rel attribute on spaces, obtaining list of tokens. Convert each token in list of tokens to lowercase." |
| 09:07 | <jgraham> | Hixie: BTW, as a general comment it is rather confusing when the spec uses "lowercase" to mean "ascii only lowercase" |
| 09:07 | <jgraham> | (I know it is defined and there is alink and everything, but it is still confusing) |
| 09:08 | <Hixie> | jgraham: file a bug, i can change that terminology easily enough |
| 09:08 | Philip` | wonders if he's badly confused about things |
| 09:08 | <Philip`> | Hixie: As far as I can see, rel="http://..." will never produce any triples at all |
| 09:09 | <Philip`> | (because there's only "For each token token in list of tokens that contains neither a U+003A COLON character (:) nor a U+002E FULL STOP character (.), generate the following triple:") |
| 09:09 | zcorpan_ | just noticed that Philip`'s impl didn't generate a triple for urls |
| 09:10 | Philip` | notes that his implementation does not attempt to be perfectly correct |
| 09:10 | <Philip`> | (but if there are things that are easy to fix then I can fix them) |
| 09:11 | <Hixie> | Philip`: oh right, for rel="" it's only values, i forgot |
| 09:11 | <Hixie> | Philip`: ok, will use uppercase |
| 09:19 | zcorpan_ | updates html5-elements |
| 09:19 | <Hixie> | Philip`: done |
| 09:25 | zcorpan_ | notes that the order is different in the Amanda examples, in Philip`'s impl |
| 09:28 | <jgraham> | zcorpan_: Order of hat? |
| 09:29 | <jgraham> | Argh. "what" |
| 09:29 | <zcorpan_> | jgraham: the "band" and "name" properties |
| 09:29 | <zcorpan_> | "In this example, the outer item represents a person, and the inner one represents a band:" |
| 09:29 | <zcorpan_> | and "This example is the same as the previous one, but all the properties are separated from their items:" |
| 09:30 | <zcorpan_> | Hixie: you could either move the second div to below the name paragraph or clarify that the order of the properties will be different |
| 09:30 | <Philip`> | Properties have no order |
| 09:30 | <Philip`> | (in the JSON version, at least) |
| 09:30 | <jgraham> | What Philip` said |
| 09:31 | <zcorpan_> | ok |
| 09:31 | <Philip`> | The output order is just an irrelevant artifact of the JS Object implementation and of the JSON serialiser |
| 09:31 | <jgraham> | At least I hope that is true because if if is, it's much easier to come up with nice API design |
| 09:32 | <jgraham> | And if it's not, my implementation is wrong :) |
| 09:33 | <zcorpan_> | the order of attributes in html is also supposed to be irrelevant, but browsers still have to represent them in the source order to plugins for web compat |
| 09:34 | <zcorpan_> | iirc |
| 09:34 | <jgraham> | zcorpan_: Right. But hopefully this case is different |
| 09:35 | <Philip`> | Hixie: The first example in the spec using 'getItem' looks a little broken |
| 09:35 | <Philip`> | (at least in the multipage version) |
| 09:35 | <zcorpan_> | it's only different until people start to rely on the order of a popular implementation |
| 09:35 | <Philip`> | because it does "i < something" instead of "i < something" |
| 09:36 | <Philip`> | If all implementations implement it in the way the spec describes, they'll give the same order for the same input |
| 09:36 | <Philip`> | so there's no problem |
| 09:36 | <Philip`> | (and it doesn't matter that different inputs give different orders) |
| 09:36 | <jgraham> | Actually I think I would prefer it if the DOM APIs were unordered |
| 09:36 | jgraham | hadn't really looked at those |
| 09:37 | <Philip`> | (and since the order is an implementation detail (though one that may be constrained by compatibility concerns), it can be ignored in the introduction section) |
| 09:37 | <Philip`> | jgraham: You don't want to allow enumeration of properties? |
| 09:37 | <zcorpan_> | Philip`: it's a problem for implementations that assume that the order is irrelevant and do optimzations that will change the order |
| 09:38 | <jgraham> | Philip`: Yeah, not sure what to do about enumeration |
| 09:38 | <jgraham> | But having IndexGetter seems bad |
| 09:39 | <jgraham> | Since that just encourages people to rely on order |
| 09:39 | <Philip`> | Having IndexGetter seems good, because it's a useful feature |
| 09:39 | <Philip`> | and the spec could just require implementations to sort properties alphabetically, or whatever |
| 09:39 | <jgraham> | (enumeration seems very useful and as along as it is clearly stated that the order is arbitary, maybe it's not a problem) |
| 09:40 | <jgraham> | Philip`: Why? |
| 09:40 | <jgraham> | (is IndexGetter useful?) |
| 09:40 | <Philip`> | jgraham: Um, because I failed to understand what IndexGetter is |
| 09:40 | <zcorpan_> | Philip`: sorting alphabetically would have worked but is too late for html attributes |
| 09:40 | <Philip`> | and I was just thinking of enumeration |
| 09:40 | <Hixie> | the collections are ordered in tree order |
| 09:40 | <zcorpan_> | Philip`: still not too late for microdata :) |
| 09:41 | <Hixie> | zcorpan_: not sure what you mean about the divs earlier |
| 09:41 | <jgraham> | Hixie: Enforcing ordering is bad if you want to back the implementation with a hash table |
| 09:41 | <zcorpan_> | Hixie: <div subject="amanda" property="band" item id="jazzband"></div> starts the "band" property before seeing the "name" property |
| 09:41 | <zcorpan_> | Hixie: so the order is different from the previous example |
| 09:42 | <Hixie> | jgraham: collections are already ordered in the rest of the platform, so it won't need new code as far as i can tell |
| 09:42 | <Hixie> | zcorpan_: hm, yeah, might be best to not have that change |
| 09:42 | <Hixie> | Philip`: uppercased and fixed < issue |
| 09:42 | <jgraham> | Hixie: But this is something that non-browsers are likely to implement |
| 09:43 | <jgraham> | So having a requirement to be ordered also burdens them |
| 09:43 | <Philip`> | Interoperability between non-browsers seems unimportant |
| 09:43 | <Hixie> | jgraham: the dom api? i doubt it. why would they use that api? it's got all kinds of weird JSisms |
| 09:43 | <Philip`> | since the problem is just when two browsers run one script that makes assumptions that are only valid in one |
| 09:44 | <Philip`> | whereas it seems unlikely anyone will run the same code on two non-browser implementations and expect them to be identical |
| 09:44 | <jgraham> | Hixie: I guess if it only applies to the DOM API then I can't really object. I don't want people to have the general idea that items are ordered collections of name:value pairs |
| 09:45 | <jgraham> | s/I/I just/ |
| 09:51 | <Hixie> | jgraham: maybe we should define some other api for other languages or something to prevent people from trying to implement it outside the dom |
| 09:51 | <Hixie> | jgraham: or maybe if html5lib gets an api for it and we publicise that, people will try to duplicate that one and it won't be an issue |
| 09:52 | <Hixie> | jgraham: i'm happy to put something in the spec if you think it'd help |
| 09:52 | <jgraham> | Hixie: Not worth worrying about at this point, I guess |
| 09:53 | <Hixie> | k |
| 09:53 | zcorpan_ | wonders whether the microdata solution will get bad press because of its name cf predefined class names vs microformats before |
| 09:56 | <Hixie> | I'm happy to rename it if anyone has a better idea |
| 09:56 | <Hixie> | i wasn't really intending to call it "microdata", that's just what it is |
| 09:58 | <zcorpan_> | HRDF? |
| 09:58 | <zcorpan_> | i.e. Hixie-RDF |
| 09:59 | <Hixie> | heh |
| 09:59 | <Hixie> | it's not RDF per se |
| 10:00 | <Hixie> | any more than it is JSON or whatever |
| 10:00 | <zcorpan_> | that doesn't really matter :) |
| 10:01 | <Hixie> | it matters a little! |
| 10:01 | <jgraham> | FWIWW microdata seems like a totally fine name to me |
| 10:03 | <Philip`> | I don't understand why it's micro |
| 10:03 | <Hixie> | tiny bits of data |
| 10:03 | zcorpan_ | wonders whether document.items and element.item will clash with web pages' scripts |
| 10:03 | <Hixie> | zcorpan_: :-/ hope not, hard to know ahead of time though |
| 10:03 | <Philip`> | Hixie: But it could be big bits of data, and lots of them |
| 10:04 | <Hixie> | Philip`: they can't really be that big, while still being useful. |
| 10:04 | <Hixie> | granted there could be many |
| 10:04 | <Hixie> | not sure how that stops them being small though :-) |
| 10:04 | <Philip`> | I suppose the most prominent feature is that it's data embedded into the markup, but a term like "embedded data" doesn't sound great to me |
| 10:04 | <zcorpan_> | <html item> |
| 10:05 | <Philip`> | Hixie: Any data could be viewed as a collection of lots of small bits of data, so that's hardly unique to the microdata proposal :-) |
| 10:05 | <zcorpan_> | i think it's primary feature is that it's easily extractable data while ignoring other content |
| 10:06 | <zcorpan_> | so maybe "Easily Extractable Data" (EED) |
| 10:06 | <Philip`> | zcorpan_: If that was the primary feature, you could use <script type="text/json">easily extractable data in JSON form</script> which would be much easier |
| 10:06 | <Philip`> | It's more significant that it's mixed up with the markup |
| 10:06 | <zcorpan_> | Philip`: "Embeeded Easily Extractable Data" (EEED) |
| 10:07 | <zcorpan_> | s/e/d// |
| 10:07 | <zcorpan_> | er |
| 10:07 | <zcorpan_> | s#/## |
| 10:07 | <Hixie> | zcorpan_: i don't like naming things in a way that presumes that a design criteria was successfully met ("easily") |
| 10:08 | <Philip`> | Call it Embedded Data With A Related Dom api, or Edward for short |
| 10:08 | <Hixie> | zcorpan_: because too often i have seen technologies called something like that only to have failed at that goal, and it just makes them easy targets for jokes :-) |
| 10:08 | <Hixie> | Philip`: heh |
| 10:08 | <zcorpan_> | Edward is a good name :) |
| 10:09 | <zcorpan_> | though the data-* stuff is also embedded data with a dom api |
| 10:10 | <Philip`> | Web Data |
| 10:15 | <Philip`> | Semantic Web 2.0 |
| 10:16 | <Philip`> | By the way, implementing the RDF/N3 output thing made me dislike prefixes, because I couldn't work out what prefixes to use |
| 10:16 | <Philip`> | Searching for http://purl.org/dc/terms/ suggested that people use a random mixture of dcterms:, dct: and dc: |
| 10:17 | <Philip`> | and I don't like having to make uneducated choices between such things |
| 10:17 | <zcorpan_> | Philip`: randomize which prefix to use |
| 10:17 | <Hixie> | prefixes are a disaster. When I'm forced to use them I intentionally mint new ones like "a", "b", "c", etc. |
| 10:17 | <Hixie> | to prevent people from thinking they have special meanings. |
| 10:19 | <jgraham> | I think I will implement rdf output using rdflib (assuming I can work out how to use it). Hopefully that will give me magic random prefixes |
| 10:22 | zcorpan_ | wonders whether form controls with microdata was considered |
| 10:23 | <Philip`> | I guess the conflict is between the viewpoint in which prefixes are just a syntactic shortcut (and so you can use whichever prefix you fancy, and there's no need to standardise them or have any conventions or design them carefully), and the viewpoint in which they're critical to human understanding of the data (since people think of them as being names with a colon in the middle, and try to use consistent meaningful prefixes, etc) |
| 10:23 | <Philip`> | It'd be fine if it was all one way, or all the other way |
| 10:25 | <zcorpan_> | Hixie: <input type=image src=foo property=bar> |
| 10:25 | <Philip`> | (e.g. if humans thought at that level of abstraction, or if humans never had to look at prefixes at all; or (the other way) if the prefixes really were just part of the name and were standardised etc) |
| 10:25 | <Hixie> | zcorpan_: <input> always uses the textContent |
| 10:25 | <Hixie> | zcorpan_: there were no use cases that needed form controls to be usefully linked into the microdata system |
| 10:26 | <zcorpan_> | i'm sure someone can mint a use case for that :) |
| 10:26 | <Philip`> | That could be a nice way of submitting structured data to a server |
| 10:27 | <Hixie> | not really |
| 10:27 | <Philip`> | without having to come up with unique names for every single input control in your page, and reconstructing that back into a tree structure on the server |
| 10:27 | <Hixie> | user input rarely maps directly to structured data schemas |
| 10:28 | <Philip`> | (particularly if the form controls are generated automatically, like in repetition templates) |
| 10:50 | <zcorpan_> | Hixie: maybe you could solve the naming/RDFa conflict debate and solve the potential Web script incompatibility problem by prefixing all relevant attributes with something |
| 10:53 | <Hixie> | any ideas? |
| 10:53 | <zcorpan_> | data- is taken :P |
| 10:54 | <Hixie> | indeed |
| 10:54 | <zcorpan_> | though data-* isn't much used yet so could be redesigned |
| 10:54 | <zcorpan_> | not that there's anything wrong with data-* |
| 10:56 | <zcorpan_> | "rdf" |
| 10:57 | <zcorpan_> | <div rdfitem><span rdfproperty="name">, document.rdfItems, element.rdfContent etc |
| 10:57 | jgraham | wonders if that is supposed to be a serious suggestion |
| 10:57 | <Hixie> | as noted before, this doesn't really have any more to do with rdf than json or anything else :-) |
| 10:58 | <jgraham> | Because it seems like a really bad idea :) |
| 10:58 | <zcorpan_> | Hixie: as noted before, that only matters a little |
| 10:58 | <zcorpan_> | jgraham: why is it bad? |
| 10:58 | <Hixie> | zcorpan_: :-P |
| 10:59 | <jgraham> | If you really want prefixes it should be really short like md-property |
| 10:59 | <Philip`> | Prefix all the names with µ |
| 10:59 | <Hixie> | it matters enough, imho |
| 10:59 | <Hixie> | Philip`: html attributes have to be ascii |
| 10:59 | <zcorpan_> | "md-" could work |
| 10:59 | <Hixie> | Philip`: (to make hsivonen happy) |
| 10:59 | <zcorpan_> | though it's no shorter than "rdf" :) |
| 10:59 | <Hixie> | md- is ugly |
| 11:00 | <jgraham> | zcorpan_: Because this isn't a generic RDF serialisation and all dong things that irritate the RDF people even more will not help anyone |
| 11:00 | <Philip`> | Hixie: Prefix them with org.whatwg.microdata- |
| 11:00 | <Hixie> | hah |
| 11:00 | <jgraham> | Plus it is silly to put rdf on a pedestal |
| 11:00 | <Philip`> | jgraham: "and all dong things"? |
| 11:01 | Philip` | 's error-correcting parser fails |
| 11:01 | <jgraham> | Philip`: s/all dong/doing/ |
| 11:01 | <Philip`> | Ah |
| 11:01 | <jgraham> | I guess I started a different clause |
| 11:01 | <jgraham> | Hixie: md- is indeed ugly but anything longer than about 2-3 characters is irritating |
| 11:02 | <Hixie> | 0 characters works for me :-) |
| 11:02 | jgraham | would prefer no prefix, really |
| 11:02 | zcorpan_ | is slightly scared about web compat |
| 11:02 | <zcorpan_> | cf formaction="" |
| 11:03 | <Philip`> | zcorpan_: Unintentional uses of the attributes won't cause UAs to misbehave |
| 11:03 | <zcorpan_> | Philip`: i guess |
| 11:03 | <Hixie> | zcorpan_: let's address it when it's a problem |
| 11:04 | <jgraham> | It seems really unlikely that anyone is using the attributes in just the way needed to produce spurious microdata |
| 11:04 | <zcorpan_> | but it might make it hard to use on existing pages that already have <div id="item"> or something |
| 11:04 | <Philip`> | (http://philip.html5.org/data/attr-count-pages-dotbot.txt suggests most of the attributes aren't used too frequently |
| 11:05 | <Philip`> | ) |
| 11:05 | <zcorpan_> | Philip`: the concern is about scripts having document.items matching <div id="items"> etc |
| 11:06 | <Philip`> | Oh, okay |
| 11:06 | <zcorpan_> | so implementing the dom api might make existing pages to stop working |
| 11:12 | <Hixie> | we can always make id=items overwrite .items |
| 11:17 | <Philip`> | id="items" is about the 1209th most common value |
| 11:18 | <Philip`> | (on 355 out of ~425K pages) |
| 11:24 | <Hixie> | ok, intro section at http://www.whatwg.org/specs/web-apps/current-work/#microdata is written |
| 11:25 | <Hixie> | it doesn't cover everything, and i'll add more examples later |
| 11:25 | <Hixie> | but it covers the basics |
| 11:28 | <Philip`> | "favorite-color" - urgh :-( |
| 11:30 | <Philip`> | "A valid reversed DNS identifier is a string that consists of a series of IDNA labels in reverse order (i.e. starting with the top-level domain), the prefix of which, when reversed and converted to ASCII, corresponds to a registered domain." |
| 11:30 | <Philip`> | but e.g. org.example.name is unlikely to correspond (directly) to a registered domain |
| 11:31 | <Philip`> | (since it'd be silly to register a subdomain for every single property you ever use) |
| 11:31 | <Philip`> | Oh |
| 11:31 | <Philip`> | I might have missed the bit saying "prefix" |
| 11:31 | <Philip`> | Seems a confusing definition since it's not at all clear what the prefix of "org.example.name" is |
| 11:32 | <Philip`> | "Types are identified in three ways:" - I only count two |
| 11:40 | <Hixie> | all the lists of ways you can identify things have "predefined types" commented out |
| 11:40 | <Hixie> | will fill that in later this week (maybe tomorrow) |
| 11:41 | <Hixie> | not sure how to fix the reversed dns identifier definition to be easier to understand |
| 11:41 | <Hixie> | bet time now |
| 11:41 | <Hixie> | nn |
| 11:42 | <Hish> | hi. is there a special tag which would help me to display page numbers, date, author, or filename on each page? can I use header/footer for this or is there something else? thanks. |
| 11:44 | <zcorpan_> | Hish: you mean when printed? |
| 11:46 | <Hish> | zcorpan_: yes |
| 11:48 | <zcorpan_> | Hish: i think you can do it with css but browser support is probably flaky |
| 11:49 | <zcorpan_> | Hish: position:fixed will repeat things on every page but might not be suitable for proper page headers |
| 11:49 | <zcorpan_> | Hish: see printed media, generated content and css3 |
| 11:50 | <jgraham> | You might b e able to get it working using Prince |
| 11:50 | <Hish> | zcorpan_: thx. so the bottomline is that this is CSS related and there are no special tags for this. |
| 11:50 | <Hish> | Prince??? |
| 11:51 | <zcorpan_> | Prince is a piece of software that is used to generate the PDF version of the html5 spec |
| 11:51 | <zcorpan_> | supports this kind of stuff |
| 11:52 | <jgraham> | Generally it's a HTML+CSS -> PDF converter |
| 11:54 | <Hish> | is it a proposal or an already working piece of code? |
| 11:54 | <zcorpan_> | the latter |
| 11:54 | <Hish> | sorry. forget it. didn't read your last comment, zcorpan_ |
| 11:55 | <Hish> | do you have a url? |
| 11:57 | <jgraham> | http://www.princexml.com/ |
| 12:45 | <zcorpan_> | Hixie: "This example creates a big list with a nested list for each item on the page, each with of all the property names used in that item./p>" markup typo |
| 12:46 | <zcorpan_> | a markup error that a validator wouldn't catch :( |
| 12:47 | <zcorpan_> | nor a spell-checker, presumably |
| 12:47 | <Philip`> | But you'd catch it when reading the page |
| 12:48 | <zcorpan_> | Philip`: after having done markup validation, you'd expect you would have caught all markup errors |
| 12:51 | <zcorpan_> | maybe a validator could issue a warning if there was a ">" before an implied tag, or similar |
| 12:51 | <jgraham> | zcorpan_: Your expectation would be wrong, however |
| 12:51 | <zcorpan_> | clearly |
| 12:52 | <zcorpan_> | i'd like to know if it's possible to make it right a bit more often, though |
| 12:52 | jgraham | wonders ho "kind" means something like "property" |
| 12:52 | <jgraham> | *how |
| 12:53 | Philip` | looks for synonyms |
| 12:53 | <Philip`> | We could replace it with the "realestate" attribute |
| 12:54 | <Philip`> | Since we already have a "subject" attribute, property could be renamed to "predicate" |
| 12:55 | <jgraham> | Philip`: Noooooooooooooooooooo |
| 12:56 | <Philip`> | Since the attribute is determining how the value is related to the item, it could be called "rel" |
| 12:56 | <jgraham> | Tip 1 for writing a usable markup language: don't use natural language words that most native speakers of the natural langauge don't understand |
| 12:57 | <jgraham> | as part of the language |
| 12:59 | <Philip`> | Everyone should know what predicates are! You can't even do higher-order logic without them |
| 12:59 | <jgraham> | Oh noes! |
| 12:59 | <jgraham> | As gsnedders would say] |
| 13:02 | <zcorpan_> | Philip`: your impl doesn't generate a triple for the <title> |
| 13:04 | <Philip`> | zcorpan_: See line 186 or thereabouts |
| 13:04 | <Philip`> | // TODO: title |
| 13:06 | zcorpan_ | notes that RDF uses title.textContent while document.title uses just the <title>s child text nodes |
| 13:11 | <Philip`> | zcorpan_: (Added title) |
| 13:13 | <zcorpan_> | Philip`: i get <> dct:title "HTML 5 microdata demo" . regardless of what i write as input |
| 13:14 | <Philip`> | zcorpan_: That's because that's the first title element on the page |
| 13:14 | <zcorpan_> | Philip`: maybe you could use an iframe? |
| 13:15 | <Philip`> | zcorpan_: Then I'd have to figure out how to make jQuery give me elements from within that iframe instead of the current document |
| 13:16 | <zcorpan_> | Philip`: you could replace title[0] with title[1] |
| 13:17 | <Philip`> | zcorpan_: I'd prefer to be implementing what the spec says, so any bugs are in the demo setup rather than in the parser code |
| 13:21 | <zcorpan_> | Philip`: btw http://simon.html5.org/tools/js/innerhtml-viewer/getInnerHTML.js has an ascii-lowercase function |
| 13:26 | <jgraham> | function toAsciiLowerCase(input) {return input.replace(/[A-Z]/g, function(char) {return char.toLowerCase()})} |
| 13:28 | <Philip`> | Hmph, '_:n2 c:org.w3.name "HTML5" .' isn't valid because it's not a proper QName |
| 13:29 | <Philip`> | or something like that |
| 13:29 | <Philip`> | http://www.rdfabout.com/demo/validator/ complains "Invalid token" so I assume it's right and I'm wrong |
| 13:32 | jgraham | wwonders how he got spidermonkey to fill up empty array elements with characters |
| 13:32 | <jgraham> | doing something like ["a", "b"].concat(["c",,"d"]) |
| 13:41 | <Philip`> | N3 output should now be correcter |
| 13:42 | <Philip`> | and conciser |
| 13:42 | <Philip`> | except for the bits that had to become verboser in order to be correcter |
| 13:47 | <zcorpan_> | c:org.w3.name is not a proper QName? |
| 13:48 | <Philip`> | It's not a proper "QName or something like that", where the "something" is (([A-Z_a-zÀ-ÖØ-öø-˿Ͱ-ͽͿ--⁰-Ⰰ-、-豈-﷏ﷰ-�𐀀-�][\-0-9A-Z_a-z·À-ÖØ-öø-ͽͿ--‿-⁀⁰-Ⰰ-、-豈-﷏ﷰ-�𐀀-�]*)?:)?[A-Z_a-zÀ-ÖØ-öø-˿Ͱ-ͽͿ--⁰-Ⰰ-、-豈-﷏ﷰ-�𐀀-�][\-0-9A-Z_a-z·À-ÖØ-öø-ͽͿ--‿-⁀⁰-Ⰰ-、-豈-﷏ﷰ-�𐀀-�]* |
| 13:48 | <Philip`> | according to http://www.w3.org/2000/10/swap/grammar/n3-report.html |
| 13:49 | <zcorpan_> | so no dots |
| 13:49 | <aja> | is audio element still around? wondered why it wasn't in microdata additions like img, object, video, & a are |
| 13:50 | <zcorpan_> | it's still around |
| 13:50 | aja | thought so |
| 13:50 | <Philip`> | zcorpan_: Lots of dots, but not "." in particular |
| 13:51 | <Philip`> | aja: Sounds like an oversight |
| 13:51 | <jgraham> | aja: Seems like it makes as much sense as <video> so probably an omisssion |
| 13:51 | <jgraham> | accidential omission |
| 13:51 | <aja> | can someone pls mention to Hixie......not gonna online rest of day |
| 13:52 | <aja> | be online, that is |
| 13:52 | <Philip`> | aja: You could email it somewhere |
| 13:52 | <Philip`> | but I guess Hixie will read the IRC logs anyway |
| 13:53 | <aja> | k...will f/u if i dont see an update.....later all |
| 13:54 | <zcorpan_> | Philip`: maybe you should not use any prefixes to prevent such bugs? |
| 13:54 | <Philip`> | zcorpan_: That would make it unnecessarily hard to read |
| 13:56 | <Philip`> | Also, I don't care much about bugs - readability is more useful |
| 14:01 | <Philip`> | "<[object Object]> c:about _:n0 ." - hmm |
| 14:30 | <Philip`> | It's confusing that <span item><span item><span property=foo>bar</span></span></span> generates no properties |
| 14:39 | Philip` | sees http://chatlogs.planetrdf.com/swig/2009-05-11.html#T10-27-03 has a few more HTML5-related comments |
| 14:51 | <jgraham> | Twitter really, really sucks for, well, as far as I can tell, for pretty much everything. But in particular for all the myriad types of communication where reasoned argument is needed |
| 14:51 | <fearphage> | jgraham: for instance? |
| 14:53 | <gavin> | fearphage: you two should continue this discussion on twitter |
| 14:53 | <fearphage> | you may have a point |
| 14:56 | <jgraham> | fearphage: Ironically it is hard to explain on IRC for rather similar reasons. But look e.g. at rubys's titter page and then try to follow any of the threads backward |
| 14:57 | <jgraham> | |
| 14:58 | <jgraham> | And wonder if the medium is not distorting the message in a rahter harmful way, by allowing people to be irrational by enforced brevity |
| 14:58 | <jgraham> | So that reasoned argument being replaced by pithy one-liners is the norm |
| 14:58 | <jgraham> | and is totally expected and so unremarkable |
| 15:01 | <fearphage> | jgraham: that's twitter's ui failing really. it should show threaded views of conversations |
| 15:03 | <zcorpan_> | and not have a silly 140 char limit |
| 15:03 | <Philip`> | It doesn't have a silly 140 char limit - it has a sensible 140 char limit |
| 15:04 | <Philip`> | If it didn't have that limit then it would be a blog, and everyone has a blog already so there wouldn't be any point in it |
| 15:06 | <jgraham> | Philip`: Indeed. But the 140 character limit is both the distinguishing design feature and the reason it sucks |
| 15:06 | <jgraham> | Well that and the UI |
| 15:07 | <jgraham> | But the UI problem is a distant decond |
| 15:07 | <jgraham> | second |
| 15:07 | <zcorpan_> | if it sucks so much, you could come up with a competing alternative and make people switch and earn lots of money |
| 15:08 | <jgraham> | zcorpan_: I don't deny that people like it. But people like taking heroin but that sucks too |
| 15:08 | <jgraham> | So I don't know what to do |
| 15:08 | <jgraham> | Apart from maybe to ignore it |
| 15:09 | <zcorpan_> | jgraham: give up and take heroin, then twitter about it |
| 15:14 | <zcorpan_> | would maybe be nice to be able to give RDF/XML or n3 as input and convert it to html5 microdata |
| 15:15 | <Philip`> | Is that possible? |
| 15:16 | <zcorpan_> | maybe not losslessly |
| 15:16 | <Philip`> | And: Is that possible in general, or only in very limited situations e.g. where all the predicates are the xhtml/custom namespace? |
| 15:17 | <jgraham> | Why is that useful? |
| 15:17 | <zcorpan_> | didn't say it would be useful, only maybe nice |
| 15:18 | <zcorpan_> | e.g. if you're familiar with microdata syntax but not rdf |
| 15:19 | <Philip`> | <meta item id="n0"> <meta subject="n0" property="about" content="http://subject/">; <meta subject="n0" property="http://predicate/"; content="value"> |
| 15:19 | <Philip`> | Would that work? |
| 15:19 | <Philip`> | as a general way to encode (non-nested) triples |
| 15:20 | <Philip`> | It seems useful to be able to write data using existing RDF vocabularies, so you can easily reuse all the work that's gone into defining them |
| 15:23 | <zcorpan_> | how many are subscribed to www-archive? |
| 15:23 | <Philip`> | How many read it via web archives? |
| 15:23 | <Philip`> | (since that mode of usage is the reason for the group's existence, after all) |
| 15:24 | <Philip`> | Oh, hmm, content="http://..." won't work because that's not an absolute URL |
| 15:26 | <Philip`> | Actually... Is it? |
| 15:26 | <Philip`> | "If name is not an absolute URL, ..." - how can it ever be an absolute URL? It's always just a string token |
| 15:28 | <Philip`> | I can't tell whether (absolute) URLs are meant to be a type distinct from strings, or whether they're just any string that happens to resolve into itself with no errors when you use the URL resolution algorithm |
| 15:29 | jgraham | thought the latter |
| 15:30 | <Philip`> | I assumed the former, but I guess it must be the latter, but then I have no idea whether <span property=foo>http://google.com/</span>; should be an RDF resource (<http://google.com/>; in N3) or still just a string ("http://google.com/";) |
| 15:31 | <jgraham> | I guess a string |
| 15:31 | <jgraham> | But clarity would be nice |
| 15:31 | <Philip`> | It makes sense to me that any content in href/src/etc should be a resource, whereas any other content should just be a string |
| 15:31 | <jgraham> | That's what I assume |
| 15:31 | <Philip`> | If you make it a string then you lose the whole graphiness of RDF, which would be silly |
| 15:31 | <Philip`> | Wait |
| 15:31 | <Philip`> | No you don't, I'm confused again |
| 15:32 | jgraham | doesn't know |
| 15:32 | <Philip`> | I'm sure the <span>http:// ought to be a string, because anything else is crazy |
| 15:32 | <jgraham> | But it makes sense that if you want to make a link to another resource you have to say <a href="http://my.other.resource">; |
| 15:32 | <Philip`> | but property="http://..." ought to be a URL, because anything else is crazy |
| 15:33 | <Philip`> | and href="http://..." ought to be a URL, because anything else is crazy |
| 15:33 | <jgraham> | Yes |
| 15:33 | <Philip`> | so the spec must be wrong because it uses the same terminology for property and for values |
| 15:34 | jgraham | wishes the spec called values "values" rather than "property values" |
| 15:35 | <jgraham> | Philip`: Does it? Where |
| 15:35 | <jgraham> | ? |
| 15:42 | <Philip`> | <meta item id="n0"> <link subject="n0" property="about" href="http://subject/">; <link subject="n0" property="http://predicate/"; href="http://value/">; <meta subject="n0" property="http://predicate/"; content="value"> should work, I think |
| 15:42 | <Philip`> | (though not in my implementation) |
| 15:43 | <Philip`> | jgraham: Um... |
| 15:43 | <jgraham> | Hmm, so it is necessary to keep tabs on where a property came from to determine if it is a url or a string that looks like a URL |
| 15:43 | <Philip`> | jgraham: I'm still just being confused |
| 15:43 | <jgraham> | I have a bug there too, then |
| 15:44 | <jgraham> | Philip`: This only really applies to the RDF serialization, right? |
| 15:44 | <jgraham> | The json serialization seems to have data loss... |
| 15:44 | <Philip`> | In order to produce RDF output (but not JSON), concept-property-value needs to remember whether it returns a URL or a string (which may or may not look like a URL) |
| 15:44 | <Philip`> | and then you use <...> or "..." depending on which it is |
| 15:45 | <Philip`> | but for 'type' and 'name' you just have a string and look to see whether it looks sufficiently like an absolute URL to be treated like one |
| 15:45 | <jgraham> | Philip`: Is that a spec quote? |
| 15:46 | <Philip`> | function looks_like_an_absolute_url(str) { return str.match(/^(([a-zA-Z][0-9a-zA-Z+\-\.]*:)\/{0,2}[0-9a-zA-Z;\/?:@&=+$\.\-_!~*'()%]+)?(#[0-9a-zA-Z;\/?:@&=+$\.\-_!~*'()%]+)?$/); } |
| 15:46 | <Philip`> | That'll do for me, I guess |
| 15:46 | <Philip`> | jgraham: Is what a spec quote? |
| 15:46 | <jgraham> | "In order to produce RDF output..." |
| 15:47 | <Philip`> | jgraham: Regardless of your answer, my answer is no |
| 15:47 | <Philip`> | The spec doesn't say anything about this for the RDF output, because it ignores types entirely |
| 15:47 | <jgraham> | OK, so the spec is wrong here |
| 15:47 | <jgraham> | In some sense |
| 15:48 | <jgraham> | s/wrong/incomplete/ |
| 15:48 | <Philip`> | unless you implicitly read some typing in the bits where it says "the value is an absolute URL" |
| 15:48 | <Philip`> | (which I do, because that's sensible) |
| 15:48 | <jgraham> | (yeha, I did that too) |
| 15:49 | <Philip`> | So, anyway, the spec should clarify that, but otherwise it seems like it's capable of representing arbitrary subject/predicate/object triples as long as you ignore all the extra bits like types and languages |
| 15:49 | <Philip`> | so you could do an RDF-to-text/html converter |
| 15:50 | jgraham | isn't sure about types and names as urls |
| 15:51 | <jgraham> | Oh wait. I think it's OK |
| 15:51 | <jgraham> | I'm being silly |
| 15:51 | <jgraham> | Probably |
| 15:52 | <zcorpan_> | how does RDF/XML distinguish between URLs and strings? |
| 15:52 | <jgraham> | So: Any type or name that looks like a URL is a URL. Any value that somes from a URLish place is a URL but any value that comes from text is text |
| 15:57 | <Philip`> | zcorpan_: <predicate rdf:resource="object"/> vs <predicate>object</predicate> |
| 15:58 | <Philip`> | zcorpan_: according to '<#n1> <#n2> <#n3> . <#n4> <#n5> "#n6" .' in http://www.rdfabout.com/demo/validator/ |
| 16:01 | <zcorpan_> | Philip`: ok |
| 16:03 | <zcorpan_> | The underlying triples |
| 16:03 | <zcorpan_> | :n1 :n2 :n3 . |
| 16:03 | <zcorpan_> | :n4 :n5 "#n6" . |
| 16:04 | <Philip`> | (In N3, the empty prefix is <#>) |
| 16:04 | <Philip`> | (by default) |
| 16:37 | <zcorpan_> | will someone send email about the url vs string issue? |
| 16:41 | <jgraham> | I will if no one else does, but not before I have had a serious attempt at implementing that part of the spec |
| 16:41 | <jgraham> | Which might be this evening but is more likely not to be |
| 16:43 | gsnedders | should probably buy Lightroom at academic prices before he leaves school |
| 16:43 | <jgraham> | gsnedders: You can still do that at university you realise? |
| 16:44 | <gsnedders> | jgraham: But if I'm not going to uni for a year, I then couldn't do it for a year :P |
| 16:44 | <Philip`> | You could ask somebody still in school/university to buy it for you |
| 16:44 | <csarven> | Is there a document somewhere that outlines XML Namespaces as helpful (as opposed to http://wiki.whatwg.org/wiki/Namespace_confusion ) ? Thought it'd be good to have data for both extreme cases, unless, of course, if Namespaces is 100% confusing and useless for all developers. |
| 16:45 | <Philip`> | csarven: Namespaces helpful? That's blasphemy! |
| 16:45 | <jgraham> | csarven: You may have come to the wrong place :) |
| 16:45 | <csarven> | Unless I'm mistaking, the existing approach is hardly scientific. :) |
| 16:46 | Philip` | is not aware of documents listing the benefits of namespaces over other approaches, but assumes there must be some somewhere |
| 16:46 | <jgraham> | (But I guess the TAG will have something about how they are wonderful somewhere) |
| 16:46 | <csarven> | s/mistaking/mistaken |
| 16:47 | <jgraham> | csarven: If I didn't have to go, I would probably argue with that statement :) |
| 16:49 | <Philip`> | I guess the obvious advantages are that they make it possible to create unambiguous globally-unique names (using the DNS infrastructure to avoid conflicts between independent groups), that can be dereferenced to find related information about their meaning, and that can be expressed concisely in XML syntax in a way that's easy to read and write by hand but can still express arbitrarily complex arrangements of namespaced data |
| 16:49 | <Philip`> | Also, colons are cute |
| 16:50 | zcorpan_ | finds http://mailman.ic.ac.uk/pipermail/xml-dev/1999-January/008189.html |
| 16:52 | <Philip`> | That's, um, a lot of syntax |
| 16:53 | <Philip`> | <?xml:begin-ns name="D" urn="http://www.daisoft.com/schema-D"?><D:baz></D:baz><?xml:end-ns name="D"?> |
| 16:53 | <Philip`> | vs <D:baz xmlns:D="http://www.daisoft.com/schema-D"></D:baz>; |
| 16:54 | <Philip`> | XML Namespaces could have been much worse than it is :-) |
| 16:55 | <csarven> | Would I get yelled at if I started a Wiki page on 'Namespaces' which covers both pros and cons? |
| 16:55 | <Philip`> | Not at all |
| 16:58 | <gsnedders> | csarven: I think the current page is more to avoid making the same points over and over again about the conventional wisdom |
| 17:04 | <csarven> | gsnedders Is the decision for HTML5 based on http://wiki.whatwg.org/wiki/Namespace_confusion ? i.e., a subset of views on XML Namespaces |
| 17:05 | <gsnedders> | csarven: No |
| 17:06 | <Philip`> | There are non-confusion-related issues with Namespaces in text/html, like the inconsistency between text/html parsers and XML parsers when names contain colons, that make it less desirable too |
| 17:07 | <csarven> | That's good. So, how was the decision made? Is there more evidence supporting the disadvantages of NS than advantages? |
| 17:07 | <csarven> | I'm just curious about the data gathered for both cases |
| 17:09 | zcorpan_ | wonders which decision is being discussed |
| 17:09 | <csarven> | Pardon me if I'm repeating/rehashing something which has been discussed, I don't wish to take people's time with this. Kindly point me to a URI which answers such questions. |
| 17:20 | Philip` | updates his RDF output to be much less wrong |
| 17:30 | <Philip`> | csarven: I don't think there's a URI giving the rationale |
| 17:30 | <zcorpan_> | Philip`: "_:n2 a <http://www.w3.org/1999/xhtml/custom#org.w3.spec>; ." - what's the "a"? |
| 17:31 | <Philip`> | zcorpan_: Shorthand for <http://www.w3.org/1999/02/22-rdf-syntax-ns#type>; |
| 17:31 | <zcorpan_> | ah |
| 17:31 | <Philip`> | Maybe rdf:type would be less confusing |
| 17:32 | <Philip`> | but I'm assuming it was added to N3 (and Turtle) because they wanted it to be used |
| 17:34 | <zcorpan_> | are there more magic identifiers in n3? |
| 17:35 | <Philip`> | http://www.w3.org/DesignIssues/Notation3.html |
| 17:36 | <Philip`> | but http://www.dajobe.org/2004/01/turtle/ (sort of a subset of N3) only has 'a' and not the others |
| 17:37 | Philip` | hopes those are the most proper specifications |
| 17:38 | <Philip`> | csarven: When you say "decision", which one do you mean? (The decision to use full URIs / reverse domain labels instead of CURIEs for the microdata property attribute?) |
| 17:38 | <zcorpan_> | n3 is more complicated than i had thought |
| 17:41 | zcorpan_ | stops reading and goes on to do something different |
| 17:43 | <csarven> | Philip` Moreso where WHATWG stands with NS and how was that decision made i.e., based on which data? I'm only aware of http://wiki.whatwg.org/wiki/Namespace_confusion |
| 17:44 | <takkaria> | namespaces aren't an end in themselves, though, they're an implementation detail for certain use cases |
| 17:44 | <takkaria> | namespaces are explicitly used, e.g. for SVG and MathML content, the spec says those elements go in the right namespace |
| 17:45 | <Philip`> | csarven: I don't think the WHATWG has a specific standing on Namespaces - sometimes they're considered to be appropriate, sometimes other solutions are considered to be better |
| 17:59 | <csarven> | takkaria Philip` Thanks. |
| 18:02 | <Philip`> | (However, I have heard rumours that XML Namespaces cause babies to grow horns and were the cause of World War 2, so to stay safe I think we should avoid them) |
| 18:08 | gsnedders | rather dislikes uni of Edi for re-inventing email for the sake of applicants |
| 18:09 | <Philip`> | Maybe they didn't re-invent email, but invented it before it had actually been invented, and then stuck with their legacy system |
| 18:52 | <Philip`> | Hmm, the serialised JSON output can be O(2^n) in size compared to the markup |
| 18:52 | <Philip`> | <meta item id="n0"> <meta subject="n0" property="a b" item id="n1"> <meta subject="n1" property="a b" item id="n2"> <meta subject="n2" property="a b" item id="n3"> <meta subject="n3" property="p" content="x"> etc |
| 20:01 | <tantek> | Philip - the "space separated set" feature of profile, class, rel (and property in the example you gave) attributes is quite powerful, and helps with more succinct expression of semantics. |
| 20:02 | <tantek> | I think it's a consequence of content-centric design rather than syntax-centric (or even model-centric) design. |
| 20:03 | <Hish> | hi. can anybody enlighten me regarding footnotes (http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#footnotes)? I understand the three approaches but when it comes to editing a document with long footnotes, then doing copy/paste the part with the <a href> link won't change the footnode content. any ideas? |
| 20:05 | jgraham | wonders if anyone who has used rdflib is around and if so wheher they could point him to some simple instructions for creating a graph and serializing it |
| 20:06 | <jgraham> | Preferbly one that, unlike the officil documentation, doesn't require me to already understand the api |
| 20:32 | <Philip`> | jgraham: Read the source code - it's Python so it must be easy to read |
| 20:33 | <Philip`> | tantek: It would just be nice if it was possible to parse a page without being vulnerable to DOS attacks :-) |
| 20:38 | <jgraham> | Philip`: Not sure that reading the source will allow me to trivially work out how all the design elements are expected to fit together (which is basically the problem) |
| 20:38 | <jgraham> | Also: I just read the xml:base spec and oh boy do the authors hate conformance criteria |
| 20:38 | <Philip`> | jgraham: Maybe the source code contains comments giving high-level documentation of how all the design elements are expected to fit together |
| 20:39 | <Philip`> | although if it does, they'll probably be three years out of date and have no correspondence to the current code, and those comments won't exist anyway |
| 20:39 | <Philip`> | so maybe that's not the best plan |
| 20:40 | Philip` | decides that in general it's impossible to serialise microdata as N3 without explicit blank nodes |
| 20:40 | <Philip`> | (even if you use the [...] syntax whenever possible) |
| 20:41 | <Philip`> | because it's possible to have two predicates using the same blank node, but impossible to represent that non-explicitly, as far as I can tell |
| 21:05 | <krijnh> | http://www.grauw.nl/blog/entry/513 |
| 21:08 | <Dashiva> | So the only conceivable reason to remove namespaces is to spite RDFa, obviously |
| 21:09 | <gsnedders> | Duh. |
| 21:10 | <jgraham> | Philip`: Given there are no docstrings anywhere, I have doubts about the number of comments in the code |
| 21:12 | <jgraham> | Hmm that is the same comment that Laurens posted at simonwillison.net. Unrelatedly, my comment there seems to have become trapped in the moderation queue. Or maybe it is a write only queue |
| 21:25 | <jgraham> | Does the html 5 definition of absolute url make any sense? |
| 21:26 | <jgraham> | An absolute url is one that resolves to itself |
| 21:26 | <jgraham> | But resolving a url requires something to resolve it against which is not specified |
| 21:31 | <Philip`> | jgraham: An absolute URL doesn't need anything to resolve it against |
| 21:31 | <Dashiva> | Would namespaces be less of a mess if tutorials used random strings for prefixes? |
| 21:32 | <Philip`> | Dashiva: No |
| 21:35 | <jgraham> | Philip`: Right but the algorithm doesn't allow for that |
| 21:35 | <Dashiva> | "And the copy and paste thing is less relevant than you all seem to imply. First of all, it would take no more than ten minutes to ensure people understand what example foaf: means." |
| 21:35 | <Dashiva> | Oh boy |
| 21:36 | <jgraham> | Dashiva: What are you quoting? |
| 21:37 | <Dashiva> | Fifth comment on http://realtech.burningbird.net/semantic-web/semantic-web-issues-and-practices/holding-on-html5 |
| 21:37 | <Dashiva> | Also interesting that RDFa chooses to ignore part of the CURIE spec |
| 21:44 | <Philip`> | Which part is that? |
| 21:54 | <Dashiva> | Philip`: Without prefix |