db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matthew T. Adams" <matthew.ad...@xcalia.com>
Subject RE: DTD files
Date Mon, 21 Mar 2005 19:46:59 GMT
I would like to see an XSD.  I don't think that it's that hard to read,
plus the tools out there are really good nowadays to provide completion
of elements and attributes.

I'd like to stay away from RelaxNG, only because I don't see the XSD as
being too hard.

Just my $0.02.

--matthew

>-----Original Message-----
>From: Craig Russell [mailto:Craig.Russell@Sun.COM] 
>Sent: Monday, March 21, 2005 11:34 AM
>To: jdo-dev@db.apache.org
>Subject: Re: DTD files
>
>
>Hi Brian,
>
>We have discussed in the JDO expert group that the standard will be 
>published as xsd, but I haven't had time to make the change in 
>the spec 
>itself. The idea I had (which might be completely whack) is to publish 
>the xsd as the norm, and the DTD as non-normative. It is much 
>easier to 
>read a tight DTD than the equivalent xsd IMHO.
>
>So far, we have not had a need to make the jdo and orm doctypes more 
>expressive than we can accomplish using DTD. In other words, 
>there's no 
>technical reason to drive toward xsd.
>
>If RelaxNG is suitable for use in Apache, I'd entertain using it for 
>our purposes. Do  you have details on its closure?
>
>Craig
>
>On Mar 21, 2005, at 11:22 AM, Brian Topping wrote:
>
>> Hi Craig,
>>
>> Yes, this is good.  I'll take a look at that.  From the conference 
>> call week back (sorry I missed everyone this week), we were 
>> considering that the public metadata specs ought to be in 
>XSD, without 
>> DTD.  What do you think of that?  I'm not a big DTD user, so I don't 
>> know what the reasons are that people commonly want to use 
>them.  The 
>> advantages of using XSD are that there is only one spec, that XSD is 
>> much more expressive, and it can be parsed with standard XML tools.
>> If we are still going to maintain a DTD, I would suggest 
>that it is a 
>> mistake to develop an XSD that is not a machine translation of the 
>> DTD, because no XSD is a better answer than an incorrect XSD 
>resulting 
>> from not being maintained.  And if we are going to do a machine 
>> translation, I'd just suggest putting Trang into the build 
>and make it 
>> a build-time artifact rather than checking it it.  It's a pretty 
>> slippery slope if we don't want to stay focused on XSD.
>>
>> Another alternate is to use RelaxNG, which is reasonably expressive, 
>> can be written in XML (so it is can be parsed), and can be machine 
>> translated into both DTD and XSD.  It is not as expressive 
>as XSD, but 
>> if I remember correctly, there are only a couple of XSD 
>constructions 
>> that can't be done in it.  It does add the RelaxNG closure to the 
>> dependencies though.
>>
>> Comments anyone?
>>
>> -b
>>
>> Craig Russell wrote:
>>
>>> Team,
>>>
>>> As I was checking in the dtd files for jdo2 (jdo.dtd and orm.dtd) I 
>>> had to think again about where we should put the official 
>PUBLIC dtd 
>>> files. For JDO 1, it was clear that the site should be Sun. For JDO 
>>> 2, I believe that the answer still should be Sun, because the JCP 
>>> officially owns the IP to the dtd (and xml schema once we have that 
>>> in place).
>>>
>>> Does anyone think that we should change the official web 
>location to 
>>> some other place like the Apache web site?
>>>
>>> Brian,
>>>
>>> The dtd files I checked in reflect the latest JDO specification 
>>> draft. I understand you're interested in converting these to .xsd. 
>>> The last time I saw an xsd for jdo was when Robin Roos made one for 
>>> an earlier draft. He might be able to help get you started with the 
>>> task.
>>>
>>> Craig
>>>
>>> Craig Russell
>>> Architect, Sun Java Enterprise System 
>http://java.sun.com/products/jdo
>>> 408 276-5638 
>mailto:Craig.Russell@sun.com
>>> P.S. A good JDO? O, Gasp!
>>
>>
>Craig Russell
>Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
>408 276-5638 mailto:Craig.Russell@sun.com
>P.S. A good JDO? O, Gasp!
>



Mime
View raw message