Hi,
I agree that something like this would be really cool. It would require more work than I really want to put in right now - and it would require instrumentation of all W3C specs in order for it to be maximally useful. That's a good idea, but it seems like it might be above my pay grade. Still pondering... On 7/29/2010 2:43 PM, Gregg Kellogg wrote: > I think the proper way to deal with this is through using fragments. For instance, [[CSS#named-pages]]. The question is, how to extract the relevant information to make a reasonable reference? > > Ultimately, bibliography information should be scoured from the documents themselves, presumably marked up with RDFa, as you've helped facilitate. Other documents might be processed using a GRDDL-like process to construct similar information, then a reference processor can make reasonable references using information defined in the document itself. > > For example, from the recent RDFa-core document, we get statements such as the following: > > <at> base<http://www.w3.org/2010/02/rdfa/drafts/2010/WD-rdfa-core-20100803/> . > <at> prefix bibo:<http://purl.org/ontology/bibo/> . > <at> prefix dcterms:<http://purl.org/dc/terms/> . > <at> prefix foaf:<http://xmlns.com/foaf/0.1/> . > <at> prefix rdf:<http://www.w3.org/1999/02/22-rdf-syntax-ns#> . > <at> prefix xhv:<http://www.w3.org/1999/xhtml/vocab#> . > > <> dcterms:title "RDFa Core 1.1"; > dcterms:issued "2010-08-03T05:00:00+0000"^^<http://www.w3.org/2001/XMLSchema#dateTime>; > dcterms:publisher [ a foaf:Organization; > foaf:homepage<http://www.w3.org/>; > foaf:name "World Wide Web Consotrium"]; > bibo:editor [ a foaf:Person; > foaf:mbox<mailto:ben <at> adida.net>; > foaf:name "Ben Adida"; > foaf:workplaceHomepage<http://creativecommons.org/>], > [ a foaf:Person; > foaf:mbox<mailto:mark.birbeck <at> webBackplane.com>; > foaf:name "Mark Birbeck"; > foaf:workplaceHomepage<http://webbackplane.com/>], > [ a foaf:Person; > foaf:homepage<http://blog.halindrome.com/>; > foaf:mbox<mailto:shane <at> aptest.com>; > foaf:name "Shane McCarron"; > foaf:workplaceHomepage<http://www.aptest.com/>], > [ a foaf:Person; > foaf:mbox<mailto:ivan <at> w3.org>; > foaf:name "Ivan Herman"; > foaf:workplaceHomepage<http://www.w3.org/>]; > <#accessing-the-processor-graph> a bibo:Chapter . > <#chaining> a bibo:Chapter . > <#changing-the-evaluation-context> a bibo:Chapter . > <#compact-uris> a bibo:Chapter . > <#conformance> a bibo:Chapter . > <#creating-a-new-item-with--typeof> a bibo:Chapter . > <#determining-the-subject-with-neither--about-nor--typeof> a bibo:Chapter . > > Actually, the code could be a bit better, and extract section titles as well, for example: > > <#accessing-the-processor-graph> a bibo:Chapter . > dcterms:title "7.6.1 Accessing the Processor Graph" . > > A reference could then be made to [[RDFA-CORE#accessing-the-processor-graph]] which could create something like the following: > > ...as discussed in<a href="http://www.w3.org/2010/02/rdfa/drafts/2010/WD-rdfa-core-20100803/accessing-the-processor-graph">Section 7.6.1 Accessing the Processor Graph</a> of [<cite><a href="#ref-RDFA-CORE">RDFA-CORE</a></cite>] > > Of course, given the RDF graph, we don't need to maintain biblio files, and could simply make a reference to [[http://www.w3.org/2010/02/rdfa/drafts/2010/WD-rdfa-core-20100803/accessing-the-processor-graph]], which could extract everything needed for making a reference from the RDF itself. Biblio files are useful when the source isn't in a standard RDF graph and statements need to either be created by hand, or though a separate processing step. It should be easy enough to process the existing biblio files to create information in RDFa format suitable for creating such references. > > Gregg > > On Jul 28, 2010, at 12:28 PM, Shane McCarron wrote: > > >> So.... today during the PFWG Editors meeting, I learned that there is a >> W3C standard way to do citations: http://www.w3.org/2001/06/manual/#citation >> >> Sadly, this is not the way ReSpec does it - and it is not super easy to >> change ReSpec to do it this way. I also think it is stupid, but I think >> lots of the pubrules are stupid... >> >> Anyway, What I was wondering is if there is a way to extend the current >> reference architecture so that it could magically do the text leading up >> to the reference AND the reference itself - wrapping them in the silly >> cite and a elements, inserting abbr elements as needed. My first >> thought was to do something like this: >> >> [[[lead in reference string]REFERENCE]] - that would be backward >> compatible so existing specs wouldn't change and we wouldn't need to >> change the bibliography file. On the other hand, it would not magically >> deal with abbreviations... >> >> Another idea was that we just continue to use [[REFERENCE]], but allow >> an extension to the biblio file that, if present, would supply the >> lead-in text, the reference, and any necessary abbreviations. This >> would require changes to any spec that used ReSpec and used references >> that were so annotated though. That seems like a bad idea. >> >> Finally, I considered some more subtle extension combined with changing >> the biblio file. Like [[ <at> REFERENCE]] would mean insert a reference and >> the standard lead-in for it. [[REFERENCE]] would work as it always had, >> albeit also adding the surrounding<cite> element. >> >> Thoughts? >> >> -- >> Shane P. McCarron Phone: +1 763 786-8160 x120 >> Managing Director Fax: +1 763 786-8180 >> ApTest Minnesota Inet: shane <at> aptest.com >> >> >> >> > > -- -- Shane P. McCarron Phone: +1 763 786-8160 x120 Managing Director Fax: +1 763 786-8180 ApTest Minnesota Inet: shane <at> aptest.com
Hey, sorry for not answering earlier, I've been on vacation! On Jul 28, 2010, at 21:28 , Shane McCarron wrote: > Sadly, this is not the way ReSpec does it - and it is not super easy to change ReSpec to do it this way. I also think it is stupid, but I think lots of the pubrules are stupid... Now now, that's not quite the spiritThis doesn't read like a pubrule to me, it's just from the manual of style. I tend to think that that's open to reasonable interpretation — what isn't is checked by the tools (and hopefully that part isn't stupid). In this case I don't see this as a strong requirement. First, editors will often spontaneously make the first mention of a reference properly expanded. Second, they will know better what "first mention" is, whether it's the one in the abstract or the one in the intro or both, whether to reintroduce it in the 77th subsection of the 42nd section, etc. Thirdly, a number of such references are self-explicit (e.g. [XML]). Finally, there's a link *right there* to the reference section that has the full name and the link. I'd say we're good. > Anyway, What I was wondering is if there is a way to extend the current reference architecture so that it could magically do the text leading up to the reference AND the reference itself - wrapping them in the silly cite and a elements, inserting abbr elements as needed. My first thought was to do something like this: > > [[[lead in reference string]REFERENCE]] - that would be backward compatible so existing specs wouldn't change and we wouldn't need to change the bibliography file. On the other hand, it would not magically deal with abbreviations... I'd like to avoid that if at all possible. The point of picking an HTML-based format with a limited set of shortcuts was to avoid the wiki-language conundrum of simplifying things to the point where you've invented a syntax that makes the raw HTML look good. > Another idea was that we just continue to use [[REFERENCE]], but allow an extension to the biblio file that, if present, would supply the lead-in text, the reference, and any necessary abbreviations. This would require changes to any spec that used ReSpec and used references that were so annotated though. That seems like a bad idea. Yup, breaking existing content bad :) > Finally, I considered some more subtle extension combined with changing the biblio file. Like [[ <at> REFERENCE]] would mean insert a reference and the standard lead-in for it. [[REFERENCE]] would work as it always had, albeit also adding the surrounding <cite> element. Adding the <cite> is fine (I see you've done that, great!). I'm in favour of [[ <at> REFERENCE]] if someone wants to pick it up, but I don't consider it high priority enough to put in the work myself. -- -- Robin Berjon - http://berjon.com/
Hi Stéphane, On Aug 2, 2010, at 21:44 , Stéphane Corlosquet wrote: > Not sure whether this is the right place to send patches, apologies if I've missed something. It is the right place to send patches, and yours has been applied. Thanks! I don't know if you have an account on dev.w3.org, but if you do note that you can also patch and commit directly — we see and review all commits anyway. Thanks again! -- -- Robin Berjon - http://berjon.com/
Hi all, I see that some here have been busy adding support for RDFa in ReSpec (both versions!). That's really cool. Would there be any issue with turning it on by default (naturally keeping the option to turn it off)? If not, I'll proceed with the change. -- -- Robin Berjon - http://berjon.com/
No objection from me. Note that in order to be valid for W3C publication use you would need to make the default XHTML+RDFa. I also added XHTML generation, and it seems to work very well. We even published a spec the other day using it (RDFa Core and XHTML+RDFa 1.1). On 8/17/2010 8:43 AM, Robin Berjon wrote: > Hi all, > > I see that some here have been busy adding support for RDFa in ReSpec (both versions!). That's really cool. > > Would there be any issue with turning it on by default (naturally keeping the option to turn it off)? If not, I'll proceed with the change. > -- -- Shane P. McCarron Phone: +1 763 786-8160 x120 Managing Director Fax: +1 763 786-8180 ApTest Minnesota Inet: shane <at> aptest.com
On Aug 17, 2010, at 16:26 , Shane McCarron wrote: > No objection from me. Note that in order to be valid for W3C publication use you would need to make the default XHTML+RDFa. I also added XHTML generation, and it seems to work very well. We even published a spec the other day using it (RDFa Core and XHTML+RDFa 1.1). Ah, that's problematic because we don't know at DOM generation time whether the user will want to save as HTML or XHTML, and I really don't want to suddenly break things for people who prefer to use HTML. Do you think that your implementation could be made to work as a post-processor so that saving to HTML would do nothing, but saving to XHTML would include the RDFa (unless disabled)? It might be too hackish though. One alternative could be to get the validator to accept it, though I suspect that might take some time :) -- -- Robin Berjon - http://berjon.com/
Actually, the validator DOES accept the HTML+RDFa version. Its just pubrules that does not. I will think about whether there is way to have a mode that means 'add RDFa at the end'. But frankly, I think that would be pretty tricky. On 8/17/2010 9:45 AM, Robin Berjon wrote: > On Aug 17, 2010, at 16:26 , Shane McCarron wrote: >> No objection from me. Note that in order to be valid for W3C publication use you would need to make the default XHTML+RDFa. I also added XHTML generation, and it seems to work very well. We even published a spec the other day using it (RDFa Core and XHTML+RDFa 1.1). > Ah, that's problematic because we don't know at DOM generation time whether the user will want to save as HTML or XHTML, and I really don't want to suddenly break things for people who prefer to use HTML. > > Do you think that your implementation could be made to work as a post-processor so that saving to HTML would do nothing, but saving to XHTML would include the RDFa (unless disabled)? It might be too hackish though. > > One alternative could be to get the validator to accept it, though I suspect that might take some time :) > -- -- Shane P. McCarron Phone: +1 763 786-8160 x120 Managing Director Fax: +1 763 786-8180 ApTest Minnesota Inet: shane <at> aptest.com
On 17 Aug 2010, at 10:50 AM, Shane McCarron wrote: > Actually, the validator DOES accept the HTML+RDFa version. Its just > pubrules that does not. Shane, Could you tell me what text in pubrules would need changing and to what? Thanks for the help, _ Ian > > I will think about whether there is way to have a mode that means > 'add RDFa at the end'. But frankly, I think that would be pretty > tricky. > > On 8/17/2010 9:45 AM, Robin Berjon wrote: >> On Aug 17, 2010, at 16:26 , Shane McCarron wrote: >>> No objection from me. Note that in order to be valid for W3C >>> publication use you would need to make the default XHTML+RDFa. I >>> also added XHTML generation, and it seems to work very well. We >>> even published a spec the other day using it (RDFa Core and XHTML >>> +RDFa 1.1). >> Ah, that's problematic because we don't know at DOM generation time >> whether the user will want to save as HTML or XHTML, and I really >> don't want to suddenly break things for people who prefer to use >> HTML. >> >> Do you think that your implementation could be made to work as a >> post-processor so that saving to HTML would do nothing, but saving >> to XHTML would include the RDFa (unless disabled)? It might be too >> hackish though. >> >> One alternative could be to get the validator to accept it, though >> I suspect that might take some time :) >> > > -- > Shane P. McCarron Phone: +1 763 786-8160 x120 > Managing Director Fax: +1 763 786-8180 > ApTest Minnesota Inet: shane <at> aptest.com > > > > -- Ian Jacobs (ij <at> w3.org) http://www.w3.org/People/Jacobs/ Tel: +1 718 260 9447
Sure. pubrules only permits certain markup languages to be used in W3C rec track documents. These include XHTML 1.0, HTML 4.01, and XHTML+RDFa 1.0. There is no W3C recommendation that defines HTML+RDFa currently. There is a rec-track document that is not yet in last call that defines such a language (http://www.w3.org/TR/rdfa-in-html/) but it is based upon RDFa Core 1.1, which has also not yet entered last call. Consequently, such a language is probably too immature for use in a rec track document. If you REALLY wanted to permit the use of HTML4+RDFa 1.0 in spite of it not being defined in a W3C recommendation, we DO have a DTD for this, and ReSpec.js has been modified to generate documents that validate against that DTD. I just assumed this would be unlikely. On 8/17/2010 9:55 AM, Ian Jacobs wrote: > > On 17 Aug 2010, at 10:50 AM, Shane McCarron wrote: > >> Actually, the validator DOES accept the HTML+RDFa version. Its just >> pubrules that does not. > > Shane, > > Could you tell me what text in pubrules would need changing and to > what? Thanks for the help, > > _ Ian > >> >> I will think about whether there is way to have a mode that means >> 'add RDFa at the end'. But frankly, I think that would be pretty >> tricky. >> >> On 8/17/2010 9:45 AM, Robin Berjon wrote: >>> On Aug 17, 2010, at 16:26 , Shane McCarron wrote: >>>> No objection from me. Note that in order to be valid for W3C >>>> publication use you would need to make the default XHTML+RDFa. I >>>> also added XHTML generation, and it seems to work very well. We >>>> even published a spec the other day using it (RDFa Core and >>>> XHTML+RDFa 1.1). >>> Ah, that's problematic because we don't know at DOM generation time >>> whether the user will want to save as HTML or XHTML, and I really >>> don't want to suddenly break things for people who prefer to use HTML. >>> >>> Do you think that your implementation could be made to work as a >>> post-processor so that saving to HTML would do nothing, but saving >>> to XHTML would include the RDFa (unless disabled)? It might be too >>> hackish though. >>> >>> One alternative could be to get the validator to accept it, though I >>> suspect that might take some time :) >>> >> >> -- >> Shane P. McCarron Phone: +1 763 786-8160 x120 >> Managing Director Fax: +1 763 786-8180 >> ApTest Minnesota Inet: shane <at> aptest.com >> >> >> >> > > -- > Ian Jacobs (ij <at> w3.org) http://www.w3.org/People/Jacobs/ > Tel: +1 718 260 9447 > -- -- Shane P. McCarron Phone: +1 763 786-8160 x120 Managing Director Fax: +1 763 786-8180 ApTest Minnesota Inet: shane <at> aptest.com
RSS Feed22 | |
|---|---|
8 | |
18 | |
28 | |
12 | |
21 | |
21 | |
20 | |
8 | |
14 | |
14 | |
7 | |
33 | |
19 | |
17 | |
1 | |
18 | |
148 | |
73 | |
9 | |
15 | |
46 | |
9 | |
3 | |
4 | |
2 | |
9 | |
4 | |
30 | |
14 | |
3 | |
10 | |
24 | |
14 | |
8 | |
27 | |
3 | |
2 | |
29 | |
2 | |
4 | |
7 | |
8 | |
4 | |
5 | |
1 | |
1 | |
3 | |
4 | |
2 | |
6 | |
1 | |
1 | |
1 | |
5 | |
1 | |
3 | |
4 | |
3 | |
14 | |
1 | |
5 | |
10 | |
10 | |
2 | |
1 | |
10 | |
1 | |
1 | |
18 | |
3 | |
1 | |
24 | |
1 | |
21 | |
6 | |
1 | |
8 | |
3 | |
4 | |
2 | |
8 | |
2 | |
8 | |
5 | |
8 | |
5 | |
1 | |
14 | |
19 | |
1 | |
1 | |
12 | |
1 | |
14 | |
5 | |
12 | |
25 | |
14 | |
4 | |
14 | |
40 | |
3 |
