[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Namespaces, schemas, Simon's filters.
From: "Tim Bray" <tbray@t...> > At 04:41 PM 20/08/01 -0700, Fuchs, Matthew wrote: > >So, to contrive an example beyond foo and bar (with the obvious danger that > >people will spend their time trying to pick apart the example, rather than > >use it to understand the goal), suppose I want to create a Schema to > >coordinate graphics, music, and text. So I create a <graphic> element, a > ><music> element, and a <text> element and I have three different people > >working on designing each of these elements. Now, my graphics designer > >decides he wants to have a <line> element to describe lines that will be > >drawn. Similarly, my musician decides he wants a <line> element to describe > >a line of music (perhaps strophe would be better, but then perhaps I've > >chosen one as ignorant of the subject matter as myself). And, of course, my > >writer also wants a <line> element > > OK, I think I get it. Local element types allow the <line> > element to have different validation rules depending on > whether it's a child of <matt:music>, <matt:graphics> or > <matt:text>. Clearly something that DTD's can't do but is > desirable. But is it a superficial usefulness? If they are separate lines semantically, why not put them into different namespaces? matt_graphics:line and matt_music:line If you still needed the container, you could use default namespacing so the file size would not be different. Why is containment more useful than subclassing line[@class="music"] and line[@class="graphics"] or specialization line[@type="multisegment"] and line[@type="single"]. This kind of need is much more common than having uncoordinated development within one namespace. The local element declarations exist because the Schema WG didn't want attributes to have anything that elements did not also have. (This complication is the result of the calls for "simplification" a few years ago that claimed that elements should be used instead of attributes.) Attributes (unless they have a different namespace) are usually strongly coupled to the element in a way that elements are not. We can imagine cell of data outside a table, but a cols attribute divorced from a table has no independent meaning. This is reflected in the syntactic differences between elements and attributes: an attribute must have an element, but an element need not have a parent. So XML's attribute syntax enforces a distinction in well- formedness which element syntax cannot: inseperability. XML Schemas goes even further with this anti-attribute bias. By not supporting any subclassing using attributes, it keeps us in the 1960s world of "gencoding". In the XML Schema language itself, it means that instead of being able to say <content type="mixed"> we have to have <content><mixed> where specialization is performed by introducing spurious intermediate elements. Cheers Rick Jelliffe
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|