Re: SD2 - Structured Attributes

Thank you Robin for a good foundation for this discussion. I 
support declaring "Structured Attributes" are within scope for XML v1.
To support this, I cite design goals 1 and 4 (usable of the Internet 
and easy to write programs that processes XML documents).

The Internet (at least the web) has a strong convention of ignoring
some parts of a document and processing others. Giving authors the 
ability to classify some information as attribute/meta and some as
content will help tool developers deal with the received data
with a minimum effort and special cases. 

Additionally, those who are extending the application to actively
process attributes will benefit from being able to reuse the same
structured content handling routines for attributes as they do for
content.

I am not sure which is the best encoding scheme. Right now, I prefer
the same techniques used for links, XML attributes on GIs with attlists. 
I assume that "attribute" vs "formatting" is the correct thing to 
differentiate but could be convinced otherwise.

Dave Hollander


Below are some detailed responses to yesterdays postings.
--------

> James Clark <jjc@jclark.com>
> I have difficulty in accepting structured attributes as a requirement.  To
> me they seem more like one possible *solution* than a requirement.  ...

I agree...lets state the problem not the solution.

--------

> Andrew Layman <andrewl@microsoft.com>
> If the policy is to ignore all unknown tags, the author is "William
> Shakespeare12345". If the policy is to ignore all unknown elements, the
> author is " ". 

I take the requirement to be that we should have a shorthand notation
for information that is not be considered part of the formatting stream.
Should it effect the stream (eg bullet style)?

--------

> Rick Jelliffe
> Your two alternate policies (ignore unkown elements, or include them) come
> from the browser world, and neither are common in the SGML world. And I don't
> think they are appropriate to XML either, in that the data being 
> transmitted using XML may well be not be literature but databases.  
> ...
> Or, better, in my opinion, is to flag it with a processing instruction
> near the top of the document, e.g.: 
> <?MS-structured-data meta="DSIG" ?>
> or even
> <?MS-structured-data  meta="DSIG"  context="author" target="MS-IE-6.*+" ?>

Yes, I do think that there should be some policies like this. XML is 
defined to be designed for the web and this type of policy has served
the web well. (should this policy be in a new thread?)

Re using PIs: I do not think we should instutionalize PI usage; leave
PIs for application specific behaviors.

--------

> lee@sq.com
> I don't think this at all radical.  In fact, we already have it!
> Consider
> 	<percy>
> 	  <attribute>
> 	    <name>Socks</name>
> 	    <value>
> 		<colour>red</colour>
> 		<material>cotton<material>
> 	    </value>
> 	  </attribute>
> 	  <content>
> 	    whatever you want
> 	  </content>
> 	</percy>

This would be one approach. I think the requirement was some what
to universally distinguish attributes from content. If we change
the GI to <xmlatt-attribute> and use the same attlist facility we use
for links we may have another solution.

I am not sure that distingishing attributes from content is the point.
If the only semantic that is instutionalized is if the data is included
in the formatted instance then perhaps that should be stated directly
<xmlfmt-attribute>.


To: James Clark <jjc@jclark.com>
cc: "'w3c-sgml-wg@w3.org'" <w3c-sgml-wg@w3.org>, dmh@hpsgml.fc.hp.com
Subject: Re: SD2 - Structured Attributes 
In-reply-to: Your message of "Fri, 16 May 1997 12:32:04 MDT."
             <2.2.32.19970516053204.0152a298@jclark.com> 
--------

Thank you Robin for a good foundation for this discussion. I 
support declaring "Structured Attributes" are within scope for XML v1.
To support this, I cite design goals 1 and 4 (usable of the Internet 
and easy to write programs that proceses XML documents).

The Internet (at least the web) has a strong convention of ignoring
some parts of a document and processing others. Giving authors the 
ability to clasify some information as attribute/meta and some as
content will help tool developers deal with the recieved data
with a minimum effort and special cases. 

Additionally, those who are extending the application to activily
process attributes will benefit from being able to reuse the same
structured content handling routines for attributes as they do for
content.

I am not sure which is the best encoding scheme. Right now, I prefer
the same techniques used for links, xml attributes on GIs with attlists. 
I assume that "attribute" vs "formatting" is the correct thing to 
differentiate but could be convinced otherwise.

Dave Hollander


Below are some detailed responses to yesterdays postings.
--------

> James Clark <jjc@jclark.com>
> I have difficulty in accepting structured attributes as a requirement.  To
> me they seem more like one possible *solution* than a requirement.  ...

I agree...lets state the problem not the solution.

--------

> Andrew Layman <andrewl@microsoft.com>
> If the policy is to ignore all unknown tags, the author is "William
> Shakespeare12345". If the policy is to ignore all unknown elements, the
> author is " ". 

I take the requirement to be that we should have a shorthand notation
for information that is not be considered part of the formatting stream.
Should it effect the stream (eg bullet style)?

--------

> Rick Jelliffe
> Your two alternate policies (ignore unkown elements, or include them) come
> from the browser world, and neither are common in the SGML world. And I don't
> think they are appropriate to XML either, in that the data being 
> transmitted using XML may well be not be literature but databases.  
> ...
> Or, better, in my opinion, is to flag it with a processing instruction
> near the top of the document, e.g.: 
> <?MS-structured-data meta="DSIG" ?>
> or even
> <?MS-structured-data  meta="DSIG"  context="author" target="MS-IE-6.*+" ?>

Yes, I do think that there should be some policies like this. XML is 
defined to be designed for the web and this type of policy has served
the web well. (should this policy be in a new thread?)

Re using PIs: I do not think we should instutionalize PI usage; leave
PIs for application specific behaviors.

--------

> lee@sq.com
> I don't think this at all radical.  In fact, we already have it!
> Consider
> 	<percy>
> 	  <attribute>
> 	    <name>Socks</name>
> 	    <value>
> 		<colour>red</colour>
> 		<material>cotton<material>
> 	    </value>
> 	  </attribute>
> 	  <content>
> 	    whatever you want
> 	  </content>
> 	</percy>

This would be one approach. I think the requirement was some what
to universally distinguish attributes from content. If we change
the GI to <xmlatt-attribute> and use the same attlist facility we use
for links we may have another solution.

I am not sure that distingishing attributes from content is the point.
If the only semantic that is instutionalized is if the data is included
in the formatted instance then perhaps that should be stated directly
<xmlfmt-attribute>.

Received on Friday, 16 May 1997 14:53:14 UTC