RE: DOM AS and RELAX

FYI for www-dom: There has been a little thread going on xml-dev on DOM AS
and Relax Starting with
http://lists.xml.org/archives/xml-dev/200203/msg01142.html  The discussion
should continue on xml-dev, but it should be considered in continued
refinement of DOM AS.

Michael Brennan wrote:
>Your example seems a good one to me. I also don't like using numeric
constants 
>instead of QNames for datatypes. This may seem less controversial, but the
more 
>open-ended approach toward datatypes taken by RELAX NG just seems more
far-sighted
>to me than an explicit coupling to XML Schema's datatypes.

It seems like it would be a whole lot more useful (and shorter) if
ASDataType was:

interface ASDataType {
  readonly attribute DOMString namespaceURI;
  readonly attribute DOMString localName;
  readonly attribute ASContentModel contentModel;  // null for simpleTypes
  boolean validate(in Node data);
}

Fredrik Lindgren wrote:
>My main concern are the parts related to modification of schemas and 
>their impact on the whole design. What is discomforting is that 
>something called Abstract Schemas has constants, methods and attributes 
>that gives the impression of being a union of known schema constructs 
>rather than the intersection. I give one example below. If you can 
>convince me that my fears are mistaken I'll be happy to accept the spec.

<example>

interface ASContentModel : ASObject {
   const unsigned long       AS_UNBOUNDED                   = MAX_VALUE;

   // ASContentModelType
   const unsigned short      AS_SEQUENCE                    = 0;
   const unsigned short      AS_CHOICE                      = 1;
   const unsigned short      AS_ALL                         = 2;
   const unsigned short      AS_NONE                        = 3;
   const unsigned short      AS_UNDEFINED                   = 4;

            attribute unsigned short  listOperator;
            attribute unsigned long   minOccurs;

</example>

Obviously, describing the content model by an enumeration makes it
impossible to add new types of content fragments.  I guess the question
whether the definition of ASContentModel should be descriptive (I am a
sequence) or functional.

If ASContentModel was functional, it might be something like:

interface ASContentModel {
      boolean validate(Node docFragOrParentNode);
	ASContentModelState initialState;
}

interface ASContentModelState {
	ASContentModelState consume(Node node);
	boolean incomplete;
	boolean satisfied;
	//
      //  maybe some more
}

//
//   could have a few canned interfaces for "standard" content model
fragments
//
interface ASSequenceContentModel : ASContentModel {
}

Received on Thursday, 28 March 2002 19:28:27 UTC