attachment-0001

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1"> <META content="MSHTML 5.50.4916.2300" name=GENERATOR> <STYLE></STYLE> </HEAD> <BODY bgColor=#ffffff> <DIV><FONT face="Courier New" color=#0000ff size=2><SPAN class=827135701-17072002>Hi Norbert, all,</SPAN></FONT></DIV> <DIV><FONT face="Courier New" color=#0000ff size=2><SPAN class=827135701-17072002></SPAN></FONT> </DIV> <DIV><FONT face="Courier New" color=#0000ff size=2><SPAN class=827135701-17072002>One of the things we (HP) have been suggesting for the semantic model is the separation of the raw "attribute/element" definitions from the structures/model that pull them together for a particular use.  As you not, UPDF has done this structuring in a different way than IPP - which is also somewhat different than UPnP & PSI, etc.  I'm not sure we want to try codify any one structure as part of the core semantic model - these will tend to vary by market segment and domain, and I'm not sure we can do this one-size-fits-all.  What we would like to see, though, is common definition of the</SPAN></FONT></DIV> <DIV><FONT face="Courier New" color=#0000ff size=2><SPAN class=827135701-17072002>core "attributes/elements" - this seems much more reusable across models & domains.  It does make sense, though, to publish some of the "common models" as at least examples of structural models - IPP, UPDF, etc. are likely candidates for this.  This exposes some of useful constructs (such as the composite feature you describe below) for reuse.</SPAN></FONT></DIV> <DIV><FONT face="Courier New" color=#0000ff size=2><SPAN class=827135701-17072002></SPAN></FONT> </DIV> <DIV><FONT face="Courier New" color=#0000ff size=2><SPAN class=827135701-17072002>thanks,</SPAN></FONT></DIV> <DIV><FONT face="Courier New" color=#0000ff size=2><SPAN class=827135701-17072002></SPAN></FONT> </DIV> <DIV><FONT face="Courier New" color=#0000ff size=2><SPAN class=827135701-17072002>bt</SPAN></FONT></DIV> <DIV><FONT face="Courier New" color=#0000ff size=2><SPAN class=827135701-17072002></SPAN></FONT> </DIV> <DIV><FONT face="Courier New" color=#0000ff size=2><SPAN class=827135701-17072002> <P><FONT size=2>---------------------------------------------------<BR>Bob Taylor                                       <BR>Senior Architect                           <BR>IPG Strategic Technology Development <BR>Hewlett-Packard Co.      <BR><A href="mailto:robertt@vcd.hp.com">mailto:robertt@vcd.hp.com</A>                       <BR>phone: 360.212.2625/T212.2625                   <BR>fax: 208.730-5111                <BR>---------------------------------------------------   </FONT></P></SPAN></FONT></DIV> <BLOCKQUOTE dir=ltr style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px"> <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma size=2>-----Original Message-----<BR><B>From:</B> Norbert Schade [mailto:norbertschade@attbi.com]<BR><B>Sent:</B> Monday, July 08, 2002 7:32 AM<BR><B>To:</B> Print Services group<BR><B>Cc:</B> UPD group<BR><B>Subject:</B> PS> Semantic model: media handling<BR><BR></FONT></DIV> <DIV><FONT size=2>I have problems to follow two different ways to specify media handling and UPDF would have problems to support that.</FONT></DIV> <DIV><FONT size=2>I'm fine with the specification of single media attributes like size, type, etc.</FONT></DIV> <DIV><FONT size=2>I agree that there should exist a media instance a level higher, which is a media element with a number of media attributes.</FONT></DIV> <DIV><FONT size=2>The number of attributes can vary. In one sample it may be just size and type, in another it may be something like the IPP media collection.</FONT></DIV> <DIV><FONT size=2></FONT> </DIV> <DIV><FONT size=2>My point is that the attributes a media is described by may vary.</FONT></DIV> <DIV><FONT size=2>There should not be a predefined media collection in a common Semantic Model representing one implementation.</FONT></DIV> <DIV><FONT size=2></FONT> </DIV> <DIV><FONT size=2>Feel free to check the composite feature definition we have in UPDF. Open the UPDF.xsd schema to do this and follow the path down to PrintCapabilities.Features. The current sample description xml of an imaginary LJ9000 has a 'Media' composite feature.  We can compose any number of features to a new feature, be it Media, Quality or anything else. This is a very flexible structure and is expected to be used frequently. We got very positive feedback once we finished it last year.</FONT></DIV> <DIV><FONT size=2></FONT> </DIV> <DIV><FONT size=2>We'd appreciate if  the Semantic Model does something down that path. Otherwise the spec is ambiguous.</FONT></DIV> <DIV><FONT size=2></FONT> </DIV> <DIV><FONT size=2></FONT> </DIV> <DIV><FONT size=2>Another statement:</FONT></DIV> <DIV><FONT size=2>We've seen the current schema of the Semantic Model. We know there are a number of ways to write schemas. The UPDF group made the experience that working with attributes instead of assigning text to elements directly has advantages. Validation is easier and we can define constraints (these are really constraints and not dependencies) for attributes. You may think that over.</FONT></DIV> <DIV><FONT size=2></FONT> </DIV> <DIV><FONT size=2>Regards</FONT></DIV> <DIV><FONT size=2></FONT> </DIV> <DIV><FONT size=2>Norbert Schade<BR>69 Prescott Drive<BR>North Chelmsford, MA 01863<BR>978-251-1017<BR><A href="mailto:norbertschade@attbi.com">norbertschade@attbi.com</A></FONT></DIV></BLOCKQUOTE></BODY></HTML>