- From: Phillips, Addison <addison@lab126.com>
- Date: Mon, 30 Mar 2015 15:59:16 +0000
- To: "Eric Prud'hommeaux" <eric@w3.org>
- CC: "public-ldp-comments@w3.org" <public-ldp-comments@w3.org>, Steven Atkin <atkin@us.ibm.com>, "www-international@w3.org" <www-international@w3.org>
> > > > I guess what you're saying is that, although the "optional language tag" > should be a language tag, any string could appear there and it would not be a > processing/parsing error if something that didn't follow BCP47 appeared > there. Is that correct? > > Right. Turtle Patch treats it as a string. Other stuff in the RDF stack would > break if one didn't at least follow obs-language-tag (SPARQL a '-'-sensitive > langmatches function and probably some UIs crack the'-'s) but nothing would > treat a rigorous LanguageTag differently from an obs-language-tag. > Okay, that matches what I recall of reviewing those other specifications. I do tend to favor being consistent, even when being non-normative, in talking about what a field can contain. It is good to point out that, although a value is "just a string" in one place, it might cause failures elsewhere later if it isn't actually well-formed (at least to obs-language-tag). A family of specifications should all use the same requirements. In any case, I don't object to using the wording now in place and don't think it needs to be belabored. I also note that the link to RDF 1.1 ends up at a definition that includes a "well-formed" requirement (that requirement is stronger than obs-language-tag). Addison
Received on Monday, 30 March 2015 15:59:44 UTC