OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   RE: [xml-dev] Schema Namespace name, schemaLocation, and Schema V ersi

[ Lists Home | Date Index | Thread Index ]

Regardless of where you start from, versioning spans both the syntactic and
the semantic. I could have two syntactically identical schemas, and could
choose to assign them different versions (and, if included in the namespace
name, different namespaces) if the intended semantic interpretation were to
change. The trouble with having a richer language for describing legal
structures and types is that Schema blurs the distinction between syntactic
and semantic, even if it cannot capture/enforce all of semantics. 

 -----Original Message-----
From: 	Thomas B. Passin [mailto:tpassin@comcast.net] 
Sent:	Saturday, July 20, 2002 11:10 AM
To:	xml-dev@lists.xml.org
Subject:	Re: [xml-dev] Schema Namespace name, schemaLocation, and
Schema V   ersioning

[Rick Jelliffe]

From: "David Carlisle" <davidc@nag.co.uk>
> Take a look at the namespace spec.
> Namespaces are not about semantics they are about names.

Well, they really are about modularity which cannot really get too far from
ideas of semantics.

[Tom P]
From a strict point of view, the modularity is on a syntactical level,
though, not a semantic level.  If I specify an ex:address element rather
than an xy:address element, I am specifying the __structure__ of the address
element and its children.  This lets me know how to process its structure.

It is inviting to assume that any semantics that originally attached to the
ex:address element should come along with my use of it, but the Recs say
nothing about that.  Since neither XML Schema, DTDs, nor RELAX NG specify
semantics, there is no standard mechanized way to specify or control the
semantics of a document design.

Suppose that we import an ex:person element and it has an attribute "id".
The original schema had an annotation saying that the id is intended to be a
(US) social security number.  But after we have started to use our schema,
we decide to that it needs to allow either an SS number or the person's
driver license number (in many US states you can use state-assigned number
in place of your SS number for a driver's license).  Should we stop using
ex:person?  This is a semantic issue, not a structural or syntactical one
(and gets into Len's pet area of contracts).

Suppose that we decide to continue to use the id attribute even though its
meaning has changed a bit.  The syntactic consequence is that ex:person will
still work fine with my software.  If we decide that we should have another
attribute, called "newid", that would be a semantic decision and we could
work out the syntactical consequences (perhaps an extension of ex:person if
it can be extended).

Of course, we may consider the syntactic consequences as we decide whether
the semantic issues are strong enough to warrant a change in the structures.
Those practical tradeoffs are where the lines get blurred.  But I think it
is useful to start from a strict position - syntax is syntax, not
semantics - and only deviate for good reasons.  The Recs - XML, Namespaces,
Schema - only deal with syntax.  The semantic issues are an overlay.


Tom P

The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
initiative of OASIS <http://www.oasis-open.org>

The list archives are at http://lists.xml.org/archives/xml-dev/

To subscribe or unsubscribe from this list use the subscription
manager: <http://lists.xml.org/ob/adm.pl>


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS