lynx-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: LYNX-DEV Internal MIME types


From: Al Gilman
Subject: Re: LYNX-DEV Internal MIME types
Date: Mon, 28 Apr 1997 12:42:21 -0400 (EDT)

  From: "Christopher R. Maden" <address@hidden>

  [Al Gilman]
  > SGML forces us to write the rules in unenforceably strict ways, like
  > Prohibition.
  > 
  > To write more savvy rules that you can stick to, you need a
  > sufficiently flexible fabric to cut them from.  SGML doesn't cut it
  > there.  XML tries to be more regular and thereby more flexible.
  > We'll see how they do.
  
  XML allows the innovative concept of "well-formed" documents.  These
  are documents that have elements that start and end, nest, and have
  full attribute specifications.  THEY NEED NOT COMPLY TO A CONTENT
  MODEL.  This is a first, and is something of an SGML heresy.
  
This is a positive step.  I am not sure that the XML enthusiasts
are recognizing that there need to be shared [standard, registered,
etc. ] content concepts as well as general well-formedness rules
for forms.  XML is relaxing the tight one-to-one relationship
SGML imposes between content concepts and structural forms.
This is good.  We want to reuse formal classes across multiple
content classes.  But we still need to address content, albeit
at arm's length from structure.

  The accessibility benefit from XML is that things will be labelled as
  WHAT THEY ARE.  ("Call a spade a <spade>," says Peter Flynn.)  If the
  publisher didn't provide an audio spreadsheet, a visually impaired
  user can look at the source and *figure out what the author meant*!
  This is *not* something that can be done with HTML; a <p> might
  contain information without which deaths will occur, or it might be a
  digression - there's no difference.  In XML, the author could label it
  a <warning> or a <fluff>, and the end-user can tell what was meant and
  apply their own semantics to it.
  
If there is no registry to look up more info about what <warning>
and <fluff> are, this is limited help.  What if class definitions
are handled over an "orderwire," a separate discourse dealing
with meta-data?  Suppose one could retrieve class definitions as
required much the way the DNS works now?  Call it a Class Name
Service.

--
Al Gilman
;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;

reply via email to

[Prev in Thread] Current Thread [Next in Thread]