[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