RE: New draft: DOM Content Models and Load and Save

> 
> Hi there,
> 
> I have read the CM draft specification and am confused by some of it,
> especially by the attribute data types.
> 
> The way I read the spec the specified interface is supposed to be the
> abstract super-model to be subclassed for DTDs and Schema's 
> (e.g. "CMModel
> is an abstract object that could map to a DTD, an XML Schema, 
> a database
> schema, etc. It's a generalized content model object,..."). However,
> CMDataType (used in AttributeDeclaration) specifies several 
> primitive types,
> such as integer, byte and boolean, which cannot be 
> represented in DTDs. And
> these declarations are insufficient for XML-Schema's, these 
> would have to
> extend the set drastically. So the generic content model is 
> too specific for
> DTDs and too generic for XML-Schema's it seems to me?
>
Good point. It still needs to be refined further. But this is the current
thinking on it.
In DOM CM we did want it to be an abstraction of other content model
definitions. So it incorporated some widely used primitive types like the
ones you have mentioned expecting that other content models will be able to
use these types in their design. One of the reasons to do that was to get
around the very restrictive type support ability of the DTD's and let the
user of the DOM CM implementations to do better type checking in their
computations. The compatibility with XML Schema primitive types is a cost
vs. benefits issue. If we do not provide any integer or long etc.,
representation, a DOM CM users will not be able make use of these widely
used data types. Since XML Schema defines decimal data type as a primitive
type, it will lead to confusion in implementations of DOM CM as how to
represent the decimal type in specific language bindings. Since integer and
other data types are well defined and available in various language
bindings, we have decided to support those instead of the decimal. This
however, leads to XML Schema CM api problem. When that api is defined, it
may need to be decoupled form of the CMDataType definition. 


> AttributeDeclaration seems to be completely targeted to what 
> DTDs support,
> e.g. enumAttr seems to be more something for CMDataType to 
> me. Likewise, the
> multiplicity attribute of CMChildren can only be 0, 1, or 
> many, like in
> DTDs. Why confine it to these values, when XML-schema's can 
> also constrain
> to  values like 2 3 18 etc. The XML-schema specific interface 
> would have to
> add an extra multiplicity method, because the standard one 
> does not allow
> multiplicity to be 4.
> 
In XML Schema the element contents in an element declaration is defined
through type definitions rather than simple content model in DTDs. Thus
these are very different ways of declaring the elements and very hard to
find a common subset from which both (DTDs and Schemas) can be derived. So
when the XML Schema CM api's are being defined the element declaration
components may be described independently of the way being defined in DOM
CM.

> NodeCM has all these nice canDoSomething(Node...) methods. I 
> wonder why
> AttributeCM has no such methods. I mean, something like
>      boolean matchesType(String value)
> in which you could pass a potential value, and the 
> content-model tells you
> whether that string of characters matches e.g. an integer or is in the
> possible value enumeration or whatever type someone has 
> specified for the
> attribute in a specific content model. It seems to me that it 
> is desirable
> that a programmer's implementation does not have to change 
> much if you move
> from DTDs to Schemas for example, but this is not listed as a 
> requirement in
> the spec (or is it?). If this is not the case, why a generic 
> model in the
> first place?
> 
We are trying to find a balance between which are required and which are
utility functions. If you have some suggestions that you feel is a required
feature please send it along. Remember, a lot of these utility functions
like type conversion can be done through specific language bindings.
> 
> I hope somebody can explain the logic of it all to me, now 
> that I have tried
> to express my confusion?
> 
> --Sander.
> 
> 
> 

regards
Reza

Received on Monday, 12 February 2001 20:04:04 UTC