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

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: URIs and information typing



"Simon St.Laurent" <simonstl@simonstl.com> writes:

<snip reason="cut to the chase"/>

> For example, I might create a datatype defining a 'simonSKU' identified by 
> the URI http://simonstl.com/dt/simonSKU. At that location I'd have a RDDL 
> [5] document, which would provide a human-readable description as well as 
> links to a W3C XML Schema definition of the data type, perhaps a Perl 
> regular expression which can be used to check my SKU, a Java class which 
> can be used to check it, etc. There could also be some RDF around 
> describing relationships between this type and other types, or additional 
> properties of the type like creator, projects in which it's used, etc.
> 
> It would be my responsibility to make sure all of these things worked 
> consistently, of course (and maybe a testing resource in RDDL would be 
> cool), but applications could use my datatype processing as appropriate, 
> and humans could have a full set of documentation as well.

If I've understood you correctly, this changes both the syntax _and_
the architectural underpinning of type naming, and schema component
referencing in general.  I'm not sure either aspect of this move is a
good idea, for at least two reasons:

syntax:
1) If it ain't broke, don't fix it -- I'm no knee-jerk fan of
terseness, but requiring fully explicitly qualified names everywhere
you need to reference one component from another in a schema would be
a _substantial_ burden on schema authors _and_ schema readers.

architecture:
1) It would _require_ dereferencing namespace URIs, something we've
strenuously avoided in the design to date, for a range of reasons
including, but not limited to:
  1a) It would require connectivity or transparent offline-caching;
  1b) It would introduce network latency as a dominating factor in
      efficiency;
  1c) It removes existing flexibility about what is found at the end
      of namespace URIs -- it's _really_ not up to XML Schema to
      settle this question.

2) It would remove what many of us feel is an important flexibility in 
the design of XML Schema, namely that top-level element, attributes,
types and identity constraints are in separate 'symbol spaces', that
is, it's OK to have all of a top-level element, a top-level attribute
and a type with the same name, something your proposal would rule out.
   
ht
-- 
  Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh
          W3C Fellow 1999--2001, part-time member of W3C Team
     2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
	    Fax: (44) 131 650-4587, e-mail: ht@cogsci.ed.ac.uk
		     URL: http://www.ltg.ed.ac.uk/~ht/