- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Tue, 03 Mar 2009 11:29:19 -0500
- To: RDFa Developers <public-rdf-in-xhtml-tf@w3.org>
- CC: Henri Sivonen <hsivonen@iki.fi>, Ian Hickson <ian@hixie.ch>
Julian Reschke wrote: >> - Web authors don't understand indirection and will inevitably fail to >> include prefixes in their markup. > > You mean: "prefix mappings", right? Yes, sorry, I mean "prefix mappings". >> A number of people have proposed that instead of declaring prefixes >> using @prefix or via @profile, that a global registry is created for >> prefix declarations. The registry document must be fetched in order to >> understand the prefix mapping. The issues associated with this approach >> are listed on the rdfa wiki[2]. >> >> The biggest issue that the RDFa TF is interested in not creating is a >> backward-compatibility nightmare. If RDFa is parsed differently in HTML5 >> vs. XHTML1.1, the parser code will require a number of really nasty >> if(xhtml_flag), if(!html5) branches. Henri has noted this as an issue as >> well. > > Indeed. > > Minimally, this issue should be addressed for @rel, because it affects > even non-RDFa use cases. Do you think that this proposal could address your issue with @rel? >> - The current RDFa parsing rules don't change for XHTML. In addition, >> only @prefix should be used in HTML5/XHTML5. This should make the RDFa >> TF happy. > > But that does change the rules for XHTML, doesn't it? Or are you saying > that XHTML != XHTML5 (== HTML5 serialized as XML)? Not speaking as a member of the RDFa TF... just kicking around some ideas... Yes, it does change the rules slightly, but shouldn't create any backwards-incompatible changes. That's what I should have said: "The @prefix addition would not create any backwards-incompatible issues, nor would it adversely affect the processing rules. All of the 'XHTML+RDFa 1.0' documents would continue to work." The addition of @prefix /could/ happen in the next revision of RDFa, which would create a new mapping mechanism (not saying that it's going to happen, just that it is a potential avenue). It could also be done in the CURIE spec. I was saying that XHTML1.1 != XHTML5, although we would still need to have that discussion. My preference at this point is to phase use of "xmlns:" out for declaring prefix mappings across all HTML family languages, but the XML community might disagree very strongly. If there is enough push-back, we may end up with both @prefix and @xmlns: being acceptable in both XHTML1.1 and XHTML5, with only @prefix being acceptable in HTML4/HTML5. >> - If a parser detects an undefined prefix, it MAY load a prefix mapping >> document located at this URL: >> http://purl.org/rdf-prefixes/well-known-prefixes >> The document could be generated from the list defined at >> http://prefix.cc/ - perhaps, prefix.cc could be used as the definitive >> list? This will hopefully make the anti-prefix/anti-indirection people >> happy. > > On the other hand, it will make the owners of purl.org extremely > unhappy, unless it doesn't happen frequently. (Did you talk to them?) If the anti-indirection crowd is correct, it will happen quite frequently. If the pro-indirection crowd is correct, it will happen infrequently. We should plan for the worst. I used purl.org as an example - any redirection service would do. I haven't talked to the purl.org folks yet - don't know who to contact there. I also need to talk to them about http://purl.org/media# not resolving, but http://purl.org/media/# resolving. Do you know who I should talk to? -- manu -- Manu Sporny President/CEO - Digital Bazaar, Inc. Scaling Web Services past 100,000 Simultaneous Connections http://blog.digitalbazaar.com/2008/09/30/scaling-webservices-part-1
Received on Tuesday, 3 March 2009 16:29:57 UTC