W3C home > Mailing lists > Public > www-zig@w3.org > March 2003

RE: requesting XML records

From: Matthew Dovey <matthew.dovey@las.ox.ac.uk>
Date: Thu, 27 Mar 2003 14:06:20 -0000
Message-ID: <149B1E6A2147804D9651886835D1999A2007EF@sers004.ouls.ox.ac.uk>
To: "Andy Powell" <a.powell@ukoln.ac.uk>
Cc: <www-zig@w3.org>

> And presumably each of these would have an appropriately 
> strict or loose XML schema associated with it - so, 
> applications would still phrase their requests by providing 
> the URL of the XML schema associated with each of the 4 
> 'labels' above?

> Is an application profile that uses 1 DC element and 50 IEEE 
> LOM elements a 'loose simple DC' application or a 'loose IEEE 
> LOM' application or both or either? ;-) The point being that 
> the naming above (and Theo's DCX name) takes a very 
> DC-centric view of the world.  Does this matter?

Both - a DC centric client would request a loose DC record and a IEEE
LOM centric client a loose IEEE LOM record - the server would return the
same record in both cases. 

However, your question makes me wonder whether this is a good solution
after all. In a sense in the "loose" cases it could be argued that the
client *is* sending what namespaces it would like included but that it
isn't really interested in schema (I want a record that contains
identifiable DC elements but I don't care what else is in there). 

I still think ComSpec is the answer here - looking at it we have the
following fields

recordSyntax - ok that's XML
Specification/Schema - well that seems a good place to put in a schema
URI if you want an XML document conformant to that schema
Specification/elementSpec - well that seems a pretty good place to put
namespace URL's if you aren't interested in getting a record in a
particular schema but are interested in getting a record which includes
elements from a particular namespace! (or if the schema in question
allows elements imported from abitrary namespaces within it)

Received on Thursday, 27 March 2003 09:06:26 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:26:05 UTC