- From: Dan Connolly <connolly@w3.org>
- Date: Wed, 15 Dec 2004 13:44:45 -0600
- To: "C. M. Sperberg-McQueen" <cmsmcq@acm.org>
- Cc: Eric Miller <em@w3.org>, Ben Adida <ben@mit.edu>, www-archive@w3.org, Dominique Hazaël-Massieux <dom@w3.org>
On Wed, 2004-12-15 at 12:31 -0700, C. M. Sperberg-McQueen wrote: > On Tue, 2004-12-14 at 11:26, Eric Miller wrote: > > > I'm still sort of on the fence about following xsi:schemaLocation, with > > a slight preference to include this capability. But if you guys think > > not, at least @@'ing this issue in an updated GRDDL note is probably > > worthwhile. > > To be really seaworthy, it's good if schema-aware software well, that's the issue right there. GRDDL isn't inherently aware of XML Schema; it knows about XHTML, RDF, XML and namespaces, and it depends on some widely deployed programming language(s), for which XSLT seems the best fit these days (though I would like to find time to try out javascript). The question is whether to support xsi:schemaLocation and make it aware of XML Schema when it didn't before. > can > > - accept pointers to schema documents as part of its > invocation Indeed... we don't do that, and we could. (Well, in this case, it would be pointers to RDF documents that provide data-view:transformation, data-view:namespaceTransformation, and data-view:profileTransformation links/statements). > - check the namespace URI for a schema document that we've implemented (provided the schema is in RDF or has GRDDL markup). > - check the namespace URI for a RDDL document, and > find a schema document there if the RDDL points to > one That we support, provided the RDDL document has GRDDL markup. > - follow the hints given in schemaLocation attributes That's what we're considering. data-view:transformation attributes serve a similar purpose, meanwhile. > - consult a local or built-in store of information Yes... that's quite similar to pointers at invocation time. > preferably giving the user some control over which of > these happens when, and whether failure at any stage > should mean the processor continues (oh, well, we didn't > get any components from that source, I'll work without > them) or not (fatal error, you told me to find XHTML > components or die -- I didn't find them, now I'm > dying). > > Demos, and even some production applications, can get > by without all of these. But if the service can ONLY > use schema documents found at the namespace name, then > it does seem to mean no one can doctor an existing > schema document for a namespace owned by somebody else > and see what the service would do. So if I want to > experiment with (say) annotation of the OAI or Dublin > Core schemas, my choices are (a) to hack into their > servers and replace their copy of their schema documents > with my own, or (b) to fudge all of my examples by > replacing references to their namespace with references > to a namespace I own, or where I can at least control > what gets served from the namespace name, or (c) I can > try to persuade the owners of those namespaces to > humor me and put my experimental version of their > schema on their server where all the world can find it. > None of these three seems quite right for me. > > I think the idea that for any namespace there is > or should be a single schema document is -- well, it > seems awfully closed-worldish to me. > > So I'd encourage more flexibility in locating > schema documents. > > For the masochistic, more on locating schema components at > http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2004Dec/0012.html > (towards the bottom, proposed content of appendix > Y.s) and http://www.w3.org/People/cmsmcq/2001/schema-resolution > > Michael > -- Dan Connolly, W3C http://www.w3.org/People/Connolly/ D3C2 887B 0F92 6005 C541 0875 0F91 96DE 6E52 C29E
Received on Wednesday, 15 December 2004 19:44:35 UTC