[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Re: validating hairy data models (was Attribute

• To: <xml-dev@l...>
• Subject: Re: Re: validating hairy data models (was Attribute order)
• From: "Rick Jelliffe" <ricko@a...>
• Date: Tue, 11 Dec 2001 08:45:40 +1100
• References: <3549BAFD79A7D411A1CF00508B62B5BC0124B92E@e...> <p04330100b83a7452045b@[192.168.254.4]> <03fb01c181a4$d1a5acc0$6800000a@b...> <002b01c181aa$00fbcd10$9ac6c0d8@A...> <047001c181b1$c144f180$6800000a@b...>

 From: "David Brownell" <david-b@p...>
 
> From: "Rick Jelliffe" <ricko@a...>
> >     Executable specs
> > for standards (such as IDL) are quite a lot better, but most
> > specs are not for interfaces.
> 
> Umm ... IDL isn't executable.  That's the point.  It covers
> interface syntax (like BNF) not behavior.  Behavior gets
> described in natural language.  I've made that same
> point about needing natural language to describe
> behavior.  Most people wouldn't know a formal semantic
> specification language if it bit them ... :)

Doh.  I should have said "machine-exercisable" I guess.
Meaning that there are formalisms that cannot be machine-checked
and formalisms that can (to some extent). Look at the bogus
formalism of the RDF specs' BNF: if they had been able to 
validate that life would have been much simpler. (I.e., given
some valid RDF, you can point out which bits in the productions
correspond to which bits in your data, but to actually parse
the data using those productions is not at all straightforward,
as the recent attempts to re-formulate the RDF-in-XML
syntax have shown.)

> That model of standards doesn't work so well with W3C since
> essential parts of the "original intent" are hidden behind closed
> doors. 

Yes. 

> More to the point:  In your scenario, that community has a clear
> responsibility to clearly describe that original intent.  That's what
> the specification is for, and what specification errata address.

Yes. Actually, it works both ways: the community needs to
articulate the gaps in the formal spec, and newcomers into
the community need to err on the side of agreeing with the
community rather that making their own interpretation of 
the gaps.

Of course, what the community is or should be is another
matter. I guess I have been using it as a code word for
the inventors, maintainers and implementors, rather than
users.

> To some extent, additional specifications (XML Infoset in the
> case of attributes) can augment the base specification.

I think there should always be a quasi-judicial process available to 
help sort out ambiguities in specs. That is why errata documents
are useful.

Cheers
Rick Jelliffe

• Follow-Ups:
  • Re: Re: validating hairy data models (was Attribute order)
    • From: Dave Beckett <dave.beckett@b...>

• References:
  • RE: Re: validating hairy data models (was Attribute order)
    • From: Jeff Lowery <jlowery@s...>
  • RE: Re: validating hairy data models (was Attribute order)
    • From: Elliotte Rusty Harold <elharo@m...>
  • Re: Re: validating hairy data models (was Attribute order)
    • From: David Brownell <david-b@p...>
  • Re: Re: validating hairy data models (was Attribute order)
    • From: "Rick Jelliffe" <ricko@a...>
  • Re: Re: validating hairy data models (was Attribute order)
    • From: David Brownell <david-b@p...>

• Prev by Date: RE: Where have the element types gone?
• Next by Date: RE: Re: validating hairy data models (was Attribute order)
• Previous by thread: Re: Re: validating hairy data models (was Attribute order)
• Next by thread: Re: Re: validating hairy data models (was Attribute order)
• Index(es):
  • Date
  • Thread