Another look at namespaces

[Simon St.Laurent]

At 04:46 PM 9/20/99 +0800, James Tauber wrote:
>> Meaning one grammar + vocabulary -> language? Where the quantities are all
>> one?
>
>You don't actually need the "vocabulary". The alphabet of a formal language
>is part of the grammar.

In XML-based languages that rely on DTDs or schemas, yes.  But in all
formal languages?  Seems that it wouldn't be hard to create a formal
language that had classes of vocabulary (like noun, verb, adjective) and
fit them into patterns (subject[noun]-verb[verb]-object[noun]) that were
separate.  Hopefully, it wouldn't look like English, but it does seem like
a practical solution to a lot of problems.

>> I think in practice you may find multiple grammars used within the
>> same language, even a formal one
>
>Ahh. But now you are using "language" in a way other than "the set of
>utterances generated by the grammar" right? Unless you mean that sometimes
>the same syntactic rules can be expressed two different ways eg
>
>a+
>
>versus
>
>a a*

It's that, but it's also worse.  Suppose you have a nice modular DTD that
expresses most of the vocabulary a user will need to create documents of a
certain type, but has ANY sections so that users can organize it any way
they like.  Users build sets of DTDs to see what exactly it is they're
getting or producing, but all of the possibilities are actually open.  Is
the language described by the 'master' DTD, which doesn't get you very far?
 Or is the language described by the particular DTDs?  Or do we measure
interoperability?  A 'master DTD' containing all possibilities will quickly
grow obese.

Then there's the simpler case of well-formed documents, for which we can
_derive_ grammars, but can't make definitive statements above the level of
XML 1.0 conformance.

>> and (yuck for some) not just subsets (once you let ANY in the door, it all
>goes).  Trying to keep it all
>> exclusively singular seems to be a common dream throughout computing, but
>> one I hope we can leave behind more and more over time.
>
>Let me stress again, I am not saying you can always have a single grammar
>for a particular "language". I am saying that you can have a single grammar
>for a particular "formal language in the sense used by Paul".

I think 'formal language' in that sense is not especially useful except for
limited situations, and should probably be reserved for the few cases where
XML development is limited to representations of older legacy systems that
relied on formal languages based on that sense.  XML itself, it seems, can
do better than that.

>> I think we might do well to ponder whether XML is really about creating
>> formal languages or for encoding information already represented in
>natural
>> languages.  If it's the latter, the results might be more interesting.
>
>Why can't it be both? Isn't that the whole point of write schemata
>(including DTDs)? Isn't it about formalising the encoding of this
>information.

It depends on what kind of 'formalizing' you want to do.  In many cases,
I'd suggest that we focus on 'relaxing', producing more flexible models
that aren't so concerned about locking everything down into a single
grammar and a single vocabulary.  It requires a change of mindset.  

Why is it that only one validating Java parser allows the application to
continue after a validity constraint (not a well-formedness constraint) has
been violated?   I suspect it's because a lot of folks are taking the
'formal grammar' of DTDs more seriously than the XML 1.0 spec itself
does... [See David Brownell's report on XML.com at
http://www.xml.com/pub/1999/09/conformance/summary.html]

I don't think we're incompatibly far apart, I just would like folks to look
at 'formal languages' a bit more closely and a bit more critically.  Rick
Jelliffe's made excellent arguments in other postings on this thread, for
example, regarding the ways formal languages can obscure as well as
illuminate. 

Right now, I think we need to contemplate whether 'formal grammars'
sufficiently distinguish 'languages' in practice before putting extra work
for programmers and authors (namespaces) on every formal grammar that comes
our way.

Simon St.Laurent
XML: A Primer (2nd Ed - September)
Building XML Applications
Inside XML DTDs: Scientific and Technical
Sharing Bandwidth / Cookies
http://www.simonstl.com

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)