[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- From: Ronald Bourret <firstname.lastname@example.org>
- To: email@example.com
- Date: Tue, 31 Jul 2001 16:55:22 -0700
Richard Tobin wrote:
> But that isn't what XML Schemas does. Rather it allows a schema for
> some namespace to include declarations for elements in no namespace,
> provided they are contained within an element from the namespace.
> That is, it provides an interpretation of elements in no namespace as
> being *scoped by* their containing, namespaced element. It doesn't
> put them in the namespace, at least not literally.
> But I'm sure you know all that.
Actually, I didn't. I've dealt with the schema data model, but not the
surface syntax. This feature doesn't show up in the data model as far as
I can tell. Looks like I misunderstood the earlier posts.
> >is not in scope, they're not in any namespace. My point is that XML
> >Schemas did to namespace processing what DTDs did to attributes in
> >document processing.
> Do you mean that it's only because of DTDs that we can consider
> attributes to be scoped by their elements?
No. I meant that because attribute defaults are declared in DTDs, what
you get when you parse a document can vary depending on whether a DTD is
> >You get different results depending on whether a
> >schema is present. I can't see this as a good thing.
> What is the "different result" you get? It doesn't change the
> namespace of the elements. It just does some work - what you might
> call context-sensitive type assignment - that otherwise would have to
> be done by the application.
According to my misinterpretation of earlier messages, the different
result was the universal name of the unqualified elements. I thought
these would have a non-null URI if a schema was present and an
(effectively) null URI if the a schema was not present. I was wrong.
> Incidentally, this use of unqualified local elements is very natural
> for some applications. Consider structures in a traditional
> programming language like C, and represent the fields of the structure
> by subelements. Do you expect to have to qualify the field names?
> No, they are scoped by the type of structure containing them.
I understand the use case, but I'm not convinced I like the solution,
since the resulting data is non-portable. That is, if you remove an
unqualified child element from its parent and transfer it to another
file, you've lost the context and no longer know how to interpret the
data. This is not the case with elements in namespaces.
(You can argue that the same problem exists with unqualified attributes
and you would be correct. Probably another one of the reasons that most
minimal forms of XML don't include attributes. As an aside that will no
doubt cause another long discussion, except for the fact that attributes
are typed, is there anything you can do with an attribute that you can't
do with a PCDATA-only child element?)
In any case, it appears that the major beneficiary of this feature is
software that automatically generates XML from objects, since it no
longer has to worry about uniqueness of property names across elements.
Given that the cost of this feature is the lack of data portability, I'm
not convinced it's worth it.