[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: URIs and information typing
Henry S. Thompson wrote: > > 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. to reduce the burden explicitly use qname as a shorthand for the full URI reference, the syntax remains exactly the same ... (note: consider defining the attribute "name" as an ID). > > 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: why? what would be different than the current system -- the qname could remain the same. Am I missing something? > 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. Just because a URI reference is present doesn't mean it needs to be dereferenced. Indeed I imagine XML Schema processors would have builtin knowledge of the meaning of the simple datatypes despite what their URI references might resolve to. This is the crux of my point, an XML Schema or RDF application might use a QName, an XLink application might use a URI reference but they all might interoperate because there would be an unambiguous mapping of QName <-> URI reference, and this would be entirely independent of resolution. Of course resolution might yield additional information and like namespace URIs this would be allowed but not mandated. > > 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. > I don't immediately see the utility of this. From perhaps a simplistic perspective ought a name name one thing regardless of the naming syntax? The idea of a programming language that allows you to use the same name for a function and a variable comes to mind. Flexible perhaps, but at what cost in readability? -Jonathan
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|