Re: Namespace prefixes optional?
David Megginson wrote: > > james anderson <James.Anderson@m...> writes: > > > a. How does one do attribute defaulting in situations where the > > namespaces matter. That is, in situations where one can't just treat > > the document as if it were "xml-1.0-plain". > > Declare the attribute -- it is irrelevant whether Namespaces matter or > not. Or is your question "how can you preserve an attribute default > after a round trip through a processor that doesn't preserve the > original Namespace prefixes"? > No, that is not the issue. Namespaces matter only when an identity based on prefixes would not have been sufficient. Otherwise, except for the ability to bind xmlns="<uri>", the namespaces are redundant. In these cases where the prefixes are not identical, that is, where the namespaces matter, xml-1.0+namspaces, as ratified, doesn't work. > > > b. How can one uphold the constraint, that the set of valid > > "xml-1.0+namespaces" documents is identical with the set of valid > > "xml-1.0-plain" documents. Mr Waldin's question is one case in point. > > I'm not sure what you mean. > > If you're using "valid" the same way as the XML 1.0 spec does, then > the set of valid documents that happens to contain Namespace > declarations is a strict subset of the set of all valid XML 1.0 > documents; in other words, they are not identical. > > ... it is possible to have a document that is well-formed but > not valid XML 1.0, but still conforms to Namespaces, RDF, or XLink > (though not XHTML, which requires validity for strict conformance). Hmm, we now have the class of invalid, but namespace conformant documents. I recall hearing rather clear assertions to the contrary post-REC. Evidently the winds have changed on this question. > > > c. How does one specify an identity between a "name which is in no > > namespace" and a "name in a namespace as declared in a > > schema". Perhaps I'm just narrow-minded, but I sense a potential > > contradiction in this notion. > > This is an interesting problem, but what does it have to do with > Namespaces? All the Namespaces REC does is specify how to create > elements and attributes with two-part names, like you can with methods > or variables in Perl and Java (Namespace == package). Not entirely. The REC is the origin of the "names which are in no namespace" concept. > [discussion elided 'cause the questions have nothing to do with semantics.] > > > These for starters. They follow from the root problem, that the REC > > did ratify a complete model for the domain which it describes. It > > was most disappointing to observe the extent to which the appendix > > was disavowed. Were one to have taken something of that sort > > seriously, such issues may have come to light, rather than being > > "left to the application". > > For "left to the application" substitute "left to higher-level specs". Where higher-level is in the plural I hesitate to distinguish between the two in the case of xml and namespaces. Remember Mr. Bray's frequent reference to the "difficult things" truism. I would not be surprised that they both reduce to naming. > People were already preparing to start work on an XML Schema spec, and > it didn't make sense for Namespaces to do a half-assed job trying to > do part of schema's work for it and then leaving the schema people > with all kinds of constraints. I would have thought that names and schemas should have been separable. They have been in other domains. > > Good specifications are layered, with each one accomplishing a single, > well defined task. The Namespaces spec set out to answer the question > "How do you represent a two-part name in XML 1.0 syntax?", not "How do > you solve every possible problem with inheritance, identity, and > validation in XML?" > With which, with the exceptions of "identity" my questions remain, unconcerned... xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To unsubscribe, mailto:majordomo@i... the following message; unsubscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
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