Re: Comment on XSD 1.1

Original Message From: "Rick Jelliffe"
>
> Pete Cordell wrote:
>>
>> I'm not sure how a base layer that is not streamable can have a layer 
>> added to it that makes it streamable.  Am I missing something?
> That different layers can have different restrictions or extensions that 
> give them different implementation characteristics
> should be obvious: this is the real world, not the artificial one of 
> facets and type derivation where properties cannot emerge but always need 
> to be present in the base!

I'm just trying to understand what you're proposing.  We come from different 
worlds.  In my telecoms background, higher layers add functionality based on 
the services of the lower layers.  Hence I think we have a terminology 
mis-match.  Since even within the telecoms world there are terminology 
confusions (and terms often vary according to the context!) I don't think 
it's too surprising that in a cross-displine discussion some terminology 
needs to be clarified.

In the terminology of my world I think what you're proposing is more akin to 
defining profiles, each of which may, in a deviation from pure profiling 
principles, add a small bit of additional functionality.

> ....
>
> In concrete terms, the layering might look like this:
>
> Layer 1: RELAXSD    - targeted at standards and publishing and languages?
>     ...
> Layer 2: Databinding XSD   - targeted at databinding and small messaging?
>     ...
> Layer 3: XSD 1.1 - targeted at database and storage or type-centric 
> applications?

I think a modular approach would be better.  For example, currently I would 
go with:

- Base Module: RELAX NG minus the 'ambiguous' paths, offering little more 
than DTDs

- Simple Types Module: Adding the ability to define simple types constraints 
to the Base Module in much the same way that Relax NG does today.  I would 
make it more built in though, rather than using the param feature.  i.e. 
instead of:

<element name="email">
  <data type="string">
    <param name="maxLength">127</param>
  </data>
</element>

do:

<element name="email">
  <data type="string">
    <maxLength>127</maxLength>
  </data>
</element>

or even:

<element name="email">
  <data type="string" maxLength="127">
  </data>
</element>

i.e. the additional module adds extra keywords into the Base Modules 
vocabulary.  But that's details.

- 'Ambiguous' Paths Module: adds extensions for regular expression type 
grammar models rather than 'non-back tracking' grammars (LR1?).  Maybe this 
just removes some constraints on the Base Module.

- Complex Type Derivation Module: for class hierarchies

- Assertions/Xpath Module: i.e. Schematron and xs:assert functionality.

- Internal Referencing Module?: for ID and IDREFs etc.?

- Database Module: Maybe as simple as just xsi:nil!  Maybe some types for 
declaring keys etc.

Except for the Base Module they could just mix and match so that the data 
world could focus on Base Module + Simple Types Module + optionally Complex 
Type Derivation Module, and the document world could focus on Base Module + 
'Ambiguous' Paths Module + maybe Assertions/Xpath Module.

I think this would also help standards bodies as they could define the set 
of modules they want to use for a standard on the least power principle and 
avoid the feature creep you sometimes get when some clever clogs discovers a 
new piece of syntax!

Anyway, that's me rambled out.  I'll hand back to you pros...

Pete Cordell
Codalogic Ltd
Interface XML to C++ the easy way using XML C++
data binding to convert XSD schemas to C++ classes.
Visit http://codalogic.com/lmx/ for more info

Received on Thursday, 14 May 2009 09:40:22 UTC