- From: Mark Birbeck <mark.birbeck@webbackplane.com>
- Date: Thu, 26 Nov 2009 13:46:52 +0000
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: W3C RDFa task force <public-rdf-in-xhtml-tf@w3.org>
Hi Julian, Thanks for this. The changes I'm proposing do actually give us 'URIorCURIEorSafeCURIE' everywhere. :) It's just that since a CURIE is /either/ a [CURIE] or a [safe CURIE], I figured that using the name 'URIorCURIE' rather than 'URIorCURIEorSafeCURIE', to represent this in the prose, would be acceptable. In other words, the functionality is definitely as you describe -- i.e., it is backwards-compatible -- it's just that the short name I've used collapses the two types of CURIE into one, more general notion, of a CURIE. But if there's a feeling that this might confuse people, and that we should use the longer term, then I don't have a problem with that either. Regards, Mark On Thu, Nov 26, 2009 at 12:30 PM, Julian Reschke <julian.reschke@gmx.de> wrote: > Hi, > > here's a high-level comment without looking at the details. > > I appreciate the attempt to make progress. As far as I can tell, the change > being proposed actually will not be backwards-compatible in all cases (for > instance, when changing from URIorSafeCURIE to URIorCURIE). In which case > you really should consider making a change that at least avoids confusion > and potential ambiguity, by making everything URIorSafeCURIE. That would > also align (as far as I recall) with the TAG advice not to use CURIEs where > they might be confused with URIs. > > Best regards, Julian > > > Mark Birbeck wrote: >> >> Hello all, >> >> I'd hoped to get the following proposal to the group at the beginning >> of the week, but it wasn't possible. >> >> Anyway, below you'll find a series of minor changes that I feel would >> need to be made to various parts of the syntax document, in order to >> support URIs and CURIEs in all RDFa-related attributes (except @src >> and @href). >> >> To recap, whilst most of our attributes support URIs and CURIEs >> already, @property, @rel and @rev only supported URIs. This means that >> authors must declare prefix mappings for all predicates, even though >> they are not required to use prefix mappings for subjects or objects. >> We've agreed to try to address this, and I had an action item to come >> up with some proposed text. >> >> >> APPROACH >> >> The first step in sorting this out, is to remove the separation where >> in some places we allow a CURIE, and in others we allow a >> URIorSafeCURIE. >> >> Both situations will now use the same type, which I've called >> 'URIorCURIE'. (This type did used to exist in previous drafts, but I >> think that's ok. Of course, if anyone can spot a reason why we should >> use a different name, then please mention it.) >> >> After making the data type consistent throughout, we then need to >> clarify the processing rules. >> >> And finally, we need to add one or more examples of using a full URI >> for a predicate. >> >> >> DATATYPE >> >> The datatype changes affect section 2.1, as follows: >> >> 1. On @rel, @rev, @property, @datatype, and @typeof, replace 'CURIE' >> with 'URIorCURIE'. >> 2. On @about and @resource, replace 'URIorSafeCURIE' with 'URIorCURIE'. >> >> Also, in section 5.4.4, the bullet-points listing the attributes >> should change to this: >> >> * @about, @datatype, @property, @resource and @typeof support either a >> URI or >> a CURIE. >> * @href and @src support only a URI. >> * @rel and @rev support XHTML link types, URIs and CURIEs. >> >> >> PROCESSING >> >> In section 5.4.2, after the three steps, but before the note, we should >> add: >> >> Note that this algorithm assumes that its input is a CURIE, but in >> practice it >> won't be possible to definitively establish this until step 2; if >> there is no in-scope >> mapping that matches the prefix, then the algorithm should terminate, and >> the >> input regarded as a URI. >> >> In section 5.4.3, the first point should be removed, and in the second >> point, the sentence: >> >> In this case any value that is not surrounded by square brackets, as >> defined >> by 'safe_curie' in the section CURIE Syntax Definition, will be >> processed as if >> it was a URI. >> >> should be changed to: >> >> In this case any value that is not a CURIE, as outlined in section 5.4.2, >> will >> be processed as a URI. >> >> Note that I've left the prose about square brackets intact, because >> there are probably use-cases where people want to say 'safe CURIE or >> nothing'. (I.e., don't fall back to a URI if there is no prefix >> mapping.) >> >> In the sentence after the two (now one) sentences, we should change this: >> >> An example of an attribute that can contain CURIE and non-CURIE values is >> @about. As described, any CURIEs expressed in the attribute must follow >> the >> format of a [safe CURIE]. So to express a URI directly, an author >> might do this: >> >> to this: >> >> An example of an attribute that can contain a URIorCURIE is @about. To >> express a URI directly, an author might do this: >> >> After the example, the next sentence/example combination can be >> duplicated, to give us an extra example, like this: >> >> whilst to express a CURIE they could do this: >> >> <div about="dbr:Albert_Einstein"> >> ... >> </div> >> >> The author could also use a safe CURIE, as follows: >> >> <div about="[dbr:Albert_Einstein]"> >> ... >> </div> >> >> In the next example, we just need to clarify that we're now only >> referring to safe CURIEs; this: >> >> Since non-CURIE values MUST be ignored, ... >> >> becomes this: >> >> Since non-CURIE values MUST be ignored when they appear in safe CURIEs, >> ... >> >> In section 5.4.4, after the bullet-points, the entire sentence reading: >> >> Note that unlike @about and @resource, @rel and @rev do not >> differentiate their two >> types of data by using [safe CURIE]s. >> >> should be removed. The next sentence, which reads: >> >> Instead, any value that matches an entry in the list of link types >> in the section >> The rel attribute, MUST be treated as if it was a URI within the >> XHTML vocabulary, >> and all other values must be CURIEs. >> >> should be changed to: >> >> Any value that matches an entry in the list of link types in the >> section The rel >> attribute, MUST be treated as if it was a URI within the XHTML >> vocabulary. All >> other values will be processed as URIorCURIEs. >> >> The next paragraph and its associated example, beginning: >> >> Note that only values in the link type list have this special behaviour, >> ... >> >> can be deleted. >> >> In the section 5.4.5, the example can have its square brackets removed. >> >> In section 7, the sentence: >> >> Since it is difficult to distinguish between CURIEs and URIs, the CURIE >> syntax adds the notion of a [safe CURIE]. >> >> should be changed to: >> >> A URI that uses a scheme that is not an in-scope mapping cannot be >> confused with a CURIE. However, since there may be situations where >> authors would like to make it explicit that they are using a CURIE, the >> CURIE syntax adds the notion of a [safe CURIE]. >> >> >> EXAMPLES >> >> At the end of section 2.2, we can add: >> >> When dealing with small amounts of mark-up, it is sometimes easier >> to use full URIs, >> rather than CURIEs. The previous example can also be written as follows: >> >> <html xmlns="http://www.w3.org/1999/xhtml"> >> <head> >> <title>Books by Marco Pierre White</title> >> </head> >> <body> >> I think White's book >> '<span >> about="urn:ISBN:0091808189" >> typeof="http://example.org/book" >> property="http://purl.org/dc/elements/1.1/title" >> >Canteen Cuisine</span>' >> is well worth getting since although it's quite advanced stuff, he >> makes it pretty easy to follow. You might also like >> <span >> about="urn:ISBN:1596913614" >> typeof="http://example.org/book" >> property="http://purl.org/dc/elements/1.1/description" >> >White's autobiography</span>. >> </body> >> </html> >> >> Regards, >> >> Mark >> >> -- >> Mark Birbeck, webBackplane >> >> mark.birbeck@webBackplane.com >> >> http://webBackplane.com/mark-birbeck >> >> webBackplane is a trading name of Backplane Ltd. (company number >> 05972288, registered office: 2nd Floor, 69/85 Tabernacle Street, >> London, EC2A 4RR) >> > >
Received on Thursday, 26 November 2009 13:47:28 UTC