[Auscope-geosciml] RE : RE : Testbed proposition [SEC=UNCLASSIFIED]

Wed Mar 3 18:28:31 EST 2010

Ok,   Testbed 4 will run on WFS 1.1 / GML 3.1 for immediate testing. 
I'm hoping someone (BGS?) will also test GeoSciML RC3 against GML3.2. 
Otherwise we will need to do that as part of  further testing prior to 
release of GeoSciML v3.0.

Bruce

GeoScience Victoria
AuScope Grid
Australian Spatial Research Data Commons

Ph: +61-3-9658 4502
Fax: +61-3-9658 4555 
Mobile: +61 429 177155

"Boisvert, Eric" <Eric.Boisvert at RNCan-NRCan.gc.ca> 
Sent by: auscope-geosciml-bounces at lists.arcs.org.au
04/03/2010 09:56 AM
Please respond to
auscope-geosciml at lists.arcs.org.au

To
<auscope-geosciml at lists.arcs.org.au>, <auscope-geosciml at lists.arcs.org.au>
cc

Subject
[Auscope-geosciml] RE :  RE :  Testbed proposition [SEC=UNCLASSIFIED]

Ok,   Testbed 4 will run on WFS 1.1 / GML 3.1 for immediate testing. 
Will move to WFS 2.0 / GML 3.2 when software becomes available. 
No intent to release as 3.1 as an official release.

I got it rigth ?

________________________________

De: auscope-geosciml-bounces at lists.arcs.org.au de la part de 
Oliver.Raymond at ga.gov.au
Date: mer. 2010-03-03 17:35
À: auscope-geosciml at lists.arcs.org.au
Objet : Re: [Auscope-geosciml] RE : Testbed proposition [SEC=UNCLASSIFIED]

It was also my impression that building a GML3.1-compliant version of 
GeoSciML3 would only be used for testing using currently available 
non-GML3.2-capable software.  The final release of GeoSciML 3.0 would be a 
GML3.2-compliant schema.

As far as why I built the proxy ISO19115 model, I'll reply shortly after 
more fully reviewing all the emails and other resources.

Cheers,

Ollie

------------------------------------------------------------------------------------------------

Ollie Raymond
National Advice,  Maps and Standards Project

Geoscience Australia

Address: GPO Box 378, Canberra, ACT, 2601, Australia | ABN: 80 091 799 039

Ph: (02) 62499575 | Fax: (02) 62499992 | Email: Oliver.Raymond at ga.gov.au 

Web:  
http://www.ga.gov.au/minerals/research/national/nat_maps/nat_geol_maps.jsp 
<
http://www.ga.gov.au/minerals/research/national/nat_maps/nat_geol_maps.jsp
>  <http://www.ga.gov.au/geoscience/national> 

Google Map <
http://maps.google.com/maps?f=q&hl=en&geocode=&q=canberra+australia&ie=UTF8&ll=-35.344028,149.158362&spn=0.007684,0.016404&t=h&z=17&iwloc=addr&om=1
> 

-- This message was created with 100% recycled electrons --

-----Original Message-----
From: auscope-geosciml-bounces at lists.arcs.org.au 
[mailto:auscope-geosciml-bounces at lists.arcs.org.au] On Behalf Of 
Bruce.Simons at dpi.vic.gov.au
Sent: Thursday, 4 March 2010 9:28 AM
To: auscope-geosciml at lists.arcs.org.au
Subject: Re: [Auscope-geosciml] RE : Testbed proposition 
[SEC=UNCLASSIFIED]

Bruce, can you clarify ?.  I understand from the note that the 3.1 would 
be 'for testing until software is available'.  Your email "  In order that 
we at least have a chance of setting up GeoSciML 3.0 services I repeat my 
request in Quebec that GeoSciML remain a GML 3.1 application, with 
additional 'placeholders' for GML3.2 properties." seems to suggest that 
you want it to remain (forever) 3.1.1 

Only GML 3.1 for testbed purposes so we can actually establish some 
services. The aim would be to release GeoSciML 3.0 as a GML 3.2 schema, 
either based on Testbed 4 testing if someone tests the GML3.2 
implementation (using Snowflake and/or Coccoon?) or after post Testbed4 
testing. 
Certainly the change of version numbering to 3 was intended to indicate no 
backward compatibility, at least in part due to the move to GML3.2. 

Cheers 
Bruce

GeoScience Victoria
AuScope Grid
Australian Spatial Research Data Commons

Ph: +61-3-9658 4502
Fax: +61-3-9658 4555 
Mobile: +61 429 177155 

Létourneau, François <Francois.Letourneau at RNCan-NRCan.gc.ca> 
Sent by: auscope-geosciml-bounces at lists.arcs.org.au 

04/03/2010 06:24 AM 

Please respond to
auscope-geosciml at lists.arcs.org.au

To

<auscope-geosciml at lists.arcs.org.au> 

cc

Subject

Re: [Auscope-geosciml]        RE :  Testbed proposition [SEC=UNCLASSIFIED]

Éric, 

As for having a conforming schema in 3.1.1 or 3.2.0, we need to have all 
the required classmaps as a 3.1 or 3.2 implementation. The, in Fullmoon, 
when we generate the schemas, we explicitely tell Fullmoon to use v3.1 or 
v3.2. It is not too difficult to build the missing classmaps, it only 
takes time, as it requires exhautivity in documenting everything needed. 

François 

François Létourneau
Professionnel de recherche - géomatique / TI
Institut national de la recherche scientifique 
Centre Eau Terre Environnement - Centre Géoscientifique de Québec
490, de la Couronne, bureau 3344
Québec (Québec) G1K 9A9
418 654-3161 

________________________________

De : auscope-geosciml-bounces at lists.arcs.org.au 
[mailto:auscope-geosciml-bounces at lists.arcs.org.au] De la part de 
Boisvert, Eric
Envoyé : 3 mars 2010 14:14
À : auscope-geosciml at lists.arcs.org.au
Objet : Re: [Auscope-geosciml]RE : Testbed proposition [SEC=UNCLASSIFIED]

Ok, looks like the ball stopped bouncing here. 

Do we go forward with the instance document from a legend/story ?  Do we 
have agreement from people who commited to those use cases ? 

Do we have someone to build/lend a pretty complete database so we can test 
serialisation with WFS 1.1.0 and potentially WFS 2.0 for people who wants 
to take advantage of Snowflakes offer ? 

I understand from Simon that having a 3.1.1 and a 3.2.0 conformant schemas 
is a matter of configuring FullMoon correctly - something we apparently 
having problem wrapping our minds around.  Is somebody looking into this ? 

Regarding Bruce's request to keep GeoSciML 3 as a GML 3.1 application, I 
read back the twiki notes and it is said: 

"BS proposed and it was unaimously agreed that:: "Geosciml v3 release 
candidates will be based on GML 3.1.1 implementation for testing - the 
final production release of GeoSciML v 3 will wait for commercial and open 
source software to support both gml 3.2.1 and wfs2 (within that modules of 
conformance level that the GeoSciML community decides it needs) - which 
will probably second half of 2010. AUSCOPE Geoserver plans to work on WFS2 
implementation from the second half of 2010." 

Bruce, can you clarify ?.  I understand from the note that the 3.1 would 
be 'for testing until software is available'.  Your email "  In order that 
we at least have a chance of setting up GeoSciML 3.0 services I repeat my 
request in Quebec that GeoSciML remain a GML 3.1 application, with 
additional 'placeholders' for GML3.2 properties." seems to suggest that 
you want it to remain (forever) 3.1.1 

About WFS service : Do we need to prepare test request or is it 
essentially a serialization exercise ? 

Eric 

________________________________

De : auscope-geosciml-bounces at lists.arcs.org.au 
[mailto:auscope-geosciml-bounces at lists.arcs.org.au] De la part de 
Rob.Atkinson at csiro.au
Envoyé : 1 mars 2010 21:49
À : auscope-geosciml at lists.arcs.org.au
Objet : Re: [Auscope-geosciml] RE : Testbed proposition [SEC=UNCLASSIFIED]

Re 

" the model itself in an ideal situation would not be constrained by 
implementation details. In practice though it is ..." 

the reality is that the underlying agreement about semantics is partially 
driven by what people are motivated and able to implement - its the 
realpolitik of semantic governance that the level of abstraction of the 
conceptual model is variable according to the complexity and maturity of 
the domain. 

The CGI model is trying to find the right balance between the mess of 
multiple similar implementations and the unbounded nature of a top-down 
description of the real world. Over time we hope to see some guidance and 
best practice emerge as to how to find the right level of abstraction, but 
from my experience across multiple domains: 

1) you cant extend the model beyond the combination existing systems and 
specific interoperability requirements you can define test cases for. (and 
in many cases existing systems may need to support structural and semantic 
matching to realise these) 
2) The conceptual model should be abstracted around the concept of object 
identity - not the specific set of attributes you might attach to a 
concept 

I think the CGI model has some way to go - its still a reverse engineering 
activity, starting to explore the actual interoperability requirements. 
Its a good place, in that care is being taken to establish test cases, and 
its getting less of an implementation flavour each iteration. 

Rob Atkinson 
Research Scientist, Water Informatics 
CSIRO Land & Water 
Ph (mobile) +61 419 202 973 

________________________________

From: auscope-geosciml-bounces at lists.arcs.org.au 
[mailto:auscope-geosciml-bounces at lists.arcs.org.au] On Behalf Of 
Robert.Woodcock at csiro.au
Sent: Tuesday, 2 March 2010 1:32 PM
To: auscope-geosciml at lists.arcs.org.au
Subject: [ExternalEmail] Re: [Auscope-geosciml] RE : Testbed proposition 
[SEC=UNCLASSIFIED]

> Fine with me, but this is more testing available mapping technologies 
than testing the model itself. Unless WFS and/or RDBMS constrains becomes 
model design requirements. 

AuScope are keen to ensure that we have some decent tests for WFS serving 
GML application schemas. The current OGC cite tests in this regard are 
lacking. This is one of the drivers behind the "unit tests" Bruce Simons 
is referring too. GeoSciML being one of the more mature GML application 
schemas provides a useful basis for such testing for both WFS compliance 
and for the GeoServer technology. We hope to feed the test suite back into 
the OGC compliance process. So, yes, it is more about testing the 
standards and mapping technologies rather than the model itself though it 
will serve both purposes. 

The second comment regarding the WFS or the RDBMS becoming constraints on 
the model design requirements is interesting. In my view these already 
are, or should be, lest the model itself become something that cannot be 
implemented or managed in practice. I include "managed" as the community 
of practice around GeosciML also uses HollowWorld for model management 
plus vocab management tools etc. It's a complete system that is required. 

Please don't misunderstand me, the model itself in an ideal situation 
would not be constrained by implementation details. In practice though it 
is and whilst the WFS middleware is immature relative to the modelling 
process the model runs the risk of getting ahead of the implementations 
and becoming not implementable/manageable - my concerns about WFS CITE 
tests relates to this, so does the Geoserver development which we are 
earnestly trying to complete the foundation work for GeoSciML support 
before WFS 2.0 and GeoSciML 3 arrive. The separate, but related, 
developments that make up the community of practice that is using GeoSciML 
needs to remain in loose synchronisation and not get to far ahead or 
behind one another for the varying parts of the system. So far so good. 

> Actually, this also begs the question.. Are we restricted to classical 
RDBMS or is it more about currently available softwares ? 

In my view it is more about currently available software. I built a WFS 
using XMML (roughly an early version of GeoSciML Borehole) using an Object 
Oriented database some years back. Full 3D support, web delivery etc. 
Somewhat bespoke for that particular OO database but there was nothing in 
the XMML model that seems restrictive to RDBMS - in fact it was somewhat 
easier than the RDBMS mapping process used in Geoserver as the OO database 
was "Feature" based in the first place so a much closer match to the GML 
model. 

Regards, 

Rob 

Dr Robert Woodcock
CSIRO
ARRC (Australian Resources Research Centre)
26 Dick Perry Avenue, Kensington WA 6151, Australia
PO Box 1130, Bentley WA 6102, Australia
Ph: 08 6436.8780 | E: Robert.Woodcock at csiro.au <
mailto:Robert.Woodcock at csiro.au>  | W: www.csiro.au <http://www.csiro.au/> 

From: auscope-geosciml-bounces at lists.arcs.org.au 
[mailto:auscope-geosciml-bounces at lists.arcs.org.au] On Behalf Of Boisvert, 
Eric
Sent: Monday, 1 March 2010 6:12 PM
To: auscope-geosciml at lists.arcs.org.au
Subject: [Auscope-geosciml] RE : Testbed proposition [SEC=UNCLASSIFIED] 

> It will also serve for 'unit tests' when testing middkleware such as 
GeoServer for WFS1.1 compliance.  In order to test the mapping and 
transformation it shouldn't be a database that looks like GeoSciML, but 
rather like one of our pre-GeoSciML databases with any missing components 
added to it. 

Fine with me, but this is more testing available mapping technologies than 
testing the model itself. Unless WFS and/or RDBMS constrains becomes model 
design requirements.  Actually, this also begs the question.. Are we 
restricted to classical RDBMS or is it more about currently available 
softwares ? 

Eric 

________________________________

De: auscope-geosciml-bounces at lists.arcs.org.au de la part de 
Bruce.Simons at dpi.vic.gov.au
Date: dim. 2010-02-28 17:06
À: auscope-geosciml at lists.arcs.org.au
Objet : Re: [Auscope-geosciml] Testbed proposition [SEC=UNCLASSIFIED] 

Hi all, 
I'm happy to use instance documents to test the model if services aren't 
available. However, we need to be careful that the modelling does not get 
too far ahead of the implementation, which is what can happen with this 
strategy, and has in the past.  In order that we at least have a chance of 
setting up GeoSciML 3.0 services I repeat my request in Quebec that 
GeoSciML remain a GML 3.1 application, with additional 'placeholders' for 
GML3.2 properties if necessary. 

Eric proposed: 

My suggestion for this portion of the testbed is 
1- Come with a series of legend descriptions, or stories for each of the 
relevant use cases. Different regions and languages is obviously 
encouraged. Agree. But I would also like to see a 'test' database 
established (see below). 

2- Have people to generate instance document based on selected stories. 
The interesting bit is when more than one person attempts to serialise the 
same stories. We already know that there is a lot of assumptions in legend 
description and it will be interesting to see how this materialise on a 
rigid GeoSciML document. 
Although this is is good it is not sufficient.  we also need to commit to 
ensuring that the different instance documents are compared to ensure 
consistency between them. We have not fully done this in previous 
testbeds, as it can be quite onerous and time-consuming. 

An issue with this approach is that it will only include data we have in 
our production databases, or in a particular legend.  This does not fully 
test the model. I suggest that one of the Testbed participants (any 
volunteers?) also create a 'dummy' database which contains all properties 
that we wish to test (complete GeoSciML).  We then use this as a guide to 
craft the instance documents, and our own databases to establish the 
services.  It will also serve for 'unit tests' when testing middkleware 
such as GeoServer for WFS1.1 compliance.  In order to test the mapping and 
transformation it shouldn't be a database that looks like GeoSciML, but 
rather like one of our pre-GeoSciML databases with any missing components 
added to it. 

Cheers 
Bruce

GeoScience Victoria
AuScope Grid
Australian Spatial Research Data Commons

Ph: +61-3-9658 4502
Fax: +61-3-9658 4555 
Mobile: +61 429 177155 

<Oliver.Raymond at ga.gov.au> 
Sent by: auscope-geosciml-bounces at lists.arcs.org.au 

26/02/2010 08:50 AM 

Please respond to
auscope-geosciml at lists.arcs.org.au

To

<auscope-geosciml at lists.arcs.org.au> 

cc

Subject

Re: [Auscope-geosciml] Testbed proposition [SEC=UNCLASSIFIED]

I agree too. 

Personally, I am keen to see the process applied to geochemistry data too, 
mainly because O&M "result" is of type "Any", meaning that currently users 
can encode their assay data using any of several available methods (eg, 
swe:Quantity, gml:measure, etc).  Having a best practice XML example of a 
geochemistry 'story' is essential. 

Cheers, 
Ollie 

------------------------------------------------------------------------------------------------ 

Ollie Raymond
National Advice,  Maps and Standards Project 
Geoscience Australia 

Address: GPO Box 378, Canberra, ACT, 2601, Australia | ABN: 80 091 799 039 

Ph: (02) 62499575 | Fax: (02) 62499992 | Email: Oliver.Raymond at ga.gov.au 
Web:  
http://www.ga.gov.au/minerals/research/national/nat_maps/nat_geol_maps.jsp 
<
http://www.ga.gov.au/minerals/research/national/nat_maps/nat_geol_maps.jsp
> 

Google Map <
http://maps.google.com/maps?f=q&hl=en&geocode=&q=canberra+australia&ie=UTF8&ll=-35.344028,149.158362&spn=0.007684,0.016404&t=h&z=17&iwloc=addr&om=1
> 

-- This message was created with 100% recycled electrons -- 

-----Original Message-----
From: auscope-geosciml-bounces at lists.arcs.org.au 
[mailto:auscope-geosciml-bounces at lists.arcs.org.au] On Behalf Of Boisvert, 
Eric
Sent: Friday, 26 February 2010 1:39 AM
To: auscope-geosciml at lists.arcs.org.au
Subject: Re: [Auscope-geosciml] Testbed proposition 

> I really like the idea of adding real XML examples to a specification 
document. 

Ditto for me, I think it's the most readable form. 

If I understand the current trend up there at ISO/OGC, looks like the UML 
spec and XML encoding will now be published in two separates documents (to 
avoid making amendment to the UML+XML spec when only changes to XML is 
needed and to have UML spec independent of implementation).  The 
"instance" in the UML spec are often shown as UML instance diagram that 
all looks like a freak accident in Legoland if you ask me. 

Eric 

________________________________

De : auscope-geosciml-bounces at lists.arcs.org.au 
[mailto:auscope-geosciml-bounces at lists.arcs.org.au] De la part de 
Guillaume.Duclaux at csiro.au
Envoyé : 25 février 2010 09:34
À : auscope-geosciml at lists.arcs.org.au
Objet : Re: [Auscope-geosciml] Testbed proposition 
I really like the idea of adding real XML examples to a specification 
document. 

<<Some specification document (O&M "banana" examples come to mind) had 
those examples and they were extremely useful to 'grasp' the concept, 
specially when showing them to non-technical people. >> 
+1 --> The example helped me probably more than the spec document itself 
for the NVCL o&m work I started and improved with Bruce and Alistair. 

Gilly 
________________________________________________ 

Dr Guillaume Duclaux 
CSIRO Earth Science and Resource Engineering 
Visiting address: ARRC, 26 Dick Perry Av., Kensington WA 6151 
Postal address: PO Box 1130, Bentley WA 6102, Australia 
Ph: + 61 8 6436 8728    Fax: + 61 8 6436 8555    Web: www.csiro.au <
http://www.csiro.au/> 

________________________________

From: auscope-geosciml-bounces at lists.arcs.org.au 
[mailto:auscope-geosciml-bounces at lists.arcs.org.au] On Behalf Of Boisvert, 
Eric
Sent: Thursday, 25 February 2010 9:05 PM
To: auscope-geosciml at lists.arcs.org.au
Subject: [Auscope-geosciml] Testbed proposition 

Guys, 
A significant portion of use cases we have listed in Quebec is about 
testing new and altered elements of GeoSciML v3. In the past we tested 
those changes with instance documents and created a series of testbed to 
test the serialisation from a database. I think it's important to 
emphasise the difference between testing the model and testing the 
serialisation. Instance document allowed us to test the model with real 
cases. Creating WFS from a database allowed us to test the feasibility of 
turning our respective databases into GeoSciML (we tested the mapping 
between our databases and GeoSciML and its queriability using WFS). In 
principle, when we are testing the serialisation, the model should already 
be tested. 

In NADM, we tested the model with a real case example from a legend 
description of a geological map of Arizona: 
Harald Drewes. 1998,. ARIZONA. Geologic map of the Bartlett Mountain 
Quadrangle, Pima and Santa Cruz counties, Arizona, I-2624. Lat 31 deg 
22'30" to 31 deg 30', long 111 deg 15' to 111 deg 22'30". Scale 1:24,000 
(1 inch = 2,000 feet). Sheet 43 by 39 1/2 inches. 

The text of the legend read as follow : 
Dacitic Vent Breccia (Miocene) -Light-medium-gray, finely porphyritic 
dacitic rock containing inclusions of Jurassic or Proterozoic granite and 
Jurassic rhyolite (welded tuff?) as much as 20 m in diameter. The 
subcircular outcrop mass of breccia probably is a volcanic vent or throat. 
A halo of strongly saussuritized rock 0.3 -0.5 km wide (delineated on map) 
surrounds this vent. The dacitic matrix consists of phenocrysts (25-35%, 
as much as 2 mm in length) set in a cryptocrystalline granular groundmass. 
Phenocrysts included albitized(?) plagioclase (12-18%), chloritized 
biotite (2-5%), uralized amphibole (2-10%), magnetite (trace to 2%), and 
apatite (trace). Quartz is present as a secondary mineral, filing vugs. 

At that time, the data model was a RDBMS implementation, therefore the 
'instance' document was a description of the table content: see: 
http://ngmdb.usgs.gov/www-nadm/dmdt/pdf/CORDLink_Variant_Example.pdf 

What I found interesting in this exercise was that we tested the model 
from a real case. Some specification document (O&M "banana" examples come 
to mind) had those examples and they were extremely useful to 'grasp' the 
concept, specially when showing them to non-technical people. What I 
propose as a testbed (at least for that portion of the use cases that are 
relevant) is to have similar exercises. The added benefit is to produce 
material, coupled with an updated document like OneGeology Cookbook #2, 
that can be used in discussion with new comers and non-technical people. 

My suggestion for this portion of the testbed is 
1- Come with a series of legend descriptions, or stories for each of the 
relevant use cases. Different regions and languages is obviously 
encouraged. 

2- Have people to generate instance document based on selected stories. 
The interesting bit is when more than one person attempts to serialise the 
same stories. We already know that there is a lot of assumptions in legend 
description and it will be interesting to see how this materialise on a 
rigid GeoSciML document. 

Eric 

================================================================ 
Eric Boisvert 
Spécialiste TI-GI / IT-IM specialist 
Eric.Boisvert at rncan.gc.ca, 418-654-3705, facsimile/télécopieur 
418-654-2615 
490, rue de la Couronne, Québec (Québec), G1K 9A9 
490, rue de la Couronne, Quebec, Quebec, G1K 9A9 

Laboratoire de cartographie numérique et de photogrammétrie (LCNP) 
Digital Cartography and Photogrammetry Laboratory (DCPL) 
Commission géologique du Canada (Québec) / Geological Survey of Canada 
(Quebec) 
Ressources naturelles Canada / Natural Resources Canada 
Gouvernement du Canada / Government of Canada 
http://cgc.rncan.gc.ca/org/quebec <http://cgc.rncan.gc.ca/org/quebec> 
http://cgc.rncan.gc.ca/dir/index_f.php?id=4186 <
http://cgc.rncan.gc.ca/dir/index_f.php?id=4186>  / 
http://cgc.rncan.gc.ca/dir/index_e.php?id=4186 <
http://cgc.rncan.gc.ca/dir/index_e.php?id=4186> 

_______________________________________________
Auscope-geosciml mailing list
Auscope-geosciml at lists.arcs.org.au
http://lists.arcs.org.au/cgi-bin/mailman/listinfo/auscope-geosciml_______________________________________________

Auscope-geosciml mailing list
Auscope-geosciml at lists.arcs.org.au
http://lists.arcs.org.au/cgi-bin/mailman/listinfo/auscope-geosciml

"D?#9?M4Y?8?7?-[1]8b?Vu??r?k'(?)?*'??jW(z{bjPQ?\+?-u??mSLSM???????h???.???y?j^v?i'???-[1]*+¸?{-?m 
???Y?<??"?8?i?&"?z??X???*bz{m?rG???????Y?<????l7!zz+???Xz?^jg??^???wj)]zWz+_????'('b??m?xj???~??y?zf???SM???????(???????{c?-r?y?~?)?zf???SM???????"??)??

_______________________________________________
Auscope-geosciml mailing list
Auscope-geosciml at lists.arcs.org.au
http://lists.arcs.org.au/cgi-bin/mailman/listinfo/auscope-geosciml

Notice:
This email and any attachments may contain information that is personal, 
confidential, legally privileged and/or copyright.No part of it should be reproduced, 
adapted or communicated without the prior written consent of the copyright owner. 

It is the responsibility of the recipient to check for and remove viruses.
If you have received this email in error, please notify the sender by return email, delete 
it from your system and destroy any copies. You are not authorised to use, communicate or rely on the information 
contained in this email.

Please consider the environment before printing this email.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20100304/8459c7cd/attachment.htm>