- From: Dan Brickley <danbri@w3.org>
- Date: Wed, 25 Jun 2003 18:28:27 -0400
- To: Joseph Reagle <reagle@w3.org>
- Cc: Masayasu Ishikawa <mimasa@w3.org>, public-rdf-in-xhtml-tf@w3.org
* Joseph Reagle <reagle@w3.org> [2003-06-25 17:46-0400] > On Wednesday 25 June 2003 16:41, Dan Brickley wrote: > > My understanding that we already have a generic metadata syntax, ie. > > RDF/XML; I'm hoping we'll find a way to allow XHTML 2.0 documents to be > > enthusiatically deployed with embedded islands of full RDF/XML (eg. in a > > <meta/> element or elsewhere), rather than have to wait for XHTML 3.0. > > hrmm... Let me see if I can successfully pull together a map of the > landscape as I see it now: Thanks, this was useful. > > XHTML1.* > 1. Hacks: > a. Commenting out the RDF, (yuck; I'd rather not have validatable pages) > b. Sticking in a script tag. (better... just...) > > Assessment: These are architecturally inelegant -- though I actually prefer > the script element over comments and wonder what led CC to use a comment... > These are the solutions to beat. yup > 2. Validation: I think this is needed. So much of W3C's public image is couched in terms of HTML pages being valid/ok/checked/good. We need some notion of validation or else the public will get a very confusing message. > a. Create a version of a simple RDF syntax (for relatively "flat" data) > that could be squeezed into the meta elements in some way. This is what > many of the scenarios seem to require, but folks also say they want > arbitrary RDF. Flat takes us back to 1996. We didn't spent 5+ years on RDF just to go back to attribute/value pairs :( (per our IRC chat yesterday, I think you overstate the TrackBack requirement for flatness). > b. Create a version of a general RDF syntax that is validatable by a DTD. > The RDF community doesn't seem to want create a new or constrained syntax. A few comments: - some of us would be interested in an investigation of a fresh 'start over' syntax, or syntaxes. A 'regular' syntax, ie. with predictable element and attribute names would be needed for DTD compatibility. Some want a new regular syntax (N-Triples in XML). But there is also interest in other non-regular syntaxes, which would take us beyond DTDs. (so when you say 'the rdf crowd don't want...', are you just noting that in context of dtds?) - whether we do this is not the same question as whether RDF Core WG in its current phase does that. RDF Core needs to finish first... > c. Create a new sort of XHTML1.* document using XML Schema where the XHTML > is strictly validated, and the RDF/XML is laxly validated. Mimasa has > written such a schema. This is fantastic! (can you tell my preference? ;) > d. Create a new sort of XHTML1.* document using NRL, Schema, and RNG where > the XHTML is strictly validate by Schema, and the RDF/XML is validated > using RNG. Mimasa has written such a schema. This would be even more fantastic! Sounds like Mimasa has done all the work... > e. Create a new sort of XHTML1.* document using RNG that validates the XHTML > and RNG. This is the only thing *not* done by Mimasa <smile/>, though I > assume it could be done? Could a single online validation service handle this plus the previous two scenarios? Just one approach would be enough to allow people (at last) to deploy RDF-in-XHTML.... > > Assessment: Since Schema is mature and a W3C REC, I think option C has the > most likely chance of success and it requires constituencies to write the > formal specification, the schemas, and support a validator. The schemas are > already written, and I think a validator could be trivially layered on top > of XSV, so the task would then to formally specify it and publish it as a > NOTE, RFC, or REC... c. sets the scene nicely for (d) and (e) to follow. The critical thing is the validator for end users. > > 3. Semantics: > a. Solve the arbitrary semantics of mixed XML problem. > Assessment: I'm avoiding the issue the TAG is facing on what is the > "meaning" of all these things when combined beyond "ignore the namespaces > you don't know." > http://www.w3.org/2002/04/htmlrdf Hard problem. Some approach based on identifying islands / sub-trees makes sense. I don't think we need to deal with this now, except perhaps some notion of 'quoting', so that the place within which (RDF) content appears in the enclosing elements is significant to the RDF's relationship to the document as a whole. But we can avoid this for now, and just define HTML/META and that would be a major improvement. > > 4. **Conclusion**: Dan (and others), do you support my proposal to create a > XHTML(valid)+RDF(lax) document for XHTML 1.*? Yes, most definitely. (for XHTML 2.0 too, unless the HTML WG get more enthused about both RDF and RNG) > http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2003Jun/0012 > > > > XHML2.0 > Similar to XHTML1.* but we know: > 1. It will be based on XML Schema from the start -- though I'm still unsure > what that community will do without the entities they are so fond of. yup. > 2. They will have a richer, nested, metadata element which could be > exploited *if* folks were receptive to re-casting RDF into a meta-data tag; > but they don't seem to be, see 2a above. Perhaps N-Triples in XML has a role, but it is pretty hard to read, let alone write. > 3. They have *NOT* agreed to replace the meta element with RDF, nor to use > it nor lend it any support beyond possibility of ignoring it (i.e., laxly > valid). We should be grateful for small gifts... :/ Laxity is the best we can hope for, I suspect. > This is because even XML Schema can't validate generic RDF. I think > to get the HTML WG to actually include and *rely* upon RDF as part of the > core specification, I think they'd have to use RNG, which I don't think is > likely. (Again, we could define a document on the side and provide a > validator, but it wouldn't be *part* of the core XHTML spec.) Making something that was used and useful by content authors would be great... My hunch is that RNG will gradually take over, with XML Schema playing a major role in more B2B-ish scenarios, but that's pure speculation. Dan
Received on Wednesday, 25 June 2003 18:28:38 UTC