OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: [xml-dev] DOM AS and RELAX?

[ Lists Home | Date Index | Thread Index ]

The language dependency is mainly towards DTDs with a tiny bit XML 
Schema. It is not mainly a XML Schema contra RELAX NG thing that I'm 
concerned about.

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;
            attribute unsigned long   maxOccurs;
            attribute ASObjectList    subModels;
   void               removesubModel(in ASObject oldObject);
   ASObject           insertBeforeSubModel(in ASObject newObject,
                                           in ASObject refObject)
                                         raises(ASException);
   unsigned long      appendsubModel(in ASObject newObject)
                                         raises(ASException);
};

AS_ALL
This content model represents a simplified version of the SGML 
&-Connector and is limited to the top-level of any content model. No 
element in the content model may appear more than once. Please refer to 
the definition element-all.
AS_CHOICE
This constant value signifies a choice operator. For example, in a DTD, 
this would be the '|' operator.
AS_NONE
Neither a choice nor sequence operator.
AS_SEQUENCE
This constant value signifies a sequence operator. For example, in a 
DTD, this would be the ',' operator.
AS_UNDEFINED
This content model is undefined, and is associated with incomplete 
element declarations in the ASModel, meaning elements implicitly 
declared through an attribute list but without any corresponding element 
declarations.

</example>.

The specified types of content models are a union of the ones for DTDs 
and XML Schema. In DTDs we have AS_CHOICE and AS_SEQUENCE. XML Schema 
has these and adds AS_ALL. As far as I can see some patterns that are 
available in RELAX NG such as interleave can not be supported.

I don't believe in the idea of modifying schemas through a common 
interface. I do still think there is a need for a common interface for 
invoking schema validation on a Document or Node.

Apart from RELAX NG having a problem with this DTD centric model I can't 
say that it's obvious how a Schematron based schema would fit into the 
model either.

The one common thing among the different schemas, except for possibly 
some setup methods, is the possibility to implement:

     boolean verify(Node node);

I think that AS should not bother with modifying scehmas at all. It 
should concentrate on how to specify what schema should be used, how to 
load it if necessary, and how to set validation properties that the 
chosen schema might support and how to validate a Node or Document using it.

Basically drop the following Use cases and requirements from the draft 
together with all the functionality related to them. These use cases can 
only be properly implemented in a way specific to each schema tecnology.
<drop>
Use Cases:

ASU1. Clone/map all or parts of an existing abstract schema to a new or 
existing abstract schema.
ASU2. Save an abstract schema in a separate file. For example, if a DTD 
can be broken up into reusable pieces, which are then brought in via 
entity references, these can then be saved in a separate file. Note that 
a DTD, which may include both an internal and external subset, would be 
an example of an abstract schema.
ASU3. Modify an existing abstract schema.
ASU4. Create a new abstract schema.

Requirements:

ASR1. View and modify all parts of the abstract schema.
ASR2. Validate the abstract schema itself.
ASR3. Serialize the abstract schema.
ASR4. Clone all or parts of an existing abstract schema.
ASR5. Create a new abstract schema object.
</drop>

The only need I can see for editing schema models through the DOM is for 
editing an internal DTD subset. I would say that this is far away from 
the golden 80/20 rule for today's usage and getting further and further 
away as internal subsets get less and less usage (I don't really have 
anything more than my gut feeling to back this up).

By the way, when scraping these from the requirements list be careful 
not to remove:
ASR6. Validate portions of the XML document against the abstract schema.
IMO it is listed in the wrong list since it has nothing to do with 
schema editing.

I'm afraid I might not have made my self totally clear, but hopefully we 
should be able to clarify things along the way in the usual xml-dev spirit.

/Fredrik Lindgren


Mike Champion wrote:

> 3/28/2002 1:06:46 PM, Fredrik Lindgren <fredrik.lindgren@chello.se> wrote:
> 
> 
>>A language neutral variant 
>>should probably be added to the DOM as well, instead of the mess (IMHO) 
>>that is specified in Document Object Model (DOM) Level 3 Abstract 
>>Schemas and Load and Save Specification [2].
>>
> 
> Where are the XSD dependencies that you imply?  
> What would a language neutral variant look like?  This is the
> time to point them out!  
> 
> Concrete suggestions for how the DOM AS module could be cleaned up to 
> better support RELAX NG would be much appreciated ... that is a use
> case for AS, as far as some are concerned anyway.
> 
> 
> 
> 
> 
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
> 
> The list archives are at http://lists.xml.org/archives/xml-dev/
> 
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://lists.xml.org/ob/adm.pl>
> 
> 






 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS