Re: SV: SV: SV: SV: Schema help

I  understand, and although I don't speak officially for the workgroup, I 
want to be sure you feel that your suggestions are being heard.  One thing 
that would help, if you have not already done so, would be to mail this 
suggestion to www-xml-schema-comments@w3.org, which is the official 
comments list for the schema specification.  We formally review the 
comments received at that list, and we either open new trackable issues or 
ensure that issues we are already tracking cover them.  Please make clear 
that you are specifically endorsing schematron as a solution, as otherwise 
the WG might just view this as just another request for some form of 
co-constraints, and that's been a tracked request for some time.  I'm also 
copying David Ezell, or WG chair, on this reply.   Thank you very much. 

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------








Bryan Rasmussen <brs@itst.dk>
11/18/2005 03:31 AM
 
        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>
        Subject:        SV: SV: SV: SV: Schema help



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.

Cheers
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';
'xmlschema-dev@w3.org'
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 

time.

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------








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.

Cheers,
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 
to
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 
express
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 14:39:55 UTC