RE: property value clarification

At 5:05 PM -0400 11/2/98, Babich, Alan wrote:
>There is no problem, even in this case. Even if the
>value is compound, the server knows the data types of
>all the simple values, and from the structure of the
>XML tags, it knows the structure of the values. (If you
>don't tell it anything about the datatypes of the
>simple values, and the server doesn't already know about
>the property, the server assumes String for the simple
>values.) So, the server has no trouble in principle in
>storing or retrieving the value, or in preserving the
>abstract value, or in querying it.
>
>Generally, the server doesn't need to know the
>semantics of properties other than the simple
>data types, and their hierarchical structure.
>With String as the default data type,
>and XML providing hierarchical structure
>for hierarchical values, the server can faithfully
>implement the abstract value, whether simple or compound,
>and whether predefined in an underlying schema, or
>seen for the first time in a PROPPATCH.

Now, since this labelled hierarchy of strings _is_ the basic data model for
XML, (and the canonical XML format that I recommended examining strips out
comments, etc), we seem to have come around to solution that I was
suggesting by a different route.

There's one thin you left out, though, which is attributes. Servers must
preserve attributes, if we want to apply data typing standards such as RDF,
since they are all based on the use of attributes.

At the very least, we need to preserve the xml:lang and namespace
attributes, to even support what we've already committed to.

>So, I am agreeing with you again. I would reword your
>sentence to be slightly stronger: "The server must either
>reject the property or implement its abstract value
>correctly."

And you also seem to be agreeing with my other major point, which is we
need to have a definition of _what_ implementing an abstract value
"correctly" actually is. We can't progate a standard that says the server
"must" do something whose meaning is undefined.

I come (at least partly) from a world (the Text Encoding Initiative) where
metadata is a complex sub-DTD of at least 30 element types. I'm aware of
worlds (in the library community) where metadata encompasses literally
hundreds of potential fields that are hierarchically organized and have
complex and significant ordering relationships among each other.

From that perspective the desire to store 10002323 in 4 bytes of binary is
an interesting special case optimization. I realize the for other systems
it is a critical issue. But I don't see any reason that we can't pretty
easily handle both.

I do see the representational power of XML as being useful in some
meta-data situations, and given that I advocate it.

I also see the potential advantages that simpler schemas could gain by
limiting that model. And if we _do_ limit it, let's say how.

I propose that any server that does not have a schema for a namespace
qualified element of an XML document should preserve all the information
that would be available by converting that element to canonical form as
defined on James Clark's web page, and that we contact him for permission
to include that prose. (Since he's committed to a variety of standards
work, I expect that he'll oblige us, and save us the trouble of rewriting
it).

>Greg Stein wrote:
>"My initial question which created this thread was more about how far
>the
>property value extended within the XML framework which carries it,
>versus what the semantic nature of those properties are."
>
>The right order to consider the questions is (1) what is the
>property model or models we want to support, and (2) what
>makes sense to express property values in XML. With the
>property model in mind, it is clear that XML attributes
>are best used for decorations of literal values, e.g.,
>data type and language, and not for the abstract value
>itself.

This is one, controversial, view in the XML community. The same issue has
been controversial in the SGML community as well, for more than a decade.
In any case, unless we are going to pick one schema notation (not currently
possible), servers must preserve attributes so that clients can add schema
declarations to their data. Once a client is allowed to add the attributes,
and get them back again, the question of whether the attribute is a
"decoration" or an "abstract value" becomes a religious one with no effects
on the protocol. So we're back at the same place again.

   -- David
_________________________________________
David Durand              dgd@cs.bu.edu  \  david@dynamicDiagrams.com
Boston University Computer Science        \  Sr. Analyst
http://www.cs.bu.edu/students/grads/dgd/   \  Dynamic Diagrams
--------------------------------------------\  http://www.dynamicDiagrams.com/
MAPA: mapping for the WWW                    \__________________________

Received on Tuesday, 3 November 1998 08:59:02 UTC