Re: [odata] RE: Topic: Schema - language

[Farrukh Najmi <farrukh@wellfleetsoftware.com>]

Please see inline below...

On 09/12/2012 08:31 AM, Handl, Ralf wrote:

Hi Stefan,

The main reason why the XSD is "not normative" seems to be that it only describes the "minimum requirements" for a CSDL document to be well-formed, and that additional restrictions apply to make it correct. These additional constraints are expressed in the prose specification document.

That is quite a normal situation which can be met with a normative XSD + prose in spec that specifies the additional constraints. Ido not see it as a case for not having a normative XSD.

I don't know whether RELAX NG or schematron can help here; AtomPub and AtomSyn use RELAX NG to describe the shape of Atom documents and still need the prose RFC to define what a correct document is, so RELAX NG seems to have the same problem as XML Schema.

Schematron and OASIS Content Assembly Model (CAM) can define additional constraints but even they cannot express every possible constraint.

Can we e.g. express in schematron that the Name attribute values of the EntityType, ComplexType, EnumType, and ValueTerm child elements of a Schema element MUST be pairwise distinct?

I don't quite understand what "pairwise distinct" means so I cannot say for sure. Assuming it cannot be expressed in Schematron or CAM then the prose in spec would be the place to specify such additional constraints while still maintaining the basic syntax spec in a normative XSD.

Thanks in advance!
--Ralf


-----Original Message-----
From: Stefan Drees [mailto:stefan@drees.name] 
Sent: Wednesday, 12. September 2012 11:38
To: Handl, Ralfmut
Cc: odata@lists.oasis-open.org; Stefan Drees
Subject: Topic: Schema - place and language (changed from minutes comment)

* PGP Signature not checked

Hi Ralf,

Am 07.09.12 10:52, schrieb Handl, Ralf:

...Looking at our SVN repository I see mainly plural names: starting with
the SVN conventions /branches and /tags, continuing with
/trunk/fingerprints, /trunk/minutes, /trunk/proposals, /trunk/tools, so
/trunk/spec/schemas fits in nicely.

In fact the only exception is /trunk/spec, so maybe we should rename it
to /trunk/specs J

I'd like to keep the folder tree as shallow (or fordable) as possible,
so I'd prefer /xsd over /schema/xsd (and still prefer /schemas over /xsd J).

@All: opinions?
...

no problem with SVN folder names. I had more the packaging target and 
subsequent URL for client XMLs in mind.

I also left the minutes untouched, since /trunk/schemas nicely qualifies 
as a "schema subfolder" as minuted from the discussion.

Onto something completely different: As we do not seem to be able to 
come up with a normative schema for CSDL, might we enhance the 
situation, in adding a more capable schema language, where all scenarios 
might be supported/validated against, thus describing CSDL normatively? 
What about RELAX NG, or schematron?

@All: opinions? Shall we investigate? What were the corner cases, that 
show the "unexpressible parts" of a schema attempt formulated in the W§C 
Schema Language?

All the best,
Stefan.





* Signature checking is off by policy

---------------------------------------------------------------------
To unsubscribe, e-mail: odata-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: odata-help@lists.oasis-open.org

-- 
Regards,
Farrukh Najmi

Web: http://www.wellfleetsoftware.com