Makx,
> Doesn't the approach you suggest make it hard for XML applications
> to apply a dumb-down rule - the XML encoding
>
> <dc:title>
> UKOLN
> </dc:title>
> <dcterms:alternative>
> UK Office for Library and Information Networking
> </dcterms:alternative>
>
> does not give an indication that e.g. "dcterms:alternative" should
> dumb down to "dc:title". How would an application find out?
It seems to me there are (only?) three options:
(i) the relationship between element refinement and refined element is
carried explicitly in the instance document, using some convention;
(ii) the application has to have "prior knowledge" of the relationship
hard-coded;
(iii) the relationship between element refinement and refined element is
recorded in some form of secondary external resource (e.g. a schema) which
the application reads in addition to the instance.
In the draft XML Schemas, I took the (extremely tentative and not described
in Andy's document, but mentioned at end of
http://www.ukoln.ac.uk/metadata/dcmi/dcxml/examples.html
) approach of adding a "fixed" attribute (dcxml:refines) to each XML element
for a DC refinement, which has as its value a URI corresponding to the
element which a refinement refines. i.e. to replicate the functionality of
rdfs:subPropertyOf in the RDF Schema.
[And yes, I can see the argument that this level of complexity is starting
to look awfully like re-inventing a wheel which has been finely polished
elsewhere already... ;-) ]
So an application which validates an instance against the schema receives a
"parse tree"/node hierarchy which includes this info from the schema as well
as the data from the instance document.
This was something of an experiment to try to address this precise issue:
I'm not convinced it is a good approach because it may not be good practice
re use of XML Schema i.e. it means an application which processes the XML
document without reference to the XML schema operates on a different
structure from one which does reference the schema.
Pete
|