Re: use of the XML Schema & DTD to formalize specs

comments inlined

On Thursday, April 18, 2002, at 07:49 , Kirill Gavrylyuk wrote:

> And my second answer:)
>
> I have 3 points
> 1. I don't want us to invent bicycle. The problem of formalizing specs
> is as old as the specs writing themselves. ASML [1] is just one of
> examples. And there are already tools that create models from the
> formalized specs and verifies them. I can give a short
> presentation-overview of existing techniques on the f2f if there is an
> interest. If we want to invest in this - let's do research of what
> exists publicly already.
>
[dd] This is what I will propose to the QA WG - that a review be made of 
publically and non-proprietary tools. Let's decide on the presentation 
issue just before the f2F.

> 2. I'm strongly against using DTDs or XML Schemas for specs
> formalization. XML Schemas are bad even to use as a type system. Their
> intent is lexical validation only. While you can hack them adding your
> own instructions - you will end up investing XSLT or Xquery. I
> experimented using XSLT for validation of XML documents - fun, but not
> practical. XQuery might be better. But it is still not what these
> languages were designed for. Sure, you can construct XML based ASML or
> something alike - but why? It already exists in non-markup form.
>
[dd] First, I am strongly for using DTDs or schemas (in W3C Schema or 
RelaxNG form) just because it is.
1. A good usecase of existing W3C technologies
2. It gives unsurpassed control of content and (lexical) validation
3. It can be used in a larger framework, which would consist of 
authoring tools, validators (of all W3C-relevant requirements and 
limitations), stylesheets to generate both normative XHTML version but 
also machine readable representations of it (as well as simplifying in 
generating graphical interfaces to appropriate specs and so forth).

> 3. You can not create formalized spec from the scratch. You need to have
> an english version before. We need to understand that it's a much
> heavier task for the spec authors. So we need to carefully asses the
> benefits we get from doing so.
>
[dd] you could, ideally, if you invent the entire vocabulary together 
with assertions. Of course, having a version in english to begin with 
helps greatly.

> And one question:
> What is our goal?
> - If the goal is to create a spec validator that would analyze the specs
> for vague areas and unintended behaviors then - I agree, it's an
> interesting direction to invest. But not in v1 of our deliverables. I
> don't think it was in the initial charter of the QA WG.
>
[dd] This is one of the goals

> - If the goal is to improve testability of the specification - then why
> not just create XML version of the specs and markup the testable
> assertions, conformance clause, etc.? Having a schema that would
> restrict the  W3C spec XML template is an easy and useful task and
> inline with the scope of Spec Guidelines.
>
[dd] This is another point, and the point here is that the specs be in 
XML to begin with, not constructed after the fact.

There are a series of other intented points that I will take up in this 
telcon.
>
>
>
>
> -----Original Message-----
> From: Dimitris Dimitriadis [mailto:dimitris@ontologicon.com]
> Sent: Thursday, April 18, 2002 10:17 AM
> To: Kirill Gavrylyuk
> Subject: Re: Telcin discussion items
>
>
> Thanks for the links
>
> I've looked very briefly on AsmL before, I'll look into it some more.
>
> I'm not sure I share your views below; for 2 there is no difficulty in
> principle to come up with a good schema for spec guidelines requirements
>
> (among other things), but even more importantly more advanced features,
> like testable assertions, set containment of methods, hierarchy, and so
> forth.
>
> For 1, we've been using the XML DTD in DOM to "type" our spec before
> generating the XHTML version that is published.  Currently one can only
> see strictly lexical validation, but I ascribe the semi-semantical
> functionality to the surrounding framework and not only the schema
> language itself.
>
> If your email was meant for the list, feel free to forward it and this
> one to the qa wg list
>
> rest of comments inlined
>
>
> On Thursday, April 18, 2002, at 06:10 , Kirill Gavrylyuk wrote:
>
>> For the 2. - this is not done yet, but would be a useful feature. If
>> we have a standard schema for xml versions of all the specs that
>> reflects the spec guidelines requirements (having elements for
>> assertions with unique ID, elements for sections, paragraphs and
>> Conformance clause), extracting testable assertions and binding
>> testsuites to the specs would be easier.
>>
>> For 1, here are the facts:
>> The scope of XML Schema (and DTD) is lexical validation. They are not
>> even type systems strictly speaking. You can not describe semantic
>> constraints using schema or DTD. WGs like XML Protocol, XML Schema,
>> Web Services Design Language, XQuery use schema to describe the types
>> of language constructions. But not the behavior. Not every XML
>> language can be described with XSD or any other schema either. Take
>> XSLT for example.
>>
> [dd] Again, I don't share the view that behaviour simply cannot be
> represented. I'm willing to commit resources to investigate this and
> would certainly welcome commitment of Microsoft (and other's) time.
>
>> Formalizing specifications
>> There are number of efforts in direction of formalizing
>> specifications, in order to automate analysis, generate testcases. No
>> need to invent anything new. You can look at the recent work on model
>> based testing, Abstract State Machine Language [1] for example. I'm
>> sure there are a lot of other projects in this direction.
>>
> [dd] As you mention, it's one of many frameworks. I don't have the most
> current situation review, so I'll come back.
>
>> The benefit of using ASML or other techniques to formalize
>> specification is that
>> - you can compile and execute the spec and verify for conflicts, vague
>
>> areas and unintended behaviors.
>> - you can automatically generate models and test cases from them. I
>> saw it working in real projects.
>>
>> The drawback is that
>> - this task is heavy, sometimes harder then to create an actual
>> implementation.
>> - the formalized spec is less human-readable then XML Schema
>> - you cannot do this without having an initial spec written in
>> english.
>>
> [dd] The formalized spec need not necessarily be human readable, but can
>
> be used for editor-driven authoring.
>
>> The bottom line - providing list of testable assertions as an addendum
>> to the english version of the spec is the best WG's bet from the
>> cost/benefit point of view. Leave the rest to vendors, since they have
>
>> to create specs for their products based on the W3C spec too.
>>
> [dd] There is something more to writing specifications that strict
> cost/benefit analysis. In any case, I look forward to continue the
> discussion we've started here, but especially the discussion in the Qa
> (and other) WGs
>
>> [1] http://research.microsoft.com/foundations/asml/
>>
>> -----Original Message-----
>> From: Dimitris Dimitriadis [mailto:dimitris@ontologicon.com]
>> Sent: Thursday, April 18, 2002 5:54 AM
>> To: Kirill Gavrylyuk
>> Subject: Re: Telcin discussion items
>>
>>
>> I want to investigate 1. Why is it not possible to use a schema to
>> write
>>
>> a specification?
>>
>> I take 2 to be trivially true, at least in so far as the
>> specifications are valid XHMTL.
>>
>> /Dimitris
>>
>> On Thursday, April 18, 2002, at 02:16 , Kirill Gavrylyuk wrote:
>>
>>> Hi, Dimitris!
>>> Wanted to double check  - is your intent to
>>> 1. use schemas as language to write specifications or
>>> 2. to use the same schema for the XHTML version of all the W3C specs.
>>>
>>> I agree with 2, I'm opposed to 1 since it's not possible.
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: Dimitris Dimitriadis [mailto:dimitris@ontologicon.com]
>>> Sent: Wednesday, April 17, 2002 3:50 PM
>>> To: www-qa-wg@w3.org
>>> Subject: Telcin discussion items
>>>
>>>
>>> QA WG,
>>>
>>> below please find the items for discussion I propose for my part of
>>> the introduction to the Specification guidelines document:
>>>
>>> 1. motivation for using advanced schemata for specificaiton authoring
>>> 2. benefits (better control over information extraction, normative
>>> specification generation as well as automated test assertions) 3.
>>> Look
>>
>>> at what is being done in Wg's 4. Rules for spec authoring similar to
>>> pub rules that exist today
>>>
>>> I hope to have discussion on:
>>> 1. added effort on behalf of WG's
>>> 2. how to generate the normative schema(ta) to use when authoring a
>>> specification 3. generalized framework for generating normative
>>> (html)
>>
>>> versions of specifications
>>>
>>> /Dimitris
>>>
>>
>

Received on Thursday, 18 April 2002 14:24:01 UTC