W3C home > Mailing lists > Public > xmlschema-dev@w3.org > November 2005

SV: SV: SV: SV: Schema help

From: Bryan Rasmussen <brs@itst.dk>
Date: Fri, 18 Nov 2005 09:31:44 +0100
Message-ID: <D45A5694803BE943BA46F9A7262BF83D123B41@its42.itst.local>
To: "'noah_mendelsohn@us.ibm.com'" <noah_mendelsohn@us.ibm.com>
Cc: "'petexmldev@tech-know-ware.com'" <petexmldev@tech-know-ware.com>, "'xmlschema-dev@w3.org'" <xmlschema-dev@w3.org>, 'Michael Kay' <mike@saxonica.com>

Well on the subject of co-occurence constraints I would just like to
reiterate what I said earlier, with some extension:

Given that there is likely to be some argument in W3C as to how far such
constraints should be implemented I doubt they will come out as powerful as
Schematron constraints, furthermore I have a hard time seeing this as
producing a syntax as nice as Schematron, therefore I would really like to
see something like:

1. XML Schema adopts Schematron as an extension language of some sort.
2. XML Schema puts some thought into how Schematron can be combined with XML
Schema to the benefit of both, beyond the normal  method of drop schematron
in appinfo. 

I have some ideas on #2, but I'm somewhat conflicted about them - what model
makes sense, syntax etc. so I don't really want to just blurt out with it.
I'd be more interested in hearing what kinds of things other people could
see connecting the two languages.

Bryan Rasmussen

-----Oprindelig meddelelse-----
Fra: noah_mendelsohn@us.ibm.com [mailto:noah_mendelsohn@us.ibm.com]
Sendt: 17. november 2005 18:51
Til: Bryan Rasmussen
Cc: 'Michael Kay'; 'petexmldev@tech-know-ware.com';
Emne: Re: SV: SV: SV: Schema help

Well, I think there are good reasons from time to time to revisit the 
effectiveness of the W3C process and the compromises embodied therein. I'm 
not convinced that a deep dive on that is the best use of this particular 
mailing list.   I happen to like the working groups I've been on that do 
their work in public (in my case, both the TAG and XMLP) and I'd be happy 
for schema to go the same way.  Then again, I really don't think that's a 
substitute for having people who have 30% of their time committed to 
working on a technology.  There's a lot of detail work and care required 
to revise a specification even if there's agreement on the general ideas. 
The discussions need to involve people who have the knowledge and the time 
commitment to work through interactions with existing features of the 
specification.  In the case of co-constraints, it would seem to me that 
there ought to be a careful look taken at the relationship between the 
existing key/keyref/unique constraint mechanisms and anything new that's 
proposed.  It would be nice to believe that we wouldn't just be sprouting 
new and uncoordinated ways of doing things every few years.

So, I personally welcome broader input, but what we're really short of are 
the people who can edit the specification text, draft prose, be 
responsible for the details, etc.  Of course, there are also lots of other 
messy issues to consider when you change the working mode of a group 
including anti-trust laws in various jurisdictions, IP issues, etc.  If 
people feel that they have ideas for how the W3C can do these things 
better, I think the right place to go would be to the W3C staff and/or the 
workgroup chairs.  I personally would not be against having the schema WG 
switch to using a public mailing list for its discussions.  I suspect that 
requires a recharter, but in principle I'm fine with it.  I don't think 
that will solve much of our resource problems.  We don't lack for people 
with good ideas, in email or in person.  We're missing the people to do 
the archticture and drafting work that goes into making all the details 
fit together.   It's hard to do that well without meeting F2F from time to 

Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142

Bryan Rasmussen <brs@itst.dk>
Sent by: xmlschema-dev-request@w3.org
11/17/2005 04:59 AM
        To:     "'Michael Kay'" <mike@saxonica.com>
        cc:     "'xmlschema-dev@w3.org'" <xmlschema-dev@w3.org>, 
"'petexmldev@tech-know-ware.com'" <petexmldev@tech-know-ware.com>, (bcc: 
Noah Mendelsohn/Cambridge/IBM)
        Subject:        SV: SV: SV: Schema help

Damn, an earlier typo in the email address of Pete Cordell added in by me
was replicated in your email. Just on the off chance this thread goes any
further I thought I should correct it. I've cc'ed Pete on this mail. Sorry
for the problem.

Bryan Rasmussen

-----Oprindelig meddelelse-----
Fra: Michael Kay [mailto:mike@saxonica.com]
Sendt: 17. november 2005 10:47
Til: noah_mendelsohn@us.ibm.com; Bryan Rasmussen
Cc: xmlschema-dev@w3.org; ',petexmldev@tech-know-ware.com'
Emne: RE: SV: SV: Schema help

> 1) Although most widely used schema validators are fairly 
> slow, one can in 
> fact implement the XML schema rules at quite high speed.  My team is 
> hoping to publish some work in that area in coming months, 
> and I suspect 
> that others in the industry are working in the same 
> direction.  I think 
> it's important to the success of any technology we choose 
> that it be able 
> to meet the performance needs of our customers.

I would resist this kind of thinking. SQL was successful because it put
functionality first, and left implementors to devise optimisation
strategies. Users need a constraint language that is capable of expressing
arbitrary constraints on the content of a document, and it should be left 
the implementor to work out which of these constraints can be evaluated in
streaming mode and which can't.

SQL today allows the full power of the query language to be used to 
integrity contraints, and users learn when they need to restrict their
ambitions to meet performance requirements. 90% of applications aren't
performance critical anyway.

There's no point telling users to go and use some other technology to do
their validation, the other technology isn't going to be fast either.

Michael Kay
Received on Friday, 18 November 2005 08:34:35 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:56:09 UTC