Lists Home |
Date Index |
- From: james anderson <James.Anderson@mecomnet.de>
- To: xml-dev <email@example.com>
- Date: Fri, 07 Jan 2000 16:28:23 +0100
David Megginson wrote:
> james anderson <James.Anderson@mecomnet.de> 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
> 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:firstname.lastname@example.org
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:email@example.com the following message;
To subscribe to the digests, mailto:firstname.lastname@example.org the following message;
List coordinator, Henry Rzepa (mailto:email@example.com)