XML and its Uses

How do other things layer on to xml?

I mean like dtd, wsdl, soap, etc.?

Thanks.

-g

Geoff

Geoff wrote:
> How do other things layer on to xml?
> I mean like dtd, wsdl, soap, etc.?

Could you clarify what question you're asking?

DTDs are part of the XML spec. They're one way of defining a document
type. Schemas are another, more recent and more powerful, solution.

WSDL and SOAP are applications of XML -- document types, or languages if
you prefer, implemented in XML.

--
() ASCII Ribbon Campaign | Joe Kesselman
/\ Stamp out HTML e-mail! | System architexture and kinetic poetry

> Could you clarify what question you're asking?

More specifically, for example, if I have an xml spec that says:

</lastname>smith</lastname>

.. . . and continue on expressing everything about a person, first name, age,
height, address, etc. What does a dtd do or what additional info does it
add to that? Same question for schemas.

Wsdl has to do with web services but besides an xml file, etc. one might see
a wsdl file as well, what info does a wsdl file add to the above?

Thanks.

-g

Geoff wrote:
> . . . and continue on expressing everything about a person, first name, age,
> height, address, etc. What does a dtd do or what additional info does it
> add to that? Same question for schemas.

The DTD, or schema, provides a formal description of what the proper
structure is for that file, what values are acceptable, what default
values are.... Part documentation, part error-checking (since validation
will check to make sure the document matches this description). Schema
can also specify data types and value ranges, to further constrain this.

(DTDs are arguably obsolete since -- unlike schemas -- they don't
understand how to work with XML Namespaces. Some folks will challange
that assertion.)

> Wsdl has to do with web services but besides an xml file, etc. one might see
> a wsdl file as well, what info does a wsdl file add to the above?

Additional document structure to describe what service you're talking to
and what you want it to do for you.

(BTW, you should try to think in terms of documents, not files. A lot of
XML never actually gets stored in a file, existing only on the network
and in memory buffers.)


--
() ASCII Ribbon Campaign | Joe Kesselman
/\ Stamp out HTML e-mail! | System architexture and kinetic poetry

Geoff wrote:
>> Could you clarify what question you're asking?
>
> More specifically, for example, if I have an xml spec that says:
>
> </lastname>smith</lastname>
>
> ...and continue on expressing everything about a person, first name, age,
> height, address, etc. What does a dtd do or what additional info does it
> add to that?

Whatever you specify. A DTD is a description of the names for your
element types, and how they fit together. You can write it, so you
get to decide what information you want to describe, and how.

Alternatively, you use one someone else has written.

> Same question for schemas.

Ditto, except that schemas allow much tighter specification of the
types of data you want to allow (eg surname must be alphabetic; or
date must be numeric; or whatever), which is useful for data-based
applications, not so useful for normal text documents.

///Peter
--
XML FAQ: http://xml.silmaril.ie/

Joe Kesselman wrote:
> (DTDs are arguably obsolete since -- unlike schemas -- they don't
> understand how to work with XML Namespaces. Some folks will challange
> that assertion.)

It was very clear from this summer's Extreme Markup Conference that
DTDs are anything but obsolete. Namespaces are irrelevant for large
classes of documents, especially in the publishing field, where
schemas have little if anything to offer apart from enforcing the
format of dates. Many publishing applications also require the
facilities offered by declared entities, which are not available in
W3C Schemas.

///Peter
--
XML FAQ: http://xml.silmaril.ie/

Peter Flynn wrote:
> It was very clear from this summer's Extreme Markup Conference that
> DTDs are anything but obsolete.

I did say "arguably". I agree they're still being used; there's less
consensus on whether that's a good thing.

> Namespaces are irrelevant for large
> classes of documents, especially in the publishing field

Definitely disagree. That's true initially when you aren't exchanging
data with other applications or working with applications smart enough
to allow plug-in extensions. As soon as those assertions start breaking
down, namespaces become valuable and DTDs start falling apart. (I've
been involved in this since before namespaces existed, so I've had the
experience of trying to design namespaces into a DTD. Even if you kluge
like mad, it's still putting lipstick on a pig -- the results are not
pretty and the pig doesn't enjoy it at all.)

> Many publishing applications also require the
> facilities offered by declared entities, which are not available in
> W3C Schemas.

Correction: They require macro/import capabilities. Entities are
certainly the traditional way of doing that, inherited from SGML. and I
agree that schema doesn't support either. XML uses other tools --
XInclude, simple XSLT transformations, XPointer and so on -- to provide
similar capabilities.

The problem here is that the document world, understandably given their
SGML heritage. wants to treat XML as much like SGML as possible. They're
among the few who really like the DTD syntax, having "grown up with
it". They like entities because they're SGMLish. They dislike namespaces
because SGML didn't have them. I understand the resistance to change,
but I disagree that this resistance is well founded, and I feel that we
should be gently encouraging them to accept that XML is *not* SGML and
has its own (equivalent) solutions... for exactly the same reasons we
made the effort to teach C++ coders that just because they can write "as
if it was C" doesn't mean those are still the best answers in the new
environment.

I'm not dogmatic about this. People should do what's needed to get the
job done. But they should also design with an eye toward the future, and
I really don't think DTDs are it.

Your milage may vary.

--
() ASCII Ribbon Campaign | Joe Kesselman
/\ Stamp out HTML e-mail! | System architexture and kinetic poetry

Peter Flynn wrote:

> Namespaces are irrelevant for large
> classes of documents, especially in the publishing field,

Assume some witty rebutal of that on the general theme of "*******s"

Peter Flynn wrote:

> Namespaces are irrelevant for large
> classes of documents, especially in the publishing field,

OK, I've got back to a keyboad where all the keys work (I was on an
evil Sony Vaio wireless thing!)

Namespaces are useful. Namespaces are _especially_ useful in a metadata
processing context, and that is particularly relevant to document
publishing.

Taking the "sliding windows" view of data and metadata, we have a
layered view of our data in terms of abstraction. The stuff "in the
window" is treated as relevant data that's needed by the operation
currently being performed. Anything "below" this abstraction is opaque
data that's merely transported unchanged, anything "above" it is
metadata that's not immediately of relevance.

The power of this model is that it allows us to build
application-independent tools. A tool that understands email (or
internal document routing) can route documents around as unopened black
boxes, just using the RFC822 headers. An indexing tool can use Dublin
Core properties, without needing to know how to edit it. The editor can
display the Dublin Core metadata, and even permit some generalised
processing of it, because it's visible, it knows crude data typing of
it (just as strings or URLs) and it leaves the rest (and the meaning)
to the human user.

Gaining this sort of layered metadata handling is very easily done, if
you reference standard namespaces, such as Dublin Core or some shared
distribution vocabulary. Namespaces are ideal for providing that as a
simple implementation that allows complex documents to be aggregated
from simple known prototcols.

Andy Dingley wrote:

> Peter Flynn wrote:
>
>> Namespaces are irrelevant for large
>> classes of documents, especially in the publishing field,

Peter is talking about the observed situation, de-facto.

> Namespaces are useful. Namespaces are _especially_ useful in a metadata
> processing context, and that is particularly relevant to document
> publishing.

Peter is not expressing doubts about conceptual usefulness of namespaces.