[
Lists Home |
Date Index |
Thread Index
]
I fully agree with you, I don't think adding schema modification to the
DOM AS is very useful, and I do also fear that it put too much
restriction on the class of schema languages that can be compatible with
the DOM AS (Schematron is a particularly good example, here).
I have a strong need for the fulfilment of two use cases : document
validation against any given schema language, of course, and the ability
to obtain type informations related to any element in a document
(including type "names" and annotations).
JARV fulfils the first use case, the abstract grammar API MSV could
nearly fulfil the second one but alas it doesn't, AFAIK.
Regards,
Nicolas Lehuen
-----Message d'origine-----
De : Fredrik Lindgren [mailto:fredrik.lindgren@chello.se]
Envoyé : jeudi 28 mars 2002 22:49
À : xml-dev
Cc : Mike Champion
Objet : Re: [xml-dev] DOM AS and RELAX?
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>
>
>
-----------------------------------------------------------------
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>
|
