[XML-SIG] XBEL documentation, draft

[Fred L. Drake]

Greg Stein writes:
 > The DTD wasn't attached :-)

  Yeah, I realized that as soon as I sent the note!  But it went
shortly thereafter, so we'll all get over it, I hope.  ;-)

 > Nevertheless, I feel that the metadata element has very little purpose.
 > Given the presence of XML Namespaces
 > (http://www.w3.org/TR/WD-xml-names), I don't think that the metadata tag
 > adds any value. Rather than use <metadata owner="http://foo.com/app">,
 > we can use <app:mytag xmlns:app="http://foo.com/app">. Of course, there

  I tried to explain in the document why namespaces alone are not
sufficient, but I guess I wasn't successful.
  A namespace is really just refers to a structure definition.  There
is no reason that applications must use their own structure
definitions.  For example, two might use something that defines an
element with that includes a bunch of <meta> elements, similar to
those in a previous iteration of XBEL:

	<info>
	  <mine:metadict xmlns:mine="some-uri-1">
	    <mine:meta name="foo">bar</mine:meta>
	    </mine:metadict>
	  <yours:metadict xmlns:yours="some-uri-1">
	    <yours:meta name="frob">nitz</yours:meta>
	    </yours:metadict>
	  </info>

  You are saying that metadata structure definitions cannot be shared
independently of the instance data; does this really make sense?  In
the presence of generalized things like RDF, I think not.  That's why
I want to keep another level of owner identification around.

 > are other ways to specify the use of a namespace, but the point is that
 > a "metadata-like" facility has already been defined in a standardized
 > fashion (with the caveat of minor perturbations to the working draft
 > prior to IETF acceptance).

  Again, XML namespaces are really meta-information about the
structure of the data, and are not related to "ownership", which is
much closer to an application-level concept.

 > %common.attrs% is not very useful as an extension. It is located to
 > broadly for somebody to extend the DTD. If you try to add something into
 > %common.attr% it shows up EVERYWHERE. eek. Personally, I'm of the mind

  Ok, perhaps.  I'm used to seeing DTDs that have something that is
allowed everywhere, typically an ID to allow addressability and
something like HTML's CLASS or DocBook's ROLE.  This can then be
extended using a local.<whatever-its-called> to add additional
attributes.  Other groups of attribute definitions then also have
their own local.<whatever> parts that can be defined extended DTDs.
Other parameter entities are used to construct content models, etc.
  How about this:  We drop common.att, and add in local.node.att,
local.url.add, and local.node.mix.  These will be defined to be "",
and included at the end of their non-local definition.  This removes
the more difficult to use common.att, while allowing extensibility
using more targeted parameters.

 > that somebody can issue a second version of the DTD, rather than attempt
 > to extend it. At the present time, I'm not aware of apps that actually

  The application would not be the one to extend it.  Often, "industry 
standard" DTDs are subclassed in exactly this way to support
additional requirements for internal data/document management.
Instances are then down-converted for interchange.  This does not
strike me as being the "wrong" way.  When it doesn't work, it's most
likely that what is really needed isn't an extension of the original
DTD in the first place.  In this environment, it makes a lot of sense
for maintainability to use the original public text without change to
avoid accidental structural drift during maintenance.

 > Further, given the presence of XML namespaces, an XBEL document can
 > simply be incorporated *within* another XML document. i.e. extension via
 > containment, rather than extension via derivation.

  As I tried to describe above, the ability to contain isn't the
problem; XML handles that quite nicely (esp. with namespaces).
Ownership is simply a different problem.


  -Fred

--
Fred L. Drake, Jr.	     <fdrake@acm.org>
Corporation for National Research Initiatives
1895 Preston White Dr.	    Reston, VA  20191