- From: Alan Kent <ajk@mds.rmit.edu.au>
- Date: Wed, 20 Mar 2002 16:37:27 +1100
- To: ZIG <www-zig@w3.org>
On Wed, Mar 13, 2002 at 11:35:38AM +1100, Alan Kent wrote: > Problem: I have a database of XML documents. I want to be able to ask > for records to come back as the full document (marked up in XML) or as > dublin core metadata (again, marked up as XML). > ... > I think the theoretically correct approach is in present requests, use > recordComposition of 'complex', then in the 'Specification' type specify > the optional schema OID along with the element set names. The schema OID > would be different for the two forms of XML, but the record syntax OID > for both would be the XML record syntax. I realise now why I think I got confused about schemas. In the Explain record for ElementSetDetails, the key is db-name, element-set-name, and record-syntax. The schema OID is there, but it is not part of the key. Eg, the same element set definition for 'B' must apply for all 'GRS-1' record syntaxes. I cannot change the element set definition per schema. GRS-1 makes life a little clearer than XML in this case. If I want to store documents in a database and get it back as the original document (XML in a GRS-1 field) or as Dublin Core (each Dublin Core element in a separate GRS-1 field), I need different element set definitions. 'B' (brief) for the document and for the Dublin Core version want different GRS-1 fields to be returned. Should 'schema' of ElementSetDetails have been part of the key? (Or am I still missing the point?) I can understand this minor mistake slipping through with all the confusion over the years about schemas and syntaxes, but I can also belive that I have missed the point again!!! We used the Explain database when implementing our internal model of the server back when we were first learning Z39.50. This (possible) error in the Explain records certainly adds to the confusion. Hmmm, reading a little further, there are RetrievalRecordDetails too, which has as a key 'databaseName', 'schema', and 'record-syntax'. This then lists detailsPerElement. So the list of elements can change if the schema or record syntax changes. But when listing element sets, the element set definition (currently) cannot change when the schema changes. This I think adds weight to the idea that the schema should be part of the key for ElementSetDetails. Sorry, I will go further - currently for ElementSetDetails you cannot have more than one schema per record syntax because the schema is not part of the key. So an element set definition for a record syntax (eg: GRS-1) is bound to exactly one schema. (Does this mean its undefined/not explained if you request a different schema? Or that you are not permitted to have more than one schema per record syntax?) Any clarification/opinions welcome. I was starting to come to the model that a database might have a 'primary' schema it used internally, but users could request a different schema (transforming the data for example from a manual marked up in XML to dublin core). Then a record syntax could be applied to the schema to say how to encode that data for delivery. But I suspect that this view is not correct - I started reading RET.2.2 on schemas and the ARS, and got totally lost again. I mean, what does tag sets have to do with the XML record syntax for example? Maybe schemas are not a way of returning the same data in different structures, but rather just a way of changing the names (tag paths) returned for the same data (same GRS-1 fields). If this is the case, then schemas are not the solution for my original problem stated at the very top of this mail. Thanks for any clarifications! Alan
Received on Wednesday, 20 March 2002 00:38:02 UTC