Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Schema concepts
 Bill la Forge wrote: <snip/> > > Now, lets say we have XML type tied to a class, somehow, and we > have attached our methods by some means. Now an element can > reflect a use of that capability. In fact, by defining fixed values in the > schema, we can configure the common capability for a particular > usage without having to create any additional code. This feels like we've > got things in the right order. > I sense something here closely related to some of my thoughts, but I'm not sure it's what you were thinking about. When you say "we have XML type tied to a class, somehow, and we have attached our methods by some means", I think of these attachments as being specific to some application (or maybe interface). The attachments could be different for a different application. In this way, the same element could belong to different classes for different applications. This is consistent with the fact that an element contains only "data", not "methods", whereas a class ususally contains both. This makes an element a degenerate class (in the technical sense, not as a denigration) leading to many possible "solutions" (in this case, classes). Looking at it in this way, an element could be considered to be or belong to a degenerate or incomplete "class" - the application supplies the behavior (interface) while the schema supplies the data definitions. This makes sense to me. Is this anywhere close to what you were thinking about, Bill? On the other hand, why shouldn't a schema be able to define behavior in some way? We might want to call it something else since people tend to think of a "schema" as a description of a data structure alone. This looks like major expansion of the scope of work of the xml-Schemas WG, though, and it would take a long time to develop. > Frankly, if we aren't talking about implementation, I suspect type has > no meaning. If type is more than syntatic sugar, then it seems that it > must be a way of addressing some underlying semantic that is common > to various elements, where the elements reflect usage. > I would say that the type definitions in xml-Schemas Part 2, allow us to impose some additional structure on an xml document. In its turn, xml allows us to impose additional structure on a plain text document. This suggests that we will be seeing a progression of ways to impose more and more structure onto documents. This will be useful, but add complexity. In fact, xml-Schemas Part 1 is already adding more structure by using "type" both for primitive types like integers and for structured types like elements. I actually don't quite see why this is so, since the primitive types can only be in the content (or attribute values) of elements, and do not function as elements themselves, but there it is. Tom Passin *************************************************************************** This is xml-dev, the mailing list for XML developers. To unsubscribe, mailto:majordomo@x...&BODY=unsubscribe%20xml-dev List archives are available at http://xml.org/archives/xml-dev/threads.html *************************************************************************** 
|
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
|
|||||||||
