various issues

[Peter Newcomb]

> From: David Megginson <dmeggins at uottawa.ca>
> 
> Peter Murray-Rust writes:
> 
>  > > The one short-coming is that XML does not support data-attributes, so
>  > > it will not be possible to customise the AF support -- you'll have to
>  > > stick with the defaults.
>  > 
>  > This sounds reasonable for a first step :-)
> 
> Perhaps -- some of the configuration is quite important, however (do
> you want to provide a bridge element for the targets of IDREFs, for
> example?).

There are a number of architecture support attributes, all of
which appear as data attributes of the architecture notation (the
notation pointed to by the ArcBase PI).  Some of these attributes are
critical (i.e. needed 90% of the time), and one of them is required.
They are used to specify:

- the name of the architectural form attribute, used to identify the
  architectural form to which an element conforms (default: same as
  architecture notation name)

- the name of the architectural attribute renamer attribute, used to
  resolve attribute name conflicts between multiple architectures
  (default: no renaming)

- the name of the architecture suppressor attribute, used to control
  the recognition of architectural forms from this architecture within
  the content of an element (default: no suppression)

- the name of the architecture ignore data attribute, used to control
  whether the data content an element is to be considered part of the
  architectural instance (default: data is included or ignored
  according to the architecture's meta-DTD)

- the name of the architecture document element form, to which the
  document element must conform (default: same as architecture
  notation name)

- the name of the meta-DTD entity (REQUIRED for validation)

- a list of quantity set variations for the architecture (default:
  same as document)

- the default notation form for data entities (the bridge data
  form) (default: data entities are not necessarily propagated to the
  architectural document instance, and therefore cannot be used to
  satisfy ENTITY architectural attributes)

- the default element form for elements with IDs (the bridge element
  form) (default: element with IDs are not necessarily propagated to
  the architectural document instance, and therefore cannot be used to
  satisfy IDREF architectural attributes)

- whether or not to automatically map element types to element forms
  of the same name (default: perform automatic mapping)

- the names of parameter entities to give the replacement text
  "INCLUDE", used to identify the facilities of the architecture
  required by the document (default: use only non-optional facilities)

- other architecture-specific options (e.g., in HyTime, the maximum
  resolution required for finite coordinate spaces)

I would very much like to be able to use the SGML architecture
mechanism with XML, but XML's lack of data attributes makes it
impossible to do so, except in the simplest of cases.  (And even in
those cases we cannot prove architectural validity for lack of a
meta-DTD entity name.)  Either we need data attributes in XML, or a
different architecture binding mechanism needs to be devised.  My
personal opinion is that the former would be easier, and more
generally useful, but I have to admit to a tendency to the more
general and therefore less easily implementable.

-peter

--
Peter Newcomb                           TechnoTeacher, Inc.
233 Spruce Avenue                       P.O. Box 23795
Rochester, NY 14611-4041 USA            Rochester, New York 14692-3795 USA
+1 716 464 8696 (home)                  +1 716 464 8696 (direct)
+1 716 755 8698 (cell)                  +1 716 271 0796 (main)
+1 716 529 4304 (fax)                   +1 716 271 0129 (fax)
peter at petes-house.rochester.ny.us       peter at techno.com
http://www.petes-house.rochester.ny.us  http://www.techno.com

xml-dev: A list for W3C XML Developers
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To unsubscribe, send to majordomo at ic.ac.uk the following message;
unsubscribe xml-dev
List coordinator, Henry Rzepa (rzepa at ic.ac.uk)