This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
We claim in Part 2 that e.g. http://www.w3.org/2001/XMLSchema#int is the name for the int type, but there is no anchor of that name in the namespace document for our namespace URI. Perhaps we should fix this?
Discussed during 2005-09-09 WG telecon. See http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2005Sep/att-0073/2005-09- 09telcon.html#item08
Instruct editors to update the RDDL document so that the links resolve. The WG further instructs the editors to use their own discretion in providing wording in the RDDL document.
Illustration of where this is going sent to WG 2005-12-16: http://www.w3.org/XML/Group/2005/12/XMLSchema.html
Since resolving this issue will not change the conformance requirements for data or software, I'm marking this item 'editorial'.
Sandy Gao reviewed version of 10 January (http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2006Jan/0090). WG discussed this on 20 January 2006 (http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2006Jan/0098), gave the following instructions to the editor: 2 add the totally ordered duration types 3 mark anyAtomicType as subject to ratification 4 string.preserve should point to string.whiteSpace 5 make the facets in use for 1.1 items point to the spec (rather than the XML source declarations) 6 correct the links that currently don't resolve
All but one of WG requests now addressed (other one will be fixed by rebuilding once Bug 3840 is fixed. Produced new version of http://www.w3.org/XML/Group/2005/12/XMLSchema.html for editors' consideration. This document is produced by running the stylesheet at http://www.w3.org/2001/XMLSchema_namespace.xsl on an up-to-date XMLSchema.xsd, and depends on it having primitives.nxsd and derived.nxsd as siblings.
ACTION 2006-01-20.2: editors to prepare a revised proposal for 1974 for consideration on 27 January. Note 1974 is making sure published URIs for datatypes parts actually resolve.
While we are resolving this issue and fiddling about with namespace documents, it would be a good idea to turn an eye to the namespace document for the 'shadow' namespace for datatypes, http://www.w3.org/2001/XMLSchema-datatypes -- currently it is kitted out with a schema document which the WG believes is not a suitable namespace document. (The reasons we assign for its inadequacy may or may not be consistent -- we didn't have time this morning to explore them at any length. We just wanted to note that the datatypes namespace document needs revision. So noted.)
I withdraw both the precise formulation of problem in the Description of this issue, and the proposed resolution given in e.g. https://www.w3.org/Bugs/Public/show_bug.cgi?id=1974#c6 and the candidate namespace document referenced there. Short reason? They both assume that (X)HTML anchors are the right way to make it the case that e.g. http://www.w3.org/2001/XMLSchema#int "uniquely address[es]" the int datatype. But by definition such anchors would cause that URI to address an (X)HTML element. Elements are not datatypes. See thread starting at http://lists.w3.org/Archives/Public/www-tag/2012Feb/0039.html for a more detailed analysis. Proposed new Description: We claim in Part 2 that e.g. http://www.w3.org/2001/XMLSchema#int is the name for the int type, but nothing reachable today from http://www.w3.org/2001/XMLSchema makes this the case. We should fix this. I'll try to propose an approach for a resolution soon.
If a statement from the owner of a namespace NS that a particular name N in that namespace names a particular thing T does not suffice to make it the case that name N in namespace NS names thing T, then what kind of action can make it the case? Perhaps I have always misunderstood the nature of the problem leading to this bug report: I thought the problem was that people who wanted to know what a given URI denotes should be able to dereference that URI and find some human-readable (and perhaps also some machine-processable) information that helps them understand the denotation of the URI, and our namespace document doesn't do an acceptable job of helping either humans or machines understand the URIs which denote the built-in datatypes and the other things in the XSD namespace. But that understanding centers on the quality of the human- and machine-readable documentation for those URIs, not on a conflation of datatypes with HTML elements. If the plan described in comment 6 is no good because HTML elements are not datatypes, then how is any namespace owner to document the namespace? The only URIs whose meaning can conveniently be explained by means of a human-readable HTML element would then appear to be URIs denoting elements in HTML documents -- an interesting but not exhaustive subclass of URIs. One commonly held view is that what is delivered when a URI is dereferenced is a representation of the resource, not necessarily the resource itself. On that view, the idea of providing an HTML document describing the resource denoted (here, an HTML element describing the datatype denoted by a URI) is both coherent and desirable, and does not give rise to the erroneous conclusion that the resource denoted by the URI is an HTML document or element. Can anyone explain in words of one syllable what is wrong with that commonly held view that makes it necessary to change course on this issue?
> If a statement from the owner of a namespace NS that a particular name N in > that namespace names a particular thing T does not suffice to make it the case > that name N in namespace NS names thing T, then what kind of action can > make it the case? In the absence of anything else, yes, it probably suffices---I don't think I said anything to the contrary. The particular problem I failed to take account of does not arise from anything we might write in English (or any other natural language) in the namespace document. It arises from the proposal I made to add anchors (that is, id="...") for each datatype to (the (X)HTML version of) that document. Why is that a problem? Because the (X)HTML media type registrations say that in such a case, the corresponding URI _identifies an element_. And that contradicts what we say in the spec, which is that it identifies a datatype. > If the plan described in comment 6 is no good because HTML elements are not > datatypes, then how is any namespace owner to document the namespace? The only > URIs whose meaning can conveniently be explained by means of a human-readable > HTML element would then appear to be URIs denoting elements in HTML documents > -- an interesting but not exhaustive subclass of URIs. There are two ways to cut the gordian knot: 1) Don't say that NS#name identifies a datatype, say it identifies definitions of datatypes. Then my proposal would have been good on _two_ counts, back when I made it: a) It would have provided anchors in the (X)HTML which identified things which _did_ define the datatypes, albeit briefly; b) It would have made the content negotiated alternatives token-consistent, in that the 2001-vintage XMLSchema.xsd has anchors already, and they identify definitions too. 2) Make the NS#name actually identify a datatype, using the only technology we have available to take URIs out of the web and into the world, namely RDF. (1) is almost certainly closed to us: if we tried to change the relevant bit of Datatypes now, the whole RDF community would push back, since they have been taking us at our word, and using the advertised URIs to indentify datatypes since 2001. Note that (1b) would also no longer be true, because the 1.1 schema document for schema documents no longer contains the relevant anchors. I'll shortly make a proposal which would implement (2), while still also providing some comfort for human beings as well. Regarding your final question, about the alleged incompatibility between descriptions and representations: that is at the heart of an ongoing and extremely contentious debate. It's known as the httpRange-14 problem, and the TAG is currently gearing up for a major effort to find a position which will attract consensus on both the theoretical and practical fronts. I don't hold out much hope for a resolution here in the short term, hence my interest in finding a solution which doesn't fall foul of any of the known challenges in this space. Please bear with me, until I can actually frame my new proposal. I'm sorry to be doing this in such an extended fashion, both in time and in volume of prose, but we are for better or worse in the position of those pioneers identifiable as such by the arrows in our chests, and I'm trying to be sure I get every one of them out.
Given that the architectural questions around fragment ids and namespace documents are unsettled, my recommendation for the time being is to proceed as follows: 1) In the schema document for schema documents which will reside at 2001/XMLSchema.xsd once 1.1 is approved, add back, near the top, a slightly corrected version of the prose which is present in the 1.0 version (and which appears in the spec. itself in appendix C.1): ----------------------------- The W3C XML Schema specification says that all the built-in datatypes defined there (both primitive and derived) can be uniquely addressed via a URI constructed as follows: 1) the base URI is the URI of the XML Schema namespace 2) the fragment identifier is the name of the datatype For example, to address the int datatype, the URI is: http://www.w3.org/2001/XMLSchema#int Additionally, each facet can be uniquely addressed via a URI constructed as follows: 1) the base URI is the URI of the XML Schema namespace 2) the fragment identifier is the name of the facet For example, to address the maxInclusive facet, the URI is: http://www.w3.org/2001/XMLSchema#maxInclusive Additionally, each facet usage in a built-in datatype definition can be uniquely addressed via a URI constructed as follows: 1) the base URI is the URI of the XML Schema namespace 2) the fragment identifier is the name of the datatype, followed by a period (".") followed by the name of the facet For example, to address the usage of the maxInclusive facet in the definition of int, the URI is: http://www.w3.org/2001/XMLSchema#int.maxInclusive ----------------------------- 2) Update the existing namespace document (2001/XMLSchema.html) to include essentially the same text. At some future date, it may be appropriate to include RDFa in one or both of those documents, and/or to provide a separate rdf+xml or Turtle or N3 document, which provide an RDF grounding for the 'names' of all datatypes, facets and facet usages, i.e. along the lines of <http://www.w3.org/2001/XMLSchema#int> rdf:type rdfs:Datatype . but it is not in my view necessary, or even appropriate, to do this yet.
From the telcon: MSM: HT and I have discussed, starting with lists of requirements, but since HT has decided we need a change of direction. Note that we are waiting on HT for further clarification.
DE and MSM discussed comment 12 and items 1 and 2 are worthy of inclusion. Leaving as "needs drafting", awaiting the changes for review. Further comments from HT expressed concern over http://www.w3.org/2001/XMLSchema.xsd and http://www.w3.org/2001/XMLSchema.html MSM notes that the 1.1 spec references the following: - http://www.w3.org/2009/XMLSchema/XMLSchema.xsd (mutable) - http://www.w3.org/2012/04/XMLSchema.xsd (immuntable) MSM also notes the following changes that should be made: - we should update /2009/XMLSchema/XMLSchema.xsd to say version="1.1" - we should make a new dated version including that change, at /2012/09 (or whatever) - optionally we should add a documentation element to /2001/XMLSchema.xsd saying "this is the normative schema for XSD 1.0; the normative schema for XSD 1.1 schema documents is over there -->"
Created attachment 1543 [details] নতুন প্রজন্মের প্রত্যয়দীপ্ত প্রতিবাদের আওয়াজ Have a nice day.
Created attachment 1544 [details] নতুন প্রজন্মের প্রত্যয়দীপ্ত প্রতিবাদের আওয়াজ
Created attachment 1545 [details] নতুন প্রজন্মের প্রত্যয়দীপ্ত প্রতিবাদের আওয়াজ