Sigge, As stated in my response to Jane I don't think the extra tag (simple-data) is really any aid towards parsing. Since DOM parsers treat text as a node anyway inserted an extra parent node really doesn't do much. You know this right? Therefore am I not getting something that you intended.
But, probably putting the complex value rooted under another tag may make sense. I look forward to reactions of others.
> -----Original Message-----
> From: Sigfrid Lundberg, NetLab [mailto:[log in to unmask]]
> Sent: Thursday, March 07, 2002 8:05 AM
> To: [log in to unmask]
> Subject: Re: Public Comment on DC-simple XML Schema declaration within
> On Thu, 7 Mar 2002, Carl Lagoze wrote:
> > 3. We (DCMI) make an easy stab at this by providing a base schema
> > that a) allows a value of any xml subtree but b) requires a
> text value
> > resulting in xml like the following:
> > <?xml version="1.0" encoding="UTF-8"?>
> > <creator>
> > <firstName>Carl</firstName>
> > <lastName>Lagoze</lastName>
> > <affiliation>Cornell University</affiliation>Carl
> > Where the text string is the "dumb-down" value. This essentially
> > copies what the RDF construct is doing.
> I agree with Carl here. I would like to add a few points,
> though. Assume, for the purpose of making a distinction between data
> searching and data presentation that we change the above syntax just
> <affiliation>Cornell University</affiliation>
> <simple-data>Carl Lagoze</simple-data>
> Now, suppose that <creator>...</creator> is a well known XML
> construct, which is known by a wide range of search engines or
> The 'simple-data' tag should be such that I could be able to index its
> contents in my database, and by doing so, I should ensured
> not to mislead
> my users. Which is basically the same as saying that it
> should obey the
> dumb down princple.
> The <complex-data> ... </complex-data>, is presumably less well known
> than 'creator' itself, but I think it would be a very good idea to
> have common syntactic entry-point (like a tag called 'complex-data')
> to any such complex that people might use.
> Neither Carl, nor me, would index that field. Still there should be a
> code of best practice that would simplify the use of whatever is
> there, although we might not understand exactly what it is.
> For instance, that code of best practice should enable me to do
> something like the following
> <xsl:apply-templates match="complex-data">
> <xsl:for-each select='*'>
> <xsl:when test="last()">
> <xsl:apply-templates/>. <!-- full stop -->
> <xsl:apply-templates/>, <!-- comma -->
> in a hit presentation. Which would yield in case of Carl:
> Lagoze, Carl, Cornell university.
> That is, promiscuous concatination of complex data should be
> meaningful to
> humans in a presentation of a hit regardless, of encoding
> scheme. Which,
> among other things, imposes constraints on the ordering of
> elements inside
> > I'm thinking that the third is the best alternative is the best and
> > I believe possible.
> I agree.