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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-architecture message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: FW: LC-82 XML Schema considered inadequately extensible


Hi All,

Last month, I entered some personal comments on the W3C XML Schema for W3C
consideration. I am attaching the responses I have received, for those
interested in using W3C XML Schema within the ebXML effort.  I have removed
the contact info for these W3C reviewers, lest someone include them in our
list discussions.  If there is need to provide feedback from ebXML, let's do
so in a formal Email, not via a wandering discussion thread. 

The concerns I expressed regarding XML Schema were based in part on my work
in X12 and ebXML.  I identified apparent shortcomings that might hinder
efforts to use XML Schema in X12 and ebXML renderings of business
information.  These replies acknowledge my concerns, and offer some
alternatives to addressing the problem.  I've not yet researched these
alternatives, and have not formed an opinion as to the significance of these
alternatives as they may apply to X12 and ebXML. In any event, those among
the ebXML team who intend to be involved in establishing ebXML syntax need
to maintain an awareness of the issues and solution alternatives. 

Cheers,
       Bob Miller    

-----Original Message-----
From: Jonathan Robie  
Sent: Thursday, June 08, 2000 11:49 AM
To: www-xml-schema-comments@w3.org
Cc: Robert Miller
Subject: LC-82 XML Schema considered inadequately extensible


The Schema WG has asked me to respond to Robert Miller's discussion of 
extensibility, found in
http://lists.w3.org/Archives/Public/www-xml-schema-comments/2000AprJun/0120.
html. 
This
response represents my opinion, and will be taken as further feedback on 
the topic by the Working Group.

On Tue, 2 May 2000 15:43:11 -0400, Robert Miller <Robert.Miller@gxs.ge.com> 
wrote:

>I suppose my greatest concern is that the capabilities represented in the 
>Schema work are not further extendible without also extending the Schema 
>syntax. That's a steep hill for proposed new extensions to climb, and will 
>likely act as a squelch on such extensions. As one who sees shortcomings 
>in what is supported in the current Schema work, I find the closed Schema 
>syntax disturbing.
>Amid the complexity of the Schema specification is some much wished for 
>capability, and I've been among those making wishes, as the DTD capability 
>provides little of what is needed for Business Information Exchange. But 
>as much as I want such capability, I fear that Schema is all we'll get, it 
>won't be enough, and we'll have to pass it by for something better. That 
>would be disheartening.
>A design more in keeping with my desires for extensibility would define a 
>syntax by which active service packages could be associated with XML 
>elements. Edit constraints might be one such service, and one which might 
>(and should) be pre-defined for use. The addition of new services would 
>not require a change to the XML Schema syntax, it would simply require the 
>definition of the new service and access to the process(es) supporting the 
>extended service.

I agree with the need for extensibility mechanisms for XML schemas, and I 
need - and use - extensibility mechanisms myself. However, I see advantages 
to systems such as Extensibility's Schema Adjunct Framework [1], which 
allow extensibility for any schema dialect, and are not dependent on any 
particular external environment. For instance, my company makes a native 
XML database, and we use the Schema Adjunct Framework to define indexing 
parameters and component levels using XDR, and will do the same for XML
Schema.

Several companies are currently writing software that uses such 
extensibility mechanisms to allow their software to interoperate using 
extensions of existing schema languages, but I would say that such work is 
in early stages.

It is not clear to me that such extensibility mechanisms should be embedded 
in a given schema, since the extensions may need to be separated from the 
schema itself. For instance, a given schema might be indexed differently 
for different uses in different databases, e.g. with fine granularity for 
editing, but coarse granularity for publishing.

In my opinion, extensibility mechanisms are vital. They should be extremely 
general,  not tied to any particular environment, and preferably not tied 
to a given schema language, since at least DTDs and XML Schema are liable 
to be important to the future of XML. (Some members of the Working Group 
may disagree with me about DTDs, but I believe that a simple schema 
language will continue to be desirable for many purposes.) They also should 
be capable of being expressed externally to a given schema.

If the Schema Adjunct Framework [1] is not what you want, I encourage you 
to experiment with other approaches. If you wish to embed your extensions 
into a schema, you may consider using Appinfo to do that.

In my opinion, adding support for one limited form of extensibility to XML 
Schema at this point might actually hinder development of more general 
extensibility mechanisms, and since several vendors are experimenting with 
at least one form of extensibility mechanism right now, I would like to see 
the industry gain a little more experience with this approach before 
attempting to standardize it.

Please feel free to respond to this, pointing out things I may have missed 
or misunderstood.

Jonathan

[1] http://www.extensibility.com/saf/index.htm

============================================================================
========================================================

Sir, I have been task by the XML Schema Working Group (WG) to respond to
your comment  "XML Schema needs better support for semantics; in particular,
the ability to link to a repository of semantic information about a
particular object would be useful." submitted by you to the XML Schema
Comments list, Tuesday, 2 May 2000.  My response is as follows:

I researched your comment and I found that the WG discussed
Application-Specific Information and Constraint issues at the XML Schema WG
face-to-face session held 17-18 November 1999 in Reston, Virginia.  During
that discussion the 7 October 1999 W3C Cambridge Communiqué was pointed to
as a source of information relating to your comment.  Based upon my research
it is my opinion that this Communiqué addresses your comment.   The
Cambridge Communiqué is available on the WEB at
http://www.w3.org/TR/schema-arch . The 17-18 November 1999 meeting minutes
are available from the W3C site, but requires a user ID and password to
access the information. The WEB site for the meeting minutes is
http://www.w3.org/XML/Group/1999/11/xml-schema-ftf-minutes.199911.html  

Of course the XML Schema WG will review my response to you and has final
approval  authority concerning my answer.  Please feel free to contact me,
if required.

                        v/r Jim Barnette 

=======================================================================
= This is ebxml-architecture, the general mailing list for the ebXML  =
= Architecture project team. The owner of this list is                =
= owner-ebxml-architecture@oasis-open.org                             =
=                                                                     =
= To unsubscribe, send mail to majordomo@lists.oasis-open.org with    =
= the following in the body of the message:                           =
=      unsubscribe ebxml-architecture                                 =
= If you are subscribed using a different email address, put the      =
= address you subscribed with at the end of the line; e.g.            =
=      unsubscribe ebxml-architecture myname@company.com              =
=======================================================================


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC