Re: The XML Schema GRDDL Story

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