OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: [office] Clarification re: DSDL and W3C Schema


Hello Ken & all,


you wrote:
> Note that RELAX-NG is becoming an ISO standard: ISO/IEC 19757-2.  It is 
> part two of DSDL.

I'm glad to hear that!

> If we choose to make RELAX-NG or DTDs the normative expression, we will 
> be using international standards.  I don't think anyone is questioning 
> that we also will be supporting W3C Schema ... I think the only question 
> is whether it is the normative one or not.

Yes, I think we're all in agreement that we want DTD & XSD deliverables, 
as well as RELAX-NG. Currently, I see using RELAX-NG for definition work 
and converting into the the others as the best option to do so. If the 
conversion are of sufficient quality, then I think everybody is happy. 
But if the conversions are not of sufficient quality, we have a problem 
and will need to discuss again. But basically, this is reflected exactly 
in the meeting result of using RELAX-NG as a working language, and then 
look at how well it works...


Just to give an example of what we're looking at: In the base format, 
the meta data element contains Dublin Core meta data elements, as wel as 
some self-defined ones. The intention is that every meta data element 
occurs only once, although we don't really care in which order. But DTDs 
don't let us specify that.

So what we did is to simply mandate a certain order in the DTD. So the 
current DTD looks like this:
<!ENTITY % meta "(meta:generator?, dc:title?, dc:description?,[...])">

Alternatively, we could have specified repetition in any order, i.e.
<!ENTITY % meta "(meta:generator|dc:title|dc:description|[...])*">
but we felt the first was closer to out intents.

If I remember the talks at XML2002 right, then RELAX-NG lets us specify 
the real thing, namely one of each element, but in any order. Good! The 
converter would of course have to map it into something else, so the 
other deliverables would not quite match. The converter would probably 
use the second choice above, in order to be more general.

So will this be good enough? I'd think so. Resulting DTDs and XSDs 
should definitely be usable. Given that in the base format definition we 
used DTDs, I don't expect the conversion will be any worse than the 
current hand-written DTDs are, at least if we restrain ourselves from 
using every possible RELAX-NG feature. I assume that if a RELAX-NG 
feature doesn't translate well, one could easily tweak the original a 
bit to help the converter turn out better results. So all we really need 
to do is watch the DTD + XSD results as we go along using RELAX, and 
discuss in case there are any problems...


Sincerely,
Daniel



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC