Re: Why bother using DTDs?

>>Actually there is a problem in XML Schema in that it cannot represent 100% 
>>of all document formats out there. I've actually developed several where I 
>>had to switch to RelaxNG to handle them.
>
>Would you mind giving a little more detail? I'm just curious because I 
>haven't found a schema language that really fits all my needs.

Relax NG has something called interleave which allows elements in a 
collection to appear in any order. While you could force an order, it 
reduces usability and sometimes is just impossible. Lately I was creating a 
series of meta elements and the order really didn't matter. Take a look at 
the XML Schema for the title element in HTML. That demonstrates how XML 
Schema can handle interleave. The problem is that XML Schema requires N! 
choice elements where N is the number of element with cardinality (0,1) or 
(1,1) that includes a set of elements with cardinality (0,*).

>>Actually I really dislike the schemaLocation attribute. I'd like to see 
>>anything that requires instantiating another engine to be put into a 
>>processing instruction. It's also a much cleaner looking method in my 
>>opinion. A few examples:
>>
>><?xml-stylesheet href="" type="" ?>
>><?xml-schema namespace="" href="" type="" ?>
>><?xml-entity symbol="" value="" ?>
>>
>>Here the type attribute allows the document to specify the mime type 
>>associated with the language used. I do not want to see a lockin to any 
>>XML technologies because there are always going to be people (like myself 
>>occasionally) who don't like the standards as is. In the long run I'd like 
>>to see the DOCTYPE portion of a document deprecated and eventually removed 
>>from the standard.
>
>Agreed, PIs for entities and schemas would be a good solution, although 
>having pretty much every single entity of XHTML 1.1 declared as a PI in 
>every document would seem rather awkward.
>Only using those that make sense would be a good solution. Another would be 
>having something along the lines of
>
><?xml-entity-definitions href="..." 
>type="application/x-entity-definition-list+xml"?>
>

A very good suggestion, I'd love to see something like this.

>Anyway, that would lead to less standardization, but it would also mean 
>better modularization, which is what the W3C is currently into anyway.

Perhaps the DOCTYPE area could be replaced with something that just handles 
entities. I think that a combination of the two approaches might be nice. A 
processing instruction to point to a document that contains entities and an 
element that allows you to embed the same contents.

>Having standardized entity lists hosted at W3C (there already are some, 
>unless I'm mistaken - the DTDs link to them AFAIR) would be a good 
>solution.
>

Standardization like this is essential yes.

>>Processing instructions are powerful tools that it seems many of the 
>>working groups seem to have forgotten. Perhaps a body-wide document 
>>affecting conventions in standards. One of the new problems I've found is 
>>that embedding RDF or XSD in an HTML document just looks weird because of 
>>the inconsistencies in capitalization. Though I've mentioned this in 
>>regards to HTML, this is a body-wide problem.
>
>Capitalization tends to be a bit weird, but I don't think you were trying 
>to say that this should be a reason not to embed other XML languages in an 
>existing file, eh? ;)
>

No it doesn't, but this should have never been a problem. This could be 
attributed to growth, but consistent naming conventions I think are 
critical. Being that HTML is by far the most used standard and the likeliest 
thing to have things embedded, perhaps other languages should model their 
behavior after it.

Orion Adrian

_________________________________________________________________
Limited-time offer: Fast, reliable MSN 9 Dial-up Internet access FREE for 2 
months! 
http://join.msn.com/?page=dept/dialup&pgmarket=en-us&ST=1/go/onm00200361ave/direct/01/

Received on Monday, 5 April 2004 13:03:06 UTC