Subject: RE: [Simple] Question about extending mood in rpids-04

From: [email-masked]
Date: Wed, 17 Nov 2004 21:14:13 +0200

<snip>

> > >>>> Can you explain? If I receive a document that has an 
> element I don't 
> > >>>> understand, how can I tell it is an instance of a particular 
> > >>>> substitution group if that is what is required for the 
> document to 
> > >>>> be valid?
> 
> I decided to run some practical tests with xerces schema validator and
> it does what common sense says: if you extend abstract element with an
> element which does not have a definition within this schema 
> it does not
> validate the document. All the examples that i have seen (e.g. xml
> schema best practises/schema primer) usually either import or include
> the previous schema and define some new elements with 
> substitutionGroup
> in this new schema. So some kind of xml Schema versioning is 
> thus needed
> if extension is being done with substitutionGroups.

So, if I interpret this correctly the consequence of this is that if XML document contains an extension to a substitution group all parties trying to validate the XML document must understand the extension. If the extension is not understood whole document is discarded.

Using versioning is probably one way to solve this. However, this would mean that we would need new MIME type for each version. Also, this may lead into huge number of different versions. For example, if somebody would define new SIP method using prescaps that would need a new version.  

I would propose the we implement extensibility using basic XML mechanisms (using ##other or ##any declarations). 

- Mikko
 
> br,
> Jari

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 17 Nov 2004 22:19:59 -0500

In a tangentially related vein,

http://portal.opengis.org/files/?artifact_id=4347

covers related topics. It points out the practical problems of using 
substitutionGroup, alluding to the same issue as raised here. In 
addition, it notes on pg. 10 that

"1.	Many of the existing XML-Schema parsers do not fully support the 
XML-Schema specification and thus lack the ability to correctly process 
GML application schemas.
2.	Most of the available XML-Schema parsers simply validate XML instance 
documents against XML-Schema documents.  They lack the necessary API for 
interpreting XML-Schema document instances.
3.	Typically, the only language binding available is Java.  While it is 
possible to invoke Java routines from other languages using the Java 
Native Interface (JNI), this approach introduces another set of 
technical issues to deal with.

   Specifically, the parsers do not support substitution groups that are 
mandatory for processing GML schemas."

It seems worrisome if we had to include XML schema verifiers in IM 
clients and if the simpler ones do not support the extension features we 
need. I don't think analogies with other applications (OASIS, say) are 
helpful, as these are generally used in fairly heavy-weight server 
applications that weigh in at hundreds of MB anyway.

For the relatively straightforward token-level extensibility we need, it 
is not clear to me that we need to explore the outer edges of XML 
sophistication.

Henning

[email-masked] wrote:

> 
> So, if I interpret this correctly the consequence of this is that if
> XML document contains an extension to a substitution group all
> parties trying to validate the XML document must understand the
> extension. If the extension is not understood whole document is
> discarded.
> 
> Using versioning is probably one way to solve this. However, this
> would mean that we would need new MIME type for each version. Also,
> this may lead into huge number of different versions. For example, if
> somebody would define new SIP method using prescaps that would need a
> new version.
> 
> I would propose the we implement extensibility using basic XML
> mechanisms (using ##other or ##any declarations).
> 
> - Mikko
> 
> 
>> br, Jari
>>